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

[S B]

Ah ok,

I thought so, but wasn't sure about it.
I am pretty good at C, but I know nothing about the PCI-Bus. What do you
think how much time does it take to get familiar with it to fix such
problems?


So, what I did:

lspci -vvvxxxx > lspci_1

I start win8 VM with crimson driver:
/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 vm is working fine.
The new dmesg output is in dmesg_cmd_1

lspci -vvvxxxx > lspci_2

Now I started the same command again. The screen stays black, so after a
while I kill qemu.
The new dmesg output is in dmesg_cmd_2

lspci -vvvxxxx > lspci_3


The D3 stuff appears only when booting arch linux guest after windows
guest, I describe it in my next mail.


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/0348f7ea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_1
Type: application/octet-stream
Size: 1808 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/0348f7ea/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_cmd_2
Type: application/octet-stream
Size: 856 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160108/0348f7ea/attachment-0001.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/0348f7ea/attachment-0002.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/0348f7ea/attachment-0003.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/0348f7ea/attachment-0004.obj>