From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: michael.d.kinney@intel.com) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by groups.io with SMTP; Wed, 15 May 2019 09:42:38 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 09:42:36 -0700 X-ExtLoop1: 1 Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga007.jf.intel.com with ESMTP; 15 May 2019 09:42:36 -0700 Received: from orsmsx124.amr.corp.intel.com (10.22.240.120) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 15 May 2019 09:42:36 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.231]) by ORSMSX124.amr.corp.intel.com ([169.254.2.120]) with mapi id 14.03.0415.000; Wed, 15 May 2019 09:42:36 -0700 From: "Michael D Kinney" To: Leif Lindholm , Laszlo Ersek , "Kinney, Michael D" CC: edk2-devel-groups-io , Ard Biesheuvel , Andrew Fish , Gerd Hoffmann , "Justen, Jordan L" Subject: Re: [edk2-devel] [PATCH 0/4] OvmfPkg/PlatformPei: fix two assertion failures with weird RAM sizes Thread-Topic: [edk2-devel] [PATCH 0/4] OvmfPkg/PlatformPei: fix two assertion failures with weird RAM sizes Thread-Index: AQHVAg1edq0vKuu/BEyo6nG4NW+dn6ZshVEAgAAWdoD//9kscA== Date: Wed, 15 May 2019 16:42:34 +0000 Message-ID: References: <20190504000716.7525-1-lersek@redhat.com> <20190515115645.x2ewrg23rwsreocx@bivouac.eciton.net> In-Reply-To: <20190515115645.x2ewrg23rwsreocx@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Return-Path: michael.d.kinney@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 > Cc: edk2-devel-groups-io ; Ard > Biesheuvel ; Kinney, Michael > D ; Andrew Fish > ; Gerd Hoffmann ; > Justen, Jordan L > Subject: Re: [edk2-devel] [PATCH 0/4] > OvmfPkg/PlatformPei: fix two assertion failures with > weird RAM sizes >=20 > 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. >=20 > Clearly bugfix, and quite contained in scope as well. >=20 > > 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.) >=20 > I would lean towards having a TianoCore BZ for anything > pushed in the > freeze period. >=20 > 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. >=20 > But if you (plural) feel I'm being overly cautious, I > don't feel > *that* strongly about it. >=20 > Regards, >=20 > Leif >=20 > > 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=3D1666941 > > > Ref: > https://bugzilla.redhat.com/show_bug.cgi?id=3D1701710 > > > > > > 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 > > > Cc: Gerd Hoffmann > > > Cc: Jordan Justen > > > > > > 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(-) > > > > >