[edk2-devel] [PATCH 0/4] OvmfPkg/PlatformPei: fix two assertion failures with weird RAM sizes

[Leif Lindholm]

On Wed, May 15, 2019 at 12:36:22PM +0200, Laszlo Ersek wrote:
> Hi Stewards,
> 
> it seems likely that this patch series -- posted on 2019-May-04 -- will
> not receive the necessary maintainer A-b's / R-b's before we enter the
> soft feature freeze for edk2-stable201905.
> 
> Therefore I'd like to state that I consider this series a bugfix series,
> not a feature addition. I'm now asking for confirmation that I'll be
> allowed to push the series -- dependent on the expected reviewer
> feedback of course -- even after 2019-May-17 08:00:00 UTC.

Clearly bugfix, and quite contained in scope as well.

> Please also state whether I will need to open a TianoCore BZ for
> tracking this work (and to update the commit messages accordingly). I
> haven't done that because we already have two public BZs for the issue
> in the Red Hat Bugzilla instance, with issue description and analysis.
> (RHBZ references are captured in both the blurb below, and in the
> patches themselves.)

I would lean towards having a TianoCore BZ for anything pushed in the
freeze period.

While I don't expect Red Hat to close its BZ from public access, it
does sort of open up the question of "well, which other BZs do we
consider trustworthy enough to give the same treatment?" that I would
prefer to avoid having to deal with during future freeze periods.

But if you (plural) feel I'm being overly cautious, I don't feel
*that* strongly about it.

Regards,

Leif

> Thanks
> Laszlo
> 
> On 05/04/19 02:07, Laszlo Ersek wrote:
> > Repo:   https://github.com/lersek/edk2.git
> > Branch: exbar_mtrr_rhbz_1666941
> > Ref:    https://bugzilla.redhat.com/show_bug.cgi?id=1666941
> > Ref:    https://bugzilla.redhat.com/show_bug.cgi?id=1701710
> > 
> > When booting OVMF on QEMU with "weird" RAM sizes, QEMU's low-RAM split
> > logic can trigger two assertion failures in OVMF:
> > 
> > - conflict between PCIEXBAR (ECAM) and low-RAM, on q35,
> > 
> > - running out of variable MTRRs when marking the uncacheable MMIO range
> >   in 32-bit address space, on both i440fx and q35.
> > 
> > This series fixes both issues, by moving around the PCIEXBAR on q35, and
> > by truncating the size of the uncacheable 32-bit area to a power of two.
> > The latter idea was inspired by SeaBIOS.
> > 
> > Tested on both machine types, with the following memory sizes (all in
> > MB): 1025, 2815, 3583, 5120. On i440fx, the X64 build was used (without
> > SMM). On q35, the IA32 and IA32X64 builds were used (with SMM). Testing
> > included "/proc/mtrr" verification, 32-bit PCI MMIO aperture
> > verification, general dmesg checks, and my usual regression tests too
> > (ACPI S3, UEFI variable services, ...).
> > 
> > Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > Cc: Gerd Hoffmann <kraxel at redhat.com>
> > Cc: Jordan Justen <jordan.l.justen at intel.com>
> > 
> > Thanks
> > Laszlo
> > 
> > Laszlo Ersek (4):
> >   OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches
> >     explicitly
> >   OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35
> >     branching
> >   OvmfPkg/PlatformPei: reorder the 32-bit PCI hole vs. the PCIEXBAR on
> >     q35
> >   OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits
> >     clear
> > 
> >  OvmfPkg/OvmfPkgIa32.dsc         |  5 +----
> >  OvmfPkg/OvmfPkgIa32X64.dsc      |  5 +----
> >  OvmfPkg/OvmfPkgX64.dsc          |  5 +----
> >  OvmfPkg/PlatformPei/MemDetect.c | 23 +++++++++++++++++---
> >  OvmfPkg/PlatformPei/Platform.c  | 14 +++++-------
> >  OvmfPkg/PlatformPei/Platform.h  |  2 ++
> >  6 files changed, 31 insertions(+), 23 deletions(-)
> > 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#40685): https://edk2.groups.io/g/devel/message/40685
Mute This Topic: https://groups.io/mt/31489694/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-