Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on Xen

["Anthony PERARD" <anthony.perard@citrix.com>]

On Tue, Jan 19, 2021 at 03:49:34PM +0100, Laszlo Ersek wrote:
> On 01/19/21 10:37, Julien Grall wrote:
> > Hi Igor,
> > 
> > On 13/01/2021 03:42, Igor Druzhinin wrote:
> >> We faced a problem with passing through a PCI device with 64GB BAR to
> >> UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at
> >> 64G address which pushes physical address space to 37 bits. That is above
> >> 36-bit width that OVMF exposes currently to a guest without tweaking
> >> PcdPciMmio64Size knob.
> >>
> >> The reverse calculation using this knob was inhereted from QEMU-KVM
> >> platform
> >> code where it serves the purpose of finding max accessible physical
> >> address without necessary trusting emulated CPUID physbits value (that
> >> could
> >> be different from host physbits). On Xen we expect to use CPUID policy
> >> to level the data correctly to prevent situations with guest physbits >
> >> host physbits e.g. across migrations.
> >>
> >> The next aspect raising concern - resource consumption for DXE IPL
> >> page tables
> >> and time required to map the whole address space in case of using CPUID
> >> bits directly. That could be mitigated by enabling support for 1G pages
> >> in DXE IPL configuration. 1G pages are available on most CPUs produced in
> >> the last 10 years and those without don't have many phys bits.
> >>
> >> Remove all the redundant code now (including PcdPciMmio64.. handling
> >> that's
> >> not used on Xen anyway) and grab physbits directly from CPUID that should
> >> be what baremetal UEFI systems do.
> >>
> >> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
> > 
> > Reviewed-by: Julien Grall <julien@xen.org>
> 
> I'm going to hold this patch until Anthony responds in this thread as well:

This new patch is fine, I didn't notice that it was a replacement for
the previous one.

Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks,

-- 
Anthony PERARD