From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.85.128.68, mailfrom: philmd@redhat.com) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by groups.io with SMTP; Wed, 29 May 2019 08:24:29 -0700 Received: by mail-wm1-f68.google.com with SMTP id z23so1896974wma.4 for ; Wed, 29 May 2019 08:24:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PvdTF74C4Bzk4J21gCrNUCt1HdNwm1HPQiDlnv+HuZg=; b=im83yNloA7ri91o9zcxv8zps5o+BaDK7tuaug3Ar12iyKbs/e+6A0VDvz/uWk4NzPb 2gmwTipJQold3KCUiqYhK3JJznoaaULSoFe0DKaNKrIguAB0nMhbd1fU24VtF/TMcHr5 rwjubNs3YgiFAVx35L40bT/YKlFuVP/6/CjISf2ODxrve0z1CxgeToLek/jaKvKCjMrf 0V3Ad4HrktOJ8UUZuzpfqbKB9sNG3v8+a2T+u7W0bEqco6EbmeXLno3QM8PWz7RNmRlV aDKGyPYY6S+phUzlO2VPr/YUUElksHaqxBHC1Li59D8D+r4btvkIM1vnkAa/ELt2fNrq 9bOQ== X-Gm-Message-State: APjAAAVoTwzGtXFr5Lbgdx2AeTkOBO3uUKUliVdzvvIg1HRis2d6Rc1I PUas5bnu96HQyNwrnP+Q5sAvDg== X-Google-Smtp-Source: APXvYqwBmamync2xB+yb488F9RzX/NDT3wEw3yWMvovEhpbZecmnKqDXD98X0rxvAiPczZdhtoXBaw== X-Received: by 2002:a7b:c20b:: with SMTP id x11mr2186683wmi.8.1559143467575; Wed, 29 May 2019 08:24:27 -0700 (PDT) Return-Path: Received: from [10.201.33.53] ([195.166.127.210]) by smtp.gmail.com with ESMTPSA id g5sm12507850wrp.29.2019.05.29.08.24.26 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 08:24:26 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH for-edk2-stable201905 1/6] Revert "OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clear" To: devel@edk2.groups.io, lersek@redhat.com Cc: Ard Biesheuvel , Gerd Hoffmann , Jordan Justen References: <20190529151209.17503-1-lersek@redhat.com> <20190529151209.17503-2-lersek@redhat.com> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Openpgp: id=89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE; url=http://pgp.mit.edu/pks/lookup?op=get&search=0xA2A3FD6EDEADC0DE Message-ID: <7e41ef41-a8bc-5250-a80c-a8a82a259a93@redhat.com> Date: Wed, 29 May 2019 17:24:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190529151209.17503-2-lersek@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 5/29/19 5:12 PM, Laszlo Ersek wrote: > This reverts commit 39b9a5ffe6618b7870be2a54fe7725000249c33a. > > The original fix for > triggered a bug / incorrect assumption in QEMU. > > QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above > it. When the firmware doesn't satisfy this assumption, QEMU generates an > \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the > firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign > 32-bit MMIO BARs. > > Working around the problem in the firmware looks less problematic than > fixing QEMU. Revert the original changes first, before implementing an > alternative fix. > > Cc: Ard Biesheuvel > Cc: Gerd Hoffmann > Cc: Jordan Justen > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 > Signed-off-by: Laszlo Ersek Reviewed-by: Philippe Mathieu-Daude > --- > OvmfPkg/PlatformPei/Platform.h | 2 -- > OvmfPkg/PlatformPei/MemDetect.c | 23 +++----------------- > OvmfPkg/PlatformPei/Platform.c | 4 +++- > 3 files changed, 6 insertions(+), 23 deletions(-) > > diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h > index 4476ddd871cd..81af8b71480f 100644 > --- a/OvmfPkg/PlatformPei/Platform.h > +++ b/OvmfPkg/PlatformPei/Platform.h > @@ -114,6 +114,4 @@ extern UINT32 mMaxCpuCount; > > extern UINT16 mHostBridgeDevId; > > -extern UINT32 mQemuUc32Base; > - > #endif // _PLATFORM_PEI_H_INCLUDED_ > diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c > index ae73c63d27d5..e890e36408a6 100644 > --- a/OvmfPkg/PlatformPei/MemDetect.c > +++ b/OvmfPkg/PlatformPei/MemDetect.c > @@ -42,8 +42,6 @@ STATIC UINT32 mS3AcpiReservedMemorySize; > > STATIC UINT16 mQ35TsegMbytes; > > -UINT32 mQemuUc32Base; > - > VOID > Q35TsegMbytesInitialization ( > VOID > @@ -665,8 +663,6 @@ QemuInitializeRam ( > // cover it exactly. > // > if (IsMtrrSupported ()) { > - UINT32 Uc32Size; > - > MtrrGetAllMtrrs (&MtrrSettings); > > // > @@ -693,24 +689,11 @@ QemuInitializeRam ( > > // > // Set memory range from the "top of lower RAM" (RAM below 4GB) to 4GB as > - // uncacheable. Make sure one variable MTRR suffices by truncating the size > - // to a whole power of two. This will round the base *up*, and a gap (not > - // used for either RAM or MMIO) may stay in the middle, marked as > - // cacheable-by-default. > + // uncacheable > // > - Uc32Size = GetPowerOfTwo32 ((UINT32)(SIZE_4GB - LowerMemorySize)); > - mQemuUc32Base = (UINT32)(SIZE_4GB - Uc32Size); > - if (mQemuUc32Base != LowerMemorySize) { > - DEBUG ((DEBUG_VERBOSE, "%a: rounded UC32 base from 0x%x up to 0x%x, for " > - "an UC32 size of 0x%x\n", __FUNCTION__, (UINT32)LowerMemorySize, > - mQemuUc32Base, Uc32Size)); > - } > - > - Status = MtrrSetMemoryAttribute (mQemuUc32Base, Uc32Size, > - CacheUncacheable); > + Status = MtrrSetMemoryAttribute (LowerMemorySize, > + SIZE_4GB - LowerMemorySize, CacheUncacheable); > ASSERT_EFI_ERROR (Status); > - } else { > - mQemuUc32Base = (UINT32)LowerMemorySize; > } > } > > diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c > index c064b4ed9b8f..fd8eccaf3e50 100644 > --- a/OvmfPkg/PlatformPei/Platform.c > +++ b/OvmfPkg/PlatformPei/Platform.c > @@ -174,12 +174,14 @@ MemMapInitialization ( > AddIoMemoryRangeHob (0x0A0000, BASE_1MB); > > if (!mXen) { > + UINT32 TopOfLowRam; > UINT64 PciExBarBase; > UINT32 PciBase; > UINT32 PciSize; > > + TopOfLowRam = GetSystemMemorySizeBelow4gb (); > PciExBarBase = 0; > - PciBase = (mQemuUc32Base < BASE_2GB) ? BASE_2GB : mQemuUc32Base; > + PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam; > if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) { > // > // The 32-bit PCI host aperture is expected to fall between the top of >