[vfio-users] GPU instance ID not persistent on guest restart

[Abdulla Bubshait]

I checked the output of lspci. From what I could notice is an IRQ switch
between qemu cycles. Also, MSI seems to be disabled on subsequent guest
boots And ASPM goes from not supported to  ASPM L0s L1 on second boot. I
have attached the complete lspci output for all states

Prior to first qemu http://pastebin.com/Zh0KQ1xC
After first qemu http://pastebin.com/p1ipWsvJ
After second qemu http://pastebin.com/G96zhDna

One thing to note, I get this broken behaviour even if windows is restarted
within the same qemu instance.

On Mon, Sep 14, 2015 at 12:09 PM Alex Williamson <alex.williamson at redhat.com>
wrote:

> On Mon, 2015-09-14 at 15:54 +0000, Abdulla Bubshait wrote:
> > I can get my GPU to work well once per host reboot cycle. It would appear
> > on subsequent guest reboots the GPU instance ID changes slightly.
> >
> > This is what I get on my windows system:
> > Working
> > PCI\VEN_1002&DEV_7300&SUBSYS_0B361002&REV_C8\
> > On Reboot
> > PCI\VEN_1002&DEV_7300&SUBSYS_0B361002&REV_00\
> >
> > This results in the GPU not being detected as compatible by the driver
> and
> > defaults back to the microsoft display driver. That means the GPU is
> > detected properly only once per host reboot (or suspend). On subsequent
> > qemu restarts the GPU appears as an unsupported A-series APU, instead of
> an
> > r9 Fury.
> >
> > Is there something that could be done to keep the GPU persistent across
> > guest reboots?
>
> It's surprising that the driver wouldn't claim it if only the revision
> number is getting reset.  I thought most drivers don't really care about
> the revision ID.  Perhaps test whether anything else in config space is
> not quite right.  Try running:
>
> $ sudo lspci -vvvxxxx -s <bus:dev.fn>
>
> in the host and compare the output after the first VM boot to that after
> the second VM boot.  If it's only the chip revision we could probably
> quirk something, but that register is read-only according to the PCI
> spec, so it shouldn't be affected by a bus reset.  Thanks,
>
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150914/3e7d5424/attachment.htm>