[vfio-users] OVMF: Boots only first time after driver installation

S B sb9sb0 at gmail.com
Fri Jan 8 19:52:35 UTC 2016 

So, this time I mixed up arch linux guest with win8 guest.


lspci -vvvxxxx > lspci_1

/usr/bin/qemu-system-x86_64
    -enable-kvm -M pc-i440fx-2.4 -cpu host,kvm=off -smp
3,sockets=1,cores=3,threads=1 -m 4096
    -soundhw hda -serial none -parallel none -name Wingame -rtc
base=localtime  -redir tcp:22::22  -vga none -nographic -display none
    -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on
    -device vfio-pci,host=01:00.1,addr=09.1
    -drive
if=pflash,format=raw,readonly,file=/root/qemu/win8/OVMF_CODE-pure-efi.fd
    -drive if=pflash,format=raw,file=/root/qemu/win8/my_vars.fd
    -readconfig /root/qemu/config/ich9-ehci-uhci.cfg
    -device usb-host,vendorid=0x0079,productid=0x0006
    -device usb-host,vendorid=0x045e,productid=0x028e
    -device usb-host,vendorid=0x062a,productid=0x0252
    -device usb-host,vendorid=0x04f3,productid=0x0103
    -drive file=/root/qemu/arch.qcow2,id=win,format=qcow2,if=none
    -device ide-hd,bus=ide.0,drive=win
    -boot c

The arch linux guest is working fine.
The new dmesg output is in dmesg_cmd_1

lspci -vvvxxxx > lspci_2

/usr/bin/qemu-system-x86_64
    -enable-kvm -M pc-i440fx-2.4 -cpu host,kvm=off -smp
3,sockets=1,cores=3,threads=1 -m 4096
    -soundhw hda -serial none -parallel none -name Wingame -rtc
base=localtime  -vga none -nographic -display none
    -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on
    -device vfio-pci,host=01:00.1,addr=09.1
    -drive
if=pflash,format=raw,readonly,file=/root/qemu/win8/OVMF_CODE-pure-efi.fd
    -drive if=pflash,format=raw,file=/root/qemu/win8/my_vars.fd
    -readconfig /root/qemu/config/ich9-ehci-uhci.cfg
    -device usb-host,vendorid=0x0079,productid=0x0006
    -device usb-host,vendorid=0x045e,productid=0x028e
    -device usb-host,vendorid=0x062a,productid=0x0252
    -device usb-host,vendorid=0x04f3,productid=0x0103
    -drive file=/root/qemu/win8/win8.qcow2,id=win,format=qcow2,if=none
    -device ide-hd,bus=ide.0,drive=win
    -boot c

The win8 guest is working fine.
The new dmesg output is in dmesg_cmd_2

lspci -vvvxxxx > lspci_3

Now I start the first qemu command again. The screen stays off, I can ssh
to the VM and shut it down. qemu outputs:
qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3
qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3
qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3
qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3
qemu-system-x86_64: vfio-pci: Cannot read device rom at 0000:01:00.0
Device option ROM contents are probably invalied (check dmesg).
Skip option ROM probe with rombar=0, or load from file with romfile=


The new dmesg output is in dmesg_cmd_3
lspci -vvvxxxx > lspci_4


I start the second qemu command again. The VM is not starting. qemu outputs
qemu-system-x86_64: -device
vfio-pci,host=01:00.0,addr=09.0,multifunction=on: vfio: Error failed to
setup INTx fd: Device or resource busy
qemu-system-x86_64: -device
vfio-pci,host=01:00.0,addr=09.0,multifunction=on: Device initialization
failed


The new dmesg output is in dmesg_cmd_4
lspci -vvvxxxx > lspci_5


If I start one of the commands again, the behavior stays the same.

2016-01-06 22:31 GMT+01:00 Alex Williamson <alex.l.williamson at gmail.com>:

> On Wed, Jan 6, 2016 at 12:05 PM, S B <sb9sb0 at gmail.com> wrote:
>
>> Thank you, I gziped the files, because they are really huge.
>> 21734 is the first working boot.
>> 21819 is the second boot, which does not work.
>>
>
> I think these are really only useful along with the trace-events file from
> your build tree, but if I knew you were just going to throw them up on the
> mailing list I would have discouraged it altogether.  This kind of tracing
> is mostly useful if the person with the problem intends to do the
> debugging, so you can tell what point things happen, make changes and try
> something else.  Imagine running strace on your browser and asking someone
> to tell you why a web page doesn't render properly from the logs, that's
> about the same degree of complexity.
>
> Unfortunately you have a Tonga based GPU, which like Fiji, seems to have
> some sort of reset problem.  We don't really know if the problem is with
> the hardware or something we're not accounting for when doing a bus reset.
> I'm talking with AMD about this, but I have no hardware, little time, and
> it's really not an "enable tracing and spot the problem" kind of issue.
>
> Some of the errors you've reported seem like the card is dead from a PCI
> perspective, the stuck in D3 stuff, having capabilities of 0xff and 0xffff,
> INTx conflicts, etc.  could you report the following:
>
> 1) Do a clean boot of the host, do not start the VM, and report the output
> of 'sudo lspci -vvvxxxx' (that's 3x 'v', not 'w')
> 2) Boot the VM fully and shut it down, again report the same lspci output
> 3) Attempt to start the VM again, report the behavior, report anything new
> in dmesg and again lspci output
> 4) Include the qemu commandline used for all of this as well
>
> Thanks,
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_1
Type: application/octet-stream
Size: 2972 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_2
Type: application/octet-stream
Size: 1729 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_3
Type: application/octet-stream
Size: 2527 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_4
Type: application/octet-stream
Size: 71807 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci_1
Type: application/octet-stream
Size: 163492 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci_2
Type: application/octet-stream
Size: 163441 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci_3
Type: application/octet-stream
Size: 163441 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci_4
Type: application/octet-stream
Size: 157780 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci_5
Type: application/octet-stream
Size: 157780 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/aeb7d52f/attachment-0008.obj>

More information about the vfio-users mailing list