Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 22/01/16 a les 16.02, Jan Beulich ha escrit:
>>>> On 22.01.16 at 15:41, <roger.pau@xxxxxxxxxx> wrote:
>> El 22/01/16 a les 14.24, Jan Beulich ha escrit:
>>>>>> On 22.01.16 at 13:43, <roger.pau@xxxxxxxxxx> wrote:
>>>> RTC: I don't know of any way to signal the RTC presence, AFAICT it's
>>>> always assumed to be there in the PC architecture. Could maybe return ~0
>>>> when reading from IO port 0x71, but that's meh..., not the best way IMHO.
>>>
>>> There actually is an RTC-absent flag in the FADT, which the
>>> hypervisor itself actually looks at (ACPI_FADT_NO_CMOS_RTC).
>>
>> So most of this assumes that if we ever want to enable any of those
>> devices we will provide ACPI tables to the guest?
> 
> We could check whether exposing SFI tables to the guest would
> be a simpler mechanism allowing enough control.
> 
> In the absence of ACPI we need to settle on defaults: As Andrew
> has said, contemporary logic would imply no legacy devices for an
> environment that can be (made) aware of such.
> 
>> The RTC can also be used as an interrupt source, which I think it's not
>> covered by the ACPI_FADT_NO_CMOS_RTC flag.
> 
> Certainly if there's no RTC device, then there's also no legacy
> IRQ8.
> 
>>>> VGA: again I don't think there's an easy way to signal it's presence,
>>>> apart from returning ~0 from the multiple IO ports it uses. The fact
>>>> that the 0xA0000-0xBFFFF memory range is also marked as RAM in the e820
>>>> map in HVMlite DomUs should also trigger OSes into disabling VGA due to
>>>> the lack of proper MMIO range, but sadly I think most OSes just assume
>>>> it's there.
>>>
>>> Yes, VGA is kind of more difficult. Looking at all PCI devices'
>>> command words may provide a hint, as may looking at all PCI
>>> bridges' bridge control words.
>>
>> Hm that seems like a rather convoluted procedure, and this needs to be
>> available very early on during the boot process usually.
> 
> As long as the legacy MMIO address range isn't re-used by some
> other device, having an OS blindly write to that range is quite okay
> (and common practice) I think. Iiuc you think about getting log
> messages out early?
> 
>>>> PIT: assumed to be always present in the PC architecture.
>>>
>>> See PIC above.
>>
>> At least on FreeBSD PIT is used much earlier than parsing any ACPI
>> tables (it's used to implement a busy-wait DELAY routine), so I don't
>> think it's sensible to tie this device to ACPI. Also see my note above
>> about requiring ACPI in order to signal all of this.
> 
> See above: Quite likely you will need to do away with using PIT when
> run as HVMlite guest.

Oh yes, that's certainly not a problem for FreeBSD. I've already
replaced the usage of the PIT during early boot with the PV timer. I was
just pointing this out in order to make it easier for other OSes to
adopt HVMlite, I wouldn't be surprised to find out that other OSes also
use the PIT as an early source for delay available universally.

>>>> So, we have the following devices that are assumed to be there: RTC,
>>>> PIC, PIT. Everything else I think can be signalled by other means
>>>> already available.
>>>>
>>>> IMHO, I think we could say that the PIC is never going to be available
>>>> to HVMlite guests (in any case we would enable the lapic/ioapic), and
>>>> maybe enable the RTC and PIT by default?
>>>
>>> That may be a sane initial setup, but with the ACPI flags named
>>> above we may be able to expressed even their absence.
>>
>> I still think we should probably enable those, because they tend to be
>> used very early on boot, before parsing ACPI tables, and in general are
>> considered to be always there on PCs.
> 
> No if you think the modern legacy free way.

Ack.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel