Re: [Xen-devel] PVH and ACPI discussion

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel