Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size
Am 22.05.23 um 13:12 schrieb Gerd Hoffmann:> The patch below fixes it for me. Can you confirm this? Yes, it fixes the issue for me too :) Best Regards, Fiona -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105125): https://edk2.groups.io/g/devel/message/105125 Mute This Topic: https://groups.io/mt/94113626/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size
Am 04.10.22 um 15:47 schrieb Gerd Hoffmann:
> In case we have a reliable PhysMemAddressWidth use that to dynamically
> size the 64bit address window. Allocate 1/8 of the physical address
> space and place the window at the upper end of the address space.
>
> Signed-off-by: Gerd Hoffmann
Hi,
a user recently reported that their Ubuntu 18.04 VM failed to boot after
upgrading to our package based on edk2-stable202302 [0]. While the guest
does reach GRUB, the disk attached via virtio-scsi-pci could not be
found anymore. The user also reported that after changing the bus to
pvscsi, the VM booted again, but the virtual NIC attached via
virtio-net-pci did not work. Changing to e1000 made that work too.
I was able to reproduce the issue (QEMU command line below[1]) and
tracked it down to this patch. I verified that it is still an issue with
current QEMU master and edk2 master, i.e. cafb4f3f36 ("UefiPayloadPkg:
Fix boot shell issue for universal UEFI payload").
The issue happens with -cpu host, but not with -cpu kvm64. My host CPU
is a AMD Ryzen Threadripper 2920X.
"Reverting" with (this was the quickest way)
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index acf90b4e93..8563d7aedb 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -855,7 +855,7 @@ PlatformAddressWidthInitialization (
>PlatformAddressWidthFromCpuid (PlatformInfoHob, TRUE);
>if (PlatformInfoHob->PhysMemAddressWidth != 0) {
> // physical address width is known
> -PlatformDynamicMmioWindow (PlatformInfoHob);
> +//PlatformDynamicMmioWindow (PlatformInfoHob);^M
> return;
>}
allows the disk to be detected again.
The kernel within the VM is
for the user: 4.15.0-210-generic #221-Ubuntu
for me: 4.15.0-211-generic #222-Ubuntu
Happy to provide more information and relevant parts of debug logs.
Best Regards,
Fiona
[0]: https://forum.proxmox.com/threads/127410/#post-557209
[1]: > ./qemu-system-x86_64 \
> -accel 'kvm' \
> -chardev
> 'socket,id=qmp,path=/var/run/qemu-server/113.qmp,server=on,wait=off' \
> -mon 'chardev=qmp,mode=control' \
> -pidfile /var/run/qemu-server/113.pid \
> -drive 'if=pflash,unit=0,format=raw,readonly=on,file=/root/OVMF_CODE.fd' \
> -drive
> 'if=pflash,unit=1,id=drive-efidisk0,format=raw,file=/dev/pve/vm-113-disk-2,size=540672'
> \
> -nodefaults \
> -vnc 'unix:/var/run/qemu-server/113.vnc,password=on' \
> -cpu host \
> -m 10240 \
> -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' \
> -device 'vmware-svga,id=vga,bus=pci.0,addr=0x2' \
> -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1' \
> -drive
> 'file=/dev/pve/vm-113-disk-1,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on'
> \
> -device
> 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100'
> \
> -serial pty \
> -S \
> -machine 'type=pc'
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104943): https://edk2.groups.io/g/devel/message/104943
Mute This Topic: https://groups.io/mt/94113626/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*
Am 30.03.23 um 10:53 schrieb Gerd Hoffmann:
> On Thu, Mar 30, 2023 at 10:04:02AM +0200, Fiona Ebner wrote:
>> Am 28.11.22 um 06:40 schrieb Gerd Hoffmann:
>>> Instead of using hard-coded strings ("0.0.0" for BiosVersion etc)
>>> which is mostly useless read the PCDs (PcdFirmwareVendor,
>>> PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and
>>> build the string table dynamuically at runtime.
>>>
>>> Signed-off-by: Gerd Hoffmann
>>> ---
>>> .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 6 +
>>> .../XenSmbiosPlatformDxe.inf | 9 +-
>>> OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 115 +++---
>>> 3 files changed, 85 insertions(+), 45 deletions(-)
>>>
>>
>> Hi,
>> after this patch, certain SMBIOS values are different[2]. We got a
>> report that the different vendor causes issues with hardware keys[0].
>> And, as I learned from the patch fixing it, the missing date can cause
>> issues with Windows[1].
>
> See a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release
> date") for the windows issue.
>
Should the date string be "02/02/2022" rather than "2/2/2022" in that
commit?
I was wondering whether month or date comes first and found the
following in ([0], section 7.1):
> String number of the BIOS release date.
> The date string, if supplied, is in either
> mm/dd/yy or mm/dd/ format. If the year
> portion of the string is two digits, the year is
> assumed to be 19yy.
> NOTE: The mm/dd/ format is required for
> SMBIOS version 2.3 and later.
> You can set those using
> 'build --pcd PcdFirmwareVersionString="L${string}\\0" ...'
> (same for the other pcds).
I had already found the build option in the discussion of v1 of this
patch, but now I'm wondering: is the "\\0" explicitly required? My build
yesterday seemed to work without it, but I guess, I'll just add it to
make sure.
>>> It'd be
>>> good to understand what upstream's intention was there - are they
>>> expecting each distributor to set our own values, and if so, is there
>>> a scheme we should follow?
>
> The intention is to allow setting version information to whatever makes
> sense for you. A hardcoded "0.0.0" version certainly isn't very useful
> when it comes to bug reporting etc.
>
> Fedora leaves vendor unchanged, sets release date to the commit date of
> the edk2-stablemm stable tag the build is based on and version to
> the rpm package version, i.e. like this ...
>
> Handle 0x, DMI type 0, 26 bytes
> BIOS Information
> Vendor: EDK II
> Version: edk2-20230301gitf80f052277c8-1.test6.fc37
> Release Date: 03/01/2023
> [ ... ]
>
> ... which allows to easily identify the exact firmware build running.
> The one listed above happens to be this one:
>
> https://download.copr.fedorainfracloud.org/results/kraxel/edk2.testbuilds/fedora-37-x86_64/05727085-edk2/
>
Thank you for the explanation!
Best regards,
Fiona
[0]:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102172): https://edk2.groups.io/g/devel/message/102172
Mute This Topic: https://groups.io/mt/95304965/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 1/1] OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*
Am 28.11.22 um 06:40 schrieb Gerd Hoffmann:
> Instead of using hard-coded strings ("0.0.0" for BiosVersion etc)
> which is mostly useless read the PCDs (PcdFirmwareVendor,
> PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and
> build the string table dynamuically at runtime.
>
> Signed-off-by: Gerd Hoffmann
> ---
> .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 6 +
> .../XenSmbiosPlatformDxe.inf | 9 +-
> OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 115 +++---
> 3 files changed, 85 insertions(+), 45 deletions(-)
>
Hi,
after this patch, certain SMBIOS values are different[2]. We got a
report that the different vendor causes issues with hardware keys[0].
And, as I learned from the patch fixing it, the missing date can cause
issues with Windows[1].
To keep backwards compatibility for [0], it's necessary for us to
specify the old vendor value during build.
I assume this will affect other downstream distributors too. Since we
base our packaging off Debian, I asked there for how to best handle it
and am now passing along the question I got in return:
Am 29.03.23 um 18:51 schrieb dann frazier:
> It'd be
> good to understand what upstream's intention was there - are they
> expecting each distributor to set our own values, and if so, is there
> a scheme we should follow?
Best Regards,
Fiona
[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=4625
[1]: https://edk2.groups.io/g/devel/message/100922
[2]: dmidecode output differences in a Linux guest when running with a
build with OvmfPkg/OvmfPkgIa32X64.dsc:
edk2-stable202205:
Vendor: EFI Development Kit II / OVMF
Version: 0.0.0
Release Date: 02/06/2015
edk2-stable202302:
Vendor: EDK II
Version: unknown
Release Date: unknown
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102160): https://edk2.groups.io/g/devel/message/102160
Mute This Topic: https://groups.io/mt/95304965/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101449): https://edk2.groups.io/g/devel/message/101449
Mute This Topic: https://groups.io/mt/94113631/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space
Am 16.03.23 um 15:37 schrieb Gerd Hoffmann:
> On Thu, Mar 16, 2023 at 02:58:07PM +0100, Fiona Ebner wrote:
>> Hi,
>> after upgrading to edk2-stable202211 recently, we got user reports[0]
>> about QEMU virtual machines with '-cpu host' on AMD Ryzen hosts not
>> booting correctly anymore. A workaround seems to be assigning more
>> memory to the VM.
>
> Most likely this one:
> https://bugzilla.tianocore.org/show_bug.cgi?id=4251
>
> Either upgrade to 202302 or backport a107ad0f6236..015a001b03db
> to fix that.
>
Thank you for the suggestion! Unfortunately, the behavior is the same
with 202302 (and with current master, i.e. 410ca0ff94). The bug report
talks about TCG, but this is with KVM.
Is there anything like page tables or the MMIO window which simply
requires more memory when PhysMemAddressWidth is larger? Please note
that the issue here occurs with and without ecb778d0ac
("OvmfPkg/PlatformInitLib: dynamic mmio window size"), the first bad
commit is one earlier.
P.S. I would've tested 202302 already yesterday, but we base the edk2
package off Debian and building the 202302 release didn't work. The QEMU
instance spawned by debian/edk2-vars-generator.py script would hang. I
had to find and cherry-pick QEMU commit dab30fbef3 ("acpi: cpuhp: fix
guest-visible maximum access size to the legacy reg block") first to
make it work.
Best Regards,
Fiona
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101333): https://edk2.groups.io/g/devel/message/101333
Mute This Topic: https://groups.io/mt/94113631/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space
Hi,
after upgrading to edk2-stable202211 recently, we got user reports[0]
about QEMU virtual machines with '-cpu host' on AMD Ryzen hosts not
booting correctly anymore. A workaround seems to be assigning more
memory to the VM.
I was able to reproduce the issue locally (with QEMU 7.2 and an Ubuntu
20.04 VM, kernel 5.15) and bisecting led me to this patch, i.e. commit
bbda386d25 ("OvmfPkg/PlatformInitLib: detect physical address space"),
as the first bad one.
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?
Happy to provide additional information if needed!
Best Regards,
Fiona
[0]: https://forum.proxmox.com/threads/124193/
[1]: host CPU model: AMD Ryzen Threadripper 2920X 12-Core Processor
[2]: QEMU command line:
> ./qemu-system-x86_64 \
> -accel 'kvm' \
> -chardev
> 'socket,id=qmp,path=/var/run/qemu-server/141.qmp,server=on,wait=off' \
> -mon 'chardev=qmp,mode=control' \
> -pidfile /var/run/qemu-server/141.pid \
> -drive
> 'if=pflash,unit=0,format=raw,readonly=on,file=/usr/share/pve-edk2-firmware//OVMF_CODE_4M.fd'
> \
> -drive
> 'if=pflash,unit=1,id=drive-efidisk0,cache=writeback,format=raw,file=rbd:rbdkvm/vm-141-disk-1:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring:rbd_cache_policy=writeback,size=540672'
> \
> -smp '1,sockets=1,cores=1,maxcpus=1' \
> -vnc 'unix:/var/run/qemu-server/141.vnc,password=on' \
> -cpu host \
> -m 512 \
> -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' \
> -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' \
> -device 'VGA,id=vga,bus=pci.1,addr=0x2' \
> -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1' \
> -drive
> 'file=rbd:rbdkvm/vm-141-disk-0:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on'
> \
> -device
> 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100'
> \
> -machine 'type=pc'
Am 04.10.22 um 15:47 schrieb Gerd Hoffmann:
> Try detect physical address space, when successful use it.
> Otherwise go continue using the current guesswork code path.
>
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/Library/PlatformInitLib/MemDetect.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index 143a01ceb01e..16ecbfadc30c 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -761,6 +761,19 @@ PlatformAddressWidthInitialization (
> FirstNonAddress = PlatformGetFirstNonAddress (PlatformInfoHob);
>}
>
> + PlatformAddressWidthFromCpuid (PlatformInfoHob, TRUE);
> + if (PlatformInfoHob->PhysMemAddressWidth != 0) {
> +// physical address width is known
> +PlatformInfoHob->FirstNonAddress = FirstNonAddress;
> +return;
> + }
> +
> + //
> + // physical address width is NOT known
> + // -> do some guess work, mostly based on installed memory
> + // -> try be conservstibe to stay below the guaranteed minimum of
> + // 36 phys bits (aka 64 GB).
> + //
>PhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
>
>//
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101282): https://edk2.groups.io/g/devel/message/101282
Mute This Topic: https://groups.io/mt/94113631/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
