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 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?

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.

> 
>> PIC: same as RTC, I don't know of any way to signal it's presence since
>> it's assumed to be there.
> 
> I think PIC absence can also be gathered from ACPI
> (ACPI_FADT_HW_REDUCED).
> 
>> 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.

>> 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.

> 
>> PM: I'm leaning to split this into ACPI_PM and ACPI_TIMER as said
>> before. ACPI_TIMER presence it's contained inside of ACPI tables, and
>> the availability of ACPI_PM (power management) can be inferred from the
>> presence of ACPI itself.
> 
> As indicated in the original discussion, I don't think these should
> have been separate flags anyway - either you have ACPI (then
> you have indication of both in FADT), or there is no ACPI.

Right. I think this is something internal that's used between the
toolstack and Xen in order to tell Xen whether it should add those
handlers or not, because AFAIK Xen doesn't know if a certain domain has
ACPI or not.

It should not be exposed in any way to the guest except when using ACPI
tables, that will contain the appropriate value.

>> AMD guest IOMMU: AFAICT this seems to be currently disabled, since the
>> MMIO range it checks is [~0ULL, ~0ULL + 0x8000]. There is a function to
>> change the base address ~0ULL to something else, but it doesn't seem to
>> be reachable from any path. In any case, I guess the presence of this
>> device will be reported from ACPI.
> 
> Yes, the implementation is incomplete (abandoned?), but IOMMU
> presence can always be determined by the guest through
> inspecting its ACPI tables.
> 
>> 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.

Also, in order to be able to express their absence we would have to
provide ACPI tables to DomUs, which IMHO, is not something we wish to do
right now.

>> Then I think we could get away without any Xen-specific way of reporting
>> enabled devices.
> 
> Indeed - that should be the preferred goal.

Thanks for the feedback, Roger.


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