[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 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. >>> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |