Am 17.05.23 um 07:59 schrieb Gerd Hoffmann: > > On Tue, May 16, 2023 at 04:00:55PM +0200, Fiona Ebner wrote: >> >> 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. > > So the system makes it successfully though the firmware boot phase, > but then the kernel fails to initialize the virtio devices, correct? Yes. >> Happy to provide more information and relevant parts of debug logs. > > Kernel logs should give a clue what is going on. Should've thought of that :) I changed the configuration now and attached the boot drive differently, so that I can get the log, while adding a second dummy disk via virtio-scsi-pci. The errors for the virtio devices are: > virtio_scsi virtio1: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 > virtio_scsi: probe of virtio1 failed with error -22 > virtio_net virtio2: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 > virtio_net: probe of virtio2 failed with error -22 Attached are kern.log and lspci -vvv output for a boot with stable202302 with (files with "bad") and without (files with "good") the call to PlatformDynamicMmioWindow. In the kern.log, I didn't really see any interesting differences, except for the errors above. The addresses are different and there is now a 64-bit bridge window, but I guess that's expected. > *************** > *** 418,423 **** > --- 418,424 ---- > pci 0000:00:1e.0: PCI bridge to [bus 01] > pci 0000:00:1e.0: bridge window [io 0xd000-0xdfff] > pci 0000:00:1e.0: bridge window [mem 0xc1200000-0xc13fffff] > + pci 0000:00:1e.0: bridge window [mem 0x700000000000-0x700fffffffff 64bit pref] > acpiphp: Slot [0-2] registered > acpiphp: Slot [1-2] registered > acpiphp: Slot [2-2] registered > *************** Not sure if this is interesting either, but part of the diff between the lspci outputs (first with the call, second without the call): > *************** > *** 75,88 **** > 00:05.0 SCSI storage controller: Red Hat, Inc Virtio SCSI > Subsystem: Red Hat, Inc Virtio SCSI > Physical Slot: 5 > ! Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 > Interrupt: pin A routed to IRQ 10 > Region 0: I/O ports at 1040 [size=64] > Region 1: Memory at c1472000 (32-bit, non-prefetchable) [size=4K] > ! Region 4: Memory at 800004000 (64-bit, prefetchable) [size=16K] > ! Capabilities: [98] MSI-X: Enable+ Count=7 Masked- > Vector table: BAR=1 offset=00000000 > PBA: BAR=1 offset=00000800 > Capabilities: [84] Vendor Specific Information: VirtIO: > --- 75,88 ---- > 00:05.0 SCSI storage controller: Red Hat, Inc Virtio SCSI > Subsystem: Red Hat, Inc Virtio SCSI > Physical Slot: 5 > ! Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 > Interrupt: pin A routed to IRQ 10 > Region 0: I/O ports at 1040 [size=64] > Region 1: Memory at c1472000 (32-bit, non-prefetchable) [size=4K] > ! Region 4: Memory at 702000004000 (64-bit, prefetchable) [size=16K] > ! Capabilities: [98] MSI-X: Enable- Count=7 Masked- > Vector table: BAR=1 offset=00000000 > PBA: BAR=1 offset=00000800 > Capabilities: [84] Vendor Specific Information: VirtIO: > *************** Best Regards, Fiona