From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 03 Jun 2019 11:10:37 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 165F43082231; Mon, 3 Jun 2019 18:10:31 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-13.rdu2.redhat.com [10.10.121.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id A809F6402B; Mon, 3 Jun 2019 18:10:19 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH for-edk2-stable201905 0/6] work around a QEMU issue triggered by the original TianoCore#1814 fix From: "Laszlo Ersek" To: edk2-devel-groups-io Cc: Ard Biesheuvel , Gerd Hoffmann , Jordan Justen , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Reply-To: devel@edk2.groups.io, lersek@redhat.com References: <20190529151209.17503-1-lersek@redhat.com> Message-ID: <7b0457b4-1eda-9897-2b8b-7ad245552684@redhat.com> Date: Mon, 3 Jun 2019 20:10:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190529151209.17503-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Mon, 03 Jun 2019 18:10:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/29/19 17:12, Laszlo Ersek wrote: > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 > Repo: https://github.com/lersek/edk2.git > Branch: exbar_mtrr_bz_1859 > > The fix (commit range 3b7a897cd8e3..39b9a5ffe661) for > is technically > correct, but it tickles an (arguably unjustified) assumption in QEMU the > wrong way. For end users, this makes the original fix for TianoCore#1814 > a regression, under certain circumstances. > > In theory, the assumption should be eliminated in QEMU, but in practice, > that could be quite intrusive and/or take long. It seems possible to > work around the problem in OVMF, satisfying the assumption again; for > that, OVMF needs a different fix (and a different trade-off) for the > original problem described in TianoCore#1814. > > Please see the detailed problem statement and the workaround's idea in > TianoCore#1859. > > If possible, I'd like to get this into edk2-stable201905 (which we're > postponing by two weeks anyway, for the sake of the OpenSSL 1.1.1b > upgrade). > > Cc: Ard Biesheuvel > Cc: Gerd Hoffmann > Cc: Jordan Justen Thank you everyone for the feedback; I've pushed the series as commit range f03859ea6c8f..49edde15230a. Laszlo > Laszlo Ersek (6): > Revert "OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many > bits clear" > Revert "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the > PCIEXBAR on q35" > Revert "OvmfPkg/PlatformPei: hoist PciBase assignment above the > i440fx/q35 branching" > Revert "OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 > branches explicitly" > OvmfPkg: raise the PCIEXBAR base to 2816 MB on Q35 > OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase > (pc/q35) > > OvmfPkg/OvmfPkgIa32.dsc | 5 +- > OvmfPkg/OvmfPkgIa32X64.dsc | 5 +- > OvmfPkg/OvmfPkgX64.dsc | 5 +- > OvmfPkg/PlatformPei/Platform.h | 5 ++ > OvmfPkg/PlatformPei/MemDetect.c | 70 +++++++++++++++----- > OvmfPkg/PlatformPei/Platform.c | 17 +++-- > 6 files changed, 80 insertions(+), 27 deletions(-) >