On 1/3/19 12:45 PM, Roger Pau Monné wrote: > Hello, > > While looking at some tangential issues I realized that the 'VGA Not > Present' flag that Xen currently sets for PVH DomUs might be slightly > different from what we expect it to mean. The purpose was that Xen > would set this flag to denote there's no VGA MMIO region in the low > 1MB, so that the guest OS would not reserve memory in that area > thinking there's a MMIO window there. The memory map provided to a PVH > DomU typically contains a single RAM range that expands from 0 to the > selected amount of memory. > > The description of such flag by the ACPI spec (6.2A) however is as > follows: > > "If set, indicates to OSPM that it must not blindly probe the VGA > hardware (that responds to MMIO addresses A0000h-BFFFFh and IO ports > 3B0h-3BBh and 3C0h-3DFh) that may cause machine check on this system. > If clear, indicates to OSPM that it is safe to probe the VGA > hardware." > > My reading of the above text would make me think that if the flag is > set the memory region A0000h-BFFFFh should not be used at all, and > that would be in conflict with the memory map that's provided to > guests (which lists this area as RAM). > > I'm not convinced of the best way to proceed here. I can contact the > ACPI working group and try to clarify the meaning of the flag, or > inquiry if there's a more suitable flag for or use case, but I would > like to hear others opinion on this topic. > > Secondly, I've also been looking at whether it would make sense to set > the ACPI reduced hardware flag for PVH DomUs, according to the > description in the ACPI spec: > > "For certain classes of systems the ACPI Hardware Specification may > not be adequate. Examples include legacy-free, UEFI-based platforms > with recent processors, and those implementing mobile platform > architectures. For such platforms, a Hardware-reduced ACPI mode is > defined." > > Certainly the legacy-free and UEFI part is quite applicable to PVH > DomU, for which we don't plan to support legacy BIOS and only provide > UEFI firmware in the long term. > > Reduced HW ACPI also gets rid of the SCI interrupt, and instead > provides some other methods to signal ACPI events (note we don't > use any ACPI event ATM for PVH DomU). It also gets rid of a bunch of > FADT fields that we don't use for PVH DomU either. > > I however seem to remember some past discussion about PVH DomU and > reduced ACPI, but I cannot find the thread. If there are no objections > I think we should look into this (likely discuss with the ACPI working > group) in order to figure out if reduced HW ACPI could work for us, > and how the event delivery could be implemented for PVH DomU if it > turns out we need it later on. It might make sense to also figure out > what other people do, like HyperV Gen2 instances (which also get rid > of a lot of legacy hw).
I found a couple of thread where we discussed this: https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01462.html https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg00675.html I can't find where we actually rejected it but I think it had something to with the fact that we can't use it for dom0. -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
