From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web11.172838.1673888986331664483 for ; Mon, 16 Jan 2023 09:09:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HP1YqXsz; spf=pass (domain: kernel.org, ip: 145.40.73.55, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id ECE7FCE1285 for ; Mon, 16 Jan 2023 17:09:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4716BC433F1 for ; Mon, 16 Jan 2023 17:09:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673888981; bh=DgJDf3Yrqz8ENJd1JXw5otBt3E1SKikeCfPKm6yS5EA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HP1YqXsz8RVj6YFJ6qKl1hdOqvUj3Tst5tFnOCgL8omflU0nRNd1cx875lpPAh3oU 0vs0pVO8yCsvKsHGh5EXYHSL0srAdbWEa5hg0rwTdnAQH0c9zXE9586QpojgZUerFJ 9O+WJyn/JuXh2iXMTxRJhEE7wJ13OiQ4RDa0f2bkZsiINosTuyaAbMA9M+I4tCVslo ohAuVPPvmPG+k4hCt9o390dJ5kG7JvN7/4FUWIVa2YeUFt6fhVnKjiI+qjFArZBwYO 1iUq5vT2qB3wk4FdJPl2VqHDaZtKPxkIunZA5M0Xff5ieoayYbMQ7MVjKXIPPIQBfw VpfpDe47DFEqw== Received: by mail-lf1-f42.google.com with SMTP id y25so43564439lfa.9 for ; Mon, 16 Jan 2023 09:09:41 -0800 (PST) X-Gm-Message-State: AFqh2kq8/kP3xpt5Pr5sGvZLrSUMmVyknbo5P2ierBjasQPZhZyMhlE6 3bnv+BAsKBp1/7kSd/21d7BSNgU11LKekSY/Ctc= X-Google-Smtp-Source: AMrXdXse8TTbVOUWhoxZmAV7MKTaIxYM1N0PWanKyNrdbKnCc4O8gQ4cUkTLSZrR1HxwehNUMnkLGacnl0MFrA1c6DE= X-Received: by 2002:a05:6512:15a3:b0:4bc:bdf5:f163 with SMTP id bp35-20020a05651215a300b004bcbdf5f163mr4642971lfb.583.1673888979334; Mon, 16 Jan 2023 09:09:39 -0800 (PST) MIME-Version: 1.0 References: <20221207053215.2527430-1-kraxel@redhat.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 16 Jan 2023 18:09:28 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu To: Tom Lendacky Cc: devel@edk2.groups.io, kraxel@redhat.com, Laszlo Ersek , Oliver Steffen , Ard Biesheuvel , Jordan Justen , Jiewen Yao , Pawel Polawski Content-Type: text/plain; charset="UTF-8" On Thu, 12 Jan 2023 at 18:09, Tom Lendacky wrote: > > 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 > > 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. > Could someone look into this please? Gerd?