[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID
>>> 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). > 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. > PIT: assumed to be always present in the PC architecture. See PIC above. > 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. > 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. > Then I think we could get away without any Xen-specific way of reporting > enabled devices. Indeed - that should be the preferred goal. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |