On 02/21/17 13:57, Gerd Hoffmann wrote:
> On Fr, 2017-02-17 at 21:54 +0200, Michael S. Tsirkin wrote:
>> From: Paolo Bonzini <pbonz...@redhat.com>
>>
>> The virtio-net change is necessary because it uses virtqueue_fill
>> and virtqueue_flush instead of the more convenient virtqueue_push.
>>
>> Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
>> Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
>> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
>
> This change breaks ovmf for me, although it isn't obvious to me why.
> Bisect landed here, and reverting indeed makes things going again.
I looked at the patch (on the list) and I don't have the slightest idea
what's going on. I read the word "cache" in it, so I guess it introduces
(or exposes) some cache coherency issue.
> 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.
That's very strange (especially given the OVMF log below).
> 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.
The next action would be the EfiBootManagerRefreshAllBootOption()
function call in PlatformBootManagerAfterConsole(), in file
"OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c".
That function (from "MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c")
"enumerates all boot options, creates them and registers them in the
BootOrder variable". While doing that, it definitely looks (indirectly)
at any UEFI-bootable virtio-scsi or virtio-blk device.
The direct symptom you are seeing ("qemu just exits / shuts down") is
inexplicable. If there were a virtio-de-sync between guest and host, I'd
expect OVMF to hang, and/or emit error messages.
Thanks
Laszlo
