On 02/21/17 19:08, Paolo Bonzini wrote: > > > On 21/02/2017 13:57, Gerd Hoffmann wrote: >> This change breaks ovmf for me, although it isn't obvious to me why. >> Bisect landed here, and reverting indeed makes things going again. >> >> Using q35 machine type, pcie virtio devices, with the rhel ovmf build >> (OVMF-20160608b-1.git988715a.el7.noarch). >> >> First thing I've tried is swapping virtio-net for another nic, >> suspecting this change might trigger a bug in the ovmf virtio-net >> driver, but that didn't change things. >> >> Effect is that qemu just exits, without logging some error, looks like a >> normal guest shutdown. Firmware log doesn't give a clue either, it just >> stops at some point, again without any error message. Here are the last >> lines of the log: >> >> SataControllerStart START >> SataControllerStart error return status = Already started >> SetPciIntLine: [00:1C.0] PciRoot(0x0)/Pci(0x1C,0x0) -> 0x0A >> SetPciIntLine: [01:00.0] PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0) -> 0x0A >> SetPciIntLine: [00:1C.1] PciRoot(0x0)/Pci(0x1C,0x1) -> 0x0A >> SetPciIntLine: [02:00.0] PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) -> 0x0A >> SetPciIntLine: [00:1C.2] PciRoot(0x0)/Pci(0x1C,0x2) -> 0x0A >> SetPciIntLine: [00:1C.3] PciRoot(0x0)/Pci(0x1C,0x3) -> 0x0A >> SetPciIntLine: [00:1C.4] PciRoot(0x0)/Pci(0x1C,0x4) -> 0x0A >> SetPciIntLine: [05:00.0] PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0) -> 0x0A >> SetPciIntLine: [05:00.1] PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x1) -> 0x0A >> SetPciIntLine: [05:00.2] PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x2) -> 0x0A >> SetPciIntLine: [00:1C.5] PciRoot(0x0)/Pci(0x1C,0x5) -> 0x0A >> SetPciIntLine: [06:00.0] PciRoot(0x0)/Pci(0x1C,0x5)/Pci(0x0,0x0) -> 0x0A >> SetPciIntLine: [00:1C.6] PciRoot(0x0)/Pci(0x1C,0x6) -> 0x0A >> SetPciIntLine: [00:1C.7] PciRoot(0x0)/Pci(0x1C,0x7) -> 0x0A >> SetPciIntLine: [00:1F.2] PciRoot(0x0)/Pci(0x1F,0x2) -> 0x0A >> SetPciIntLine: [00:1F.3] PciRoot(0x0)/Pci(0x1F,0x3) -> 0x0A >> Select Item: 0x8 >> Select Item: 0x17 >> qemu -kernel was not used. > > Command line? I tried with > > x86_64-softmmu/qemu-system-x86_64 \ > -pflash /usr/share/edk2/ovmf/OVMF_CODE.fd \ > -pflash /usr/share/edk2/ovmf/OVMF_VARS.fd \ > --enable-kvm -M q35 -debugcon stdio \ > -global isa-debugcon.iobase=0x402 \ > -net nic,model=virtio \ > -net bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0 \ > -snapshot foo.raw > > and after the above lines I get: > > Select Item: 0x19 > [Bds]OsIndication: 0000000000000000 > [Bds]=============Begin Load Options Dumping ...============= > Driver Options: > SysPrep Options: > Boot Options: > Boot0000: UiApp 0x0109 > Boot0001: UEFI QEMU DVD-ROM QM00005 0x0001 > Boot0002: UEFI QEMU HARDDISK QM00001 0x0001 > Boot0003: EFI Internal Shell 0x0001 > PlatformRecovery Options: > PlatformRecovery0000: Default PlatformRecovery 0x0001 > > (but I'm using a different OVMF build, > edk2-ovmf-20161105git3b25ca8-2.fc25.noarch; dinner time now).
The bug reproduces for me with current upstream OVMF. I sent a full QEMU backtrace (SIGSEGV) in another message. I use libvirt (and I assume Gerd does that too, because otherwise the shell would report the SIGSEGV immediately). Interestingly, in that call stack, I see pflash_update -> blk_pwrite -> blk_prw -> aio_poll -> ... -> virtio_queue_host_notifier_aio_poll. Therefore the direct trigger seems to be a UEFI variable update, but I don't understand how that lands in virtio code in QEMU. Thanks Laszlo
