[vfio-users] USB controller no longer being released properly by QEmu/vfio

[Marcel Bieberbach]

Possibly unrelated, I've got another strange behavior with the same 
device: my xHCI Controller on address 00:14.0 (vfio-handled, allocated 
on boot) gets assigned to the wrong VM, after I shutdown a linux VM 
which it was assigned to. It either connects to a running Windows VM 
which it is *not* assigned to, or if that is not running, to nothing at 
all, even if I start another Windows VM which it *should* be assigned 
to. This Windows VM can only get the controller after a fresh boot of 
the host. The assigned Linux VM however can claim the device again.

I haven't had time yet to look more into this, e.g. how it behaves with 
manually or automatically disconnecting the controller from the vfio 
module, but first log views didn't reveal any anomalies.

For me the problem started either with the use of the linux-vm, or with 
an upgrade to qemu-git, at least 2-3 weeks ago.

Oh and I just destroyed the Linux guest, in that case I could start the 
windows guest having my usb soundcard. So I think our problems *are* 
related, I just get no log output because I have vfio permanently 
assigned to the 8086:1e31 device.
Difference: in my case the Windows VM can be shut down normally, only 
the shutdown of the Linux VM triggers the problem, but if I boot exactly 
this VM, it gets the device back.
Furthermore, if once triggered, the controller jumps to another running 
VM it isn't assigned to.

Good to know I'm not the only one affected, but I can't help yet. I can 
only tell it seems device-specific, as we share similar problems with it 
and my graphic cards behave normally.

Regards

On 03.05.2016 20:35, Nicolas Roy-Renaud wrote:
>
> Up until about a week ago, I could pass through the USB controller for 
> my front panel to my gaming VM and it would work just fine. Since 
> then, though, and I'm not exactly sure what triggered it, it appears 
> as if said controller isn't properly being released by the VM when it 
> shuts down on its own (i.e : When I initiate a shutdown from within 
> the guest and let it complete). Interestingly, getting libvirt to 
> destroy the VM works just fine, and I can reboot without issues this way.
>
> On a "bad" shut down, virt-manager says the VM is "Shutting down" and 
> won't let me do anything with it. Trying to use virsh directly doesn't 
> seem to do anything, as the operation just blocks forever. Trying to 
> restart libvirtd only makes it unresponsive. The Qemu logs for the VM 
> themselves have this interesting bit :
>
>     vfio : Cannot reset device 0000:00:14.0, no available reset mechanism
>
> Going back to earlier entries makes it seem like the USB controller 
> always did this, although this line would usually be followed by 
> something like this :
>
>     terminating on signal 15 prom pid 8360
>
> This no longer appears in newer entries.
>
> Trying to do a device remove/rescan blocks the shell with an 
> unkillable task, while dmesg outputs this :
>
>     vfio-pci 0000:00:14.0: Relaying device request to user (#0)
>     vfio-pci 0000:00:14.0: Relaying device request to user (#10)
>     vfio-pci 0000:00:14.0: Relaying device request to user (#20)
>     vfio-pci 0000:00:14.0: Relaying device request to user (#30)
>     vfio-pci 0000:00:14.0: Relaying device request to user (#40)
>     vfio-pci 0000:00:14.0: Device is currently in use, task "bash" (2030) blocked until device is released
>
> Until I try to run that remove/rescan, the lspci still lists the 
> device with this entry, which goes away after that even though the 
> operation seemingly never completes :
>
>     00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
>     	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7758]
>     	Kernel driver in use: xhci_hcd
>     	Kernel modules: xhci_pci
>
> It looks just the same when the controller is attached to the host, 
> even though none of what's plugged into it is listed by lsusb after I 
> shutdown the VM.
>
> Can anyone tell me what's going on? I feel like I'm closing in on the 
> solution, but I'm really not sure where to go from here.
>
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160504/533c68fc/attachment.htm>