Re: [Qemu-devel] [PULL 12/23] virtio: use VRingMemoryRegionCaches for avail and used rings

[Laszlo Ersek <lersek@redhat.com>]

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