From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) by mx.groups.io with SMTP id smtpd.web11.15342.1679322052045257515 for ; Mon, 20 Mar 2023 07:20:52 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: proxmox.com, ip: 94.136.29.106, mailfrom: f.ebner@proxmox.com) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B737F459E9; Mon, 20 Mar 2023 15:20:49 +0100 (CET) Message-ID: <550ddd42-2f53-b75e-c819-acfc12fd620f@proxmox.com> Date: Mon, 20 Mar 2023 15:20:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space To: Gerd Hoffmann Cc: devel@edk2.groups.io, Jordan Justen , Pawel Polawski , Jiewen Yao , Oliver Steffen , Ard Biesheuvel , Thomas Lamprecht References: <20221004134728.55499-1-kraxel@redhat.com> <20221004134728.55499-3-kraxel@redhat.com> <5259991b-964c-4378-f206-9991053f7c7e@proxmox.com> <20230317140148.7ioafsne2asymfxi@sirius.home.kraxel.org> From: "Fiona Ebner" In-Reply-To: <20230317140148.7ioafsne2asymfxi@sirius.home.kraxel.org> Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Am 17.03.23 um 15:01 schrieb Gerd Hoffmann: > Hi, > >> With edk2-stable202205 or when reverting the commit, my VM boots with >> only 512 MiB of assigned memory. With the commit, with 512 MiB it cannot >> even initialize the display, with 750 MiB it runs into a different error >> during Linux boot, and with 900 MiB it boots fine again. >> >> So it seems that having a larger PhysMemAddressWidth requires more >> memory? Is this expected and does running VMs with this version simply >> require more memory now? Is there a way to avoid that? > > Might be more memory being needed for page tables. Making sure gigabyte > pages are enabled (-cpu $name,pdpe1gb=on), so edk2 can use them for the > mmio window identity mapping. > > Alternatively try change the cap: > > ------------------------------------------------------------ > diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c > index 38cece9173e8..76df6fd020bf 100644 > --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c > +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c > @@ -669,9 +669,9 @@ PlatformAddressWidthFromCpuid ( > PhysBits = 47; > } > > - if (!Page1GSupport && (PhysBits > 40)) { > - DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 40 (no 1G pages available)\n", __func__)); > - PhysBits = 40; > + if (!Page1GSupport && (PhysBits > 38)) { > + DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 38 (no 1G pages available)\n", __func__)); > + PhysBits = 38; > } > > PlatformInfoHob->PhysMemAddressWidth = PhysBits; > ------------------------------------------------------------ > > HTH, > Gerd > > It seems that Page1GSupport is already TRUE in my case, so unfortunately, the suggested changes don't help. Before commit bbda386d25, PhysMemAddressWidth is 36, after the commit, it's 47. I tried with hardcoding different values: 45 - My VM boots fine. 46 - I run into a "KVM internal error. Suberror: 1" during Linux boot (that's also what happens with 47 and 750 MiB of memory). 47 - Hangs right away and display is never initialized. Is there any interest to use a smaller limit than 47 from upstream's perspective? Admittedly, it is a rather niche case to use OVMF with so little memory. In any case, thank you for taking a look! Best Regards, Fiona