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(-)
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@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@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(-)
--
2.19.1.3.g30247aa5d201
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39965): https://edk2.groups.io/g/devel/message/39965
Mute This Topic: https://groups.io/mt/31489694/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
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. 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.) 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@linaro.org> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: Jordan Justen <jordan.l.justen@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 (#40682): https://edk2.groups.io/g/devel/message/40682 Mute This Topic: https://groups.io/mt/31489694/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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@linaro.org> > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > Cc: Jordan Justen <jordan.l.justen@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/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Looks like a bug fix to me and is fine for soft freeze period. To commit during hard freeze, just need to show it is a critical bug. Mike > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Wednesday, May 15, 2019 4:57 AM > To: Laszlo Ersek <lersek@redhat.com> > Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Ard > Biesheuvel <ard.biesheuvel@linaro.org>; Kinney, Michael > D <michael.d.kinney@intel.com>; Andrew Fish > <afish@apple.com>; Gerd Hoffmann <kraxel@redhat.com>; > Justen, Jordan L <jordan.l.justen@intel.com> > Subject: Re: [edk2-devel] [PATCH 0/4] > OvmfPkg/PlatformPei: fix two assertion failures with > weird RAM sizes > > 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@linaro.org> > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > Cc: Jordan Justen <jordan.l.justen@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 (#40701): https://edk2.groups.io/g/devel/message/40701 Mute This Topic: https://groups.io/mt/31489694/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 05/15/19 13:56, Leif Lindholm wrote: > 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. Good point; I've now filed <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>, and I'll reference it in the commit messages, when I push the series. Thanks! Laszlo > 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@linaro.org> >>> Cc: Gerd Hoffmann <kraxel@redhat.com> >>> Cc: Jordan Justen <jordan.l.justen@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 (#40694): https://edk2.groups.io/g/devel/message/40694 Mute This Topic: https://groups.io/mt/31489694/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
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, ...). Thanks to everyone for the feedback! I've now pushed this series as commit range 3b7a897cd8e3..39b9a5ffe661, with the following updates (all requested per review feedback): * added the following tag to every commit message: Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 * dropped the following tag from every affected commit message (i.e., on the first three patches): Contributed-under: TianoCore Contribution Agreement 1.1 * picked up Phil's and Ard's R-bs * replaced "hole" with "window" in the commit message of patch #3, then re-folded the text to 74 columns. Cheers Laszlo > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: Jordan Justen <jordan.l.justen@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 (#40828): https://edk2.groups.io/g/devel/message/40828 Mute This Topic: https://groups.io/mt/31489694/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.