Am 12.07.24 um 14:24 schrieb Fiona Ebner:
> Hi,
>
> Am 21.06.24 um 14:05 schrieb Gerd Hoffmann:
>> On Wed, Jun 19, 2024 at 11:21:14AM GMT, John Levon wrote:
>>> Older 32-bit Linux VMs (including Ubuntu 16.10) have issues with the
>>> 64-bit pci io window, failing during boot with errors like:
>>
>> Well. Why people would use *that* ubuntu version is not clear to me.
>> It's *loooooong* out of support. Even the LTS version from that year
>> (16.04) is not supported any more. But it is at least available for
>> download still, so I gave it a spin.
>>
>> Turns out it apparently can't deal with PCI bars mapped above 16TB (aka
>> 44 phys-bits). Test patch below.
>>
>> take care,
>> Gerd
>>
>> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
>> index bb44dc296047..a43876a931c9 100644
>> --- a/src/fw/pciinit.c
>> +++ b/src/fw/pciinit.c
>> @@ -1189,11 +1189,16 @@ pci_setup(void)
>>
>> if (CPUPhysBits) {
>> pci_mem64_top = 1LL << CPUPhysBits;
>> - if (CPUPhysBits > 46) {
>> - // Old linux kernels have trouble dealing with more than 46
>> - // phys-bits, so avoid that for now. Seems to be a bug in the
>> - // virtio-pci driver. Reported: centos-7, ubuntu-18.04
>> - pci_mem64_top = 1LL << 46;
>> + if (CPUPhysBits > 44) {
>> + // Old linux kernels have trouble dealing with more than 44/46
>> + // phys-bits. Seems to be a bug in the virtio-pci driver.
>> + // 46: centos-7, ubuntu-18.04
>> + // 44: ubuntu-16.04
>> + // Limit the used address space to mitigate the bug, except we
>> are
>> + // running in a guest with more than 1TB of memory installed.
>> + if (RamSizeOver4G < (1LL << 40)) {
>> + pci_mem64_top = 1LL << 44;
>> + }
>> }
>> }
>>
>
> we've also had two reports about issues with 32-bit guests now[0][1]
> (both had '-m 4096' in the QEMU commandline), which I was able to
> reproduce with a 32-bit Debian 12.6 install, so nothing ancient ;) The
> QEMU commandline is below[2].
>
> Unfortunately, it still fails to boot, even with the "limit address
> space used for pci devices, part two" patch applied on top of rel-1.16.3
> (and using current QEMU master).
>
> It boots fine with '-m 3583', but not anymore with '-m 3584'. So is
> bumping the limit for the check necessary after all?
>
Sorry for bumping this again, but we got a new report about OpenBSD 7.6
being affected too (see [3] and the following posts in the forum
thread). In particular, the user reports a regression with PCIe
passthrough failing and seeing "mem address conflict" messages in dmesg.
I could reproduce the latter using [4], i.e. seeing the messages and
checked that it is caused by 96a8d130 ("be less conservative with the
64bit pci io window"). The user reported that using 2 GiB of RAM makes
the passthrough work again and the messages disappear.
The messages are still present when I test with current SeaBIOS master
2424e4c0 ("esp-scsi: indicate acceptance of MESSAGE IN phase data") and
QEMU v9.1.1.
Note that I also get the messages without the vfio-pci device, but since
I wasn't able to reproduce the passthrough failure, it is what I have to
work with.
Best Regards,
Fiona
[3]: https://forum.proxmox.com/threads/149772/post-713842
[4]: https://ftp2.eu.openbsd.org/pub/OpenBSD/7.6/amd64/install76.iso
QEMU commandline with which I observed the messages:
> ./qemu-system-x86_64 \
> -accel kvm \
> -pidfile /var/run/qemu-server/122.pid \
> -chardev
> 'socket,id=qmp,path=/var/run/qemu-server/122.qmp,server=on,wait=off' \
> -mon 'chardev=qmp,mode=control' \
> -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' \
> -mon 'chardev=qmp-event,mode=control' \
> -smp '8,sockets=1,cores=8,maxcpus=8' \
> -nodefaults \
> -vnc 'unix:/var/run/qemu-server/122.vnc,password=on' \
> -cpu host \
> -m 4096 \
> -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' \
> -device 'vfio-pci,host=0000:00:1b.0,id=hostpci0,bus=pci.0,addr=0x10' \
> -device 'VGA,id=vga,bus=pci.0,addr=0x2' \
> -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1' \
> -drive 'file=/dev/zvol/zfs/vm-122-disk-0,if=none,id=drive-scsi0,format=raw'
> \
> -device
> 'scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100'
> \
> -machine 'type=pc'
>
> [0]: https://forum.proxmox.com/threads/150217/
> [1]: https://forum.proxmox.com/threads/149772/post-683562
> [2]:
>
>> ./qemu-system-x86_64 \
>> -accel 'kvm' \
>> -cpu 'host' \
>> -chardev
>> 'socket,id=qmp,path=/var/run/qemu-server/121.qmp,server=on,wait=off' \
>> -mon 'chardev=qmp,mode=control' \
>> -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' \
>> -mon 'chardev=qmp-event,mode=control' \
>> -pidfile /var/run/qemu-server/121.pid \
>> -smp '4,sockets=1,cores=4,maxcpus=4' \
>> -nodefaults \
>> -vnc 'unix:/var/run/qemu-server/121.vnc,password=on' \
>> -m 4096 \
>> -device 'pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5' \
>> -device 'VGA,id=vga,bus=pci.0,addr=0x2' \
>> -device 'virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1' \
>> -drive
>> 'file=/dev/lvmthinbig/vm-121-disk-0,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'
>
> _______________________________________________
> SeaBIOS mailing list -- seabios@seabios.org
> To unsubscribe send an email to seabios-le...@seabios.org
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
