From: "Lendacky, Thomas" <thomas.lendacky@amd.com>
To: devel@edk2.groups.io, kraxel@redhat.com,
Laszlo Ersek <lersek@redhat.com>
Cc: Oliver Steffen <osteffen@redhat.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Pawel Polawski <ppolawsk@redhat.com>
Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu
Date: Thu, 12 Jan 2023 11:09:27 -0600 [thread overview]
Message-ID: <cbedc73a-d0f6-3627-0dc6-177983cc43ea@amd.com> (raw)
In-Reply-To: <20221207053215.2527430-1-kraxel@redhat.com>
On 12/6/22 23:32, Gerd Hoffmann via groups.io wrote:
> qemu uses the etc/e820 fw_cfg file not only for memory, but
> also for reservations. Handle reservations by adding resource
> descriptor hobs for them.
>
> A typical qemu configuration has a small reservation between
> lapic and flash:
>
> # sudo cat /proc/iomem
> [ ... ]
> fee00000-fee00fff : Local APIC
> feffc000-feffffff : Reserved <= HERE
> ffc00000-ffffffff : Reserved
> [ ... ]
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
On newer versions of Qemu, this patch causes a boot failure on my
AMD system with the following output:
...
PciHostBridgeUtilityInitRootBridge: populated root bus 0, with room for 255 subordinate bus(es)
RootBridge: PciRoot(0x0)
Support/Attr: 70069 / 70069
DmaAbove4G: No
NoExtConfSpace: No
AllocAttr: 3 (CombineMemPMem Mem64Decode)
Bus: 0 - FF Translation=0
Io: 6000 - FFFF Translation=0
Mem: C0000000 - FBFFFFFF Translation=0
MemAbove4G: E000000000 - FFFFFFFFFF Translation=0
PMem: FFFFFFFFFFFFFFFF - 0 Translation=0
PMemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0
PciHostBridgeDxe: IntersectMemoryDescriptor: desc [FD00000000, 10000000000) type 1 cap 8000000000026000 conflicts with aperture [E000000000, 10000000000) cap 1
ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [PciHostBridgeDxe] /root/kernels/ovmf-build-X64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(550): !(((INTN)(RETURN_STATUS)(Status)) < 0)
Doing some bisecting, before Qemu patch
8504f129450b ("i386/pc: relocate 4g start to 1T where applicable")
this issue wasn't observed. And before this OVMF patch, the newer version
of Qemu doesn't have an issue.
Also, if I add host-phys-bits=true to the Qemu -cpu parameter, then
the issue isn't observed regardless of Qemu/OVMF level.
I'm hoping someone has an understanding of what is going on and what
can be done to fix it.
Thanks,
Tom
> ---
> OvmfPkg/Library/PlatformInitLib/MemDetect.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index b8feae4309de..a7a4e028ad50 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -228,6 +228,22 @@ PlatformScanOrAdd64BitE820Ram (
> ));
> }
> }
> + } else if (E820Entry.Type == EfiAcpiAddressRangeReserved) {
> + if (AddHighHob) {
> + DEBUG ((
> + DEBUG_INFO,
> + "%a: Reserved: Base=0x%Lx Length=0x%Lx\n",
> + __FUNCTION__,
> + E820Entry.BaseAddr,
> + E820Entry.Length
> + ));
> + BuildResourceDescriptorHob (
> + EFI_RESOURCE_MEMORY_RESERVED,
> + 0,
> + E820Entry.BaseAddr,
> + E820Entry.Length
> + );
> + }
> }
> }
>
next prev parent reply other threads:[~2023-01-12 17:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 5:32 [PATCH 1/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu Gerd Hoffmann
2022-12-23 11:55 ` [edk2-devel] " Ard Biesheuvel
2023-01-12 17:09 ` Lendacky, Thomas [this message]
2023-01-16 17:09 ` Ard Biesheuvel
2023-01-16 20:10 ` Lendacky, Thomas
2023-01-17 16:49 ` Ard Biesheuvel
2023-01-17 21:43 ` Lendacky, Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbedc73a-d0f6-3627-0dc6-177983cc43ea@amd.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox