Re: [Xen-devel] [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection

[Laszlo Ersek <lersek@xxxxxxxxxx>]

On 07/22/19 16:53, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
>> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
>>> When running as a Xen PVH guest, there is no CMOS to read the memory
>>> size from.  Rework GetSystemMemorySize(Below|Above)4gb() so they can
>>> works without CMOS by reading the e820 table.
>>>
>>> Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
>>> about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
>>> already done by hvmloader, on PVH it is supposed to have sane default.
>>>
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>> Acked-by: Laszlo Ersek <lersek@xxxxxxxxxx>
>>> ---
>>>
>>> Notes:
>>>     Comment for Xen people:
>>>     About MTRR, should we redo the setting in OVMF? Even if in both case of
>>>     PVH and HVM, something would have setup the default type to write back
>>>     and handle a few other ranges like PCI hole, hvmloader for HVM or and
>>>     libxc I think for PVH.
>>
>> That's a tricky question. Ideally we would like the firmware (OVMF) to
>> take care of that, because it already has code to do so. Problem here
>> is that PVH can also be booted without firmware, in which case it
>> needs the hypervisor to have setup some sane initial MTRR state.
>>
>> The statement in the PVH document about initial MTRR state is vague
>> enough that allows Xen to boot into the guest with a minimal MTRR
>> state, that can for example not contain UC regions for the MMIO
>> regions of passed through devices, hence I think OVMF should be in
>> charge of creating a more complete MTRR state if possible.
>>
>> Is this something OVMF already has logic for?
> 
> Well, there are some logic but it's for QEMU (and uses an interface that
> isn't available when running on Xen, fwcfg).
> 
> The logic that was there for Xen HVM was very simple, a single set
> cache-write-back for the RAM, that's why I remove it (and because I'm
> not sure yet I figured out how to run the mtrr functions correctly in
> OVMF).
> 
> I probably going to have to write a new logic which would rewrite the
> MTRR from scratch instead of relying on the existing setup.

MTRR setup is complex in OVMF, in comparison to firmware that runs on
physical machines, because:

- the physical RAM size can change from boot to boot, with almost total
freedom, and that can incur some unexpected changes in the physical RAM
map too (i.e. affect not just the end, but holes)

- the number of variable MTRRs is severely limited and can't cover an
arbitrary physical RAM map. And, some platform-independent modules in
edk2 consume variable MTRRs too, via gDS->SetMemorySpaceAttributes(), so
we have to be very conservative with even those variable MTRRs that exist.

Even on QEMU i440fx & pc, we've *just* made OVMF cope with an arbitrary
guest RAM size (that is, beyond 128MB), and that logic relies on some
open-coded board-specific knowledge about low (<4G) RAM size. So much so
that, on i440fx, we place the 32-bit PCI IOMMU aperture based on what we
can configure with a minimal amount of variable MTRRs, and not vice
versa (i.e. we don't first set the 32-bit MMIO aperture and then attempt
to mark it as uncached). Please see:

  https://bugzilla.tianocore.org/show_bug.cgi?id=1814

This is one of the nastiest parts of OVMF. (PlatformPei is, in general.)

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel