Re: PCI Passthrough, error: The driver 'pci-stub' is occupying your device 0000:08:06.2

Chris Wright
2011-02-25T00:00:16Z

* James Neave (roboj1m@gmail.com) wrote:
> libvirtError: this function is not supported by the connection driver:
> Unable to reset PCI device 0000:00:14.4: no FLR, PM reset or bus reset
> available

Right, libvirt is more restrictive than qemu-kvm (forgot you were using
libvirt here).

> There is nothing written to test.log when you try to start the VM with
> 00:14.4 attached.
>
> At this point libvirt goes screwy and I have to restart it before I
> can remove 00:14.4 from the VM.

I assume this means that 00:14.4 is still left claimed by pci-stub?

> Failed to assign irq for "hostdev0": Operation not permitted
> Perhaps you are assigning a device that shares an IRQ with another device?
> kvm: -device pci-assign,host=08:06.0,id=hostdev0,configfd=58,bus=pci.0,addr=0x6:

Believe it or not this is progress ;) You have passed the point that
it was failing before (the iommu domain issue). Trouble now is that
with shared IRQ we don't have a good way to handle that right now.

> Device 'pci-assign' could not be initialized

> 2011-02-23 19:21:13.958: shutting down
>
> dmesg:
> http://pastebin.com/70D26xp4
>
> This bit is different:
>
> [ 201.625221] uhci_hcd 0000:08:06.0: remove, state 4
> [ 201.625237] usb usb4: USB disconnect, address 1
> [ 201.625514] uhci_hcd 0000:08:06.0: USB bus 4 deregistered
> [ 201.625595] uhci_hcd 0000:08:06.0: PCI INT A disabled
> [ 201.626028] pci-stub 0000:08:06.0: claimed by stub
> [ 201.631922] uhci_hcd 0000:08:06.1: remove, state 4
> [ 201.631937] usb usb9: USB disconnect, address 1
> [ 201.632195] uhci_hcd 0000:08:06.1: USB bus 9 deregistered
> [ 201.632274] uhci_hcd 0000:08:06.1: PCI INT B disabled
> [ 201.632419] pci-stub 0000:08:06.1: claimed by stub
> [ 201.638160] ehci_hcd 0000:08:06.2: remove, state 1
> [ 201.638172] usb usb10: USB disconnect, address 1
> [ 201.638178] usb 10-1: USB disconnect, address 2
> [ 201.721626] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully
> deinitialized and disconnected.
> [ 201.721990] ehci_hcd 0000:08:06.2: USB bus 10 deregistered
> [ 201.722126] ehci_hcd 0000:08:06.2: PCI INT C disabled
> [ 201.725042] pci-stub 0000:08:06.2: claimed by stub
> [ 201.731830] firewire_ohci 0000:08:0e.0: PCI INT A disabled
> [ 201.731838] firewire_ohci: Removed fw-ohci device.
> [ 201.732536] pci-stub 0000:08:0e.0: claimed by stub
> [ 202.303880] device vnet0 entered promiscuous mode
> [ 202.305184] virbr0: topology change detected, propagating
> [ 202.305193] virbr0: port 1(vnet0) entering forwarding state
> [ 202.305199] virbr0: port 1(vnet0) entering forwarding state
> [ 202.433007] pci-stub 0000:08:06.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 202.470076] pci-stub 0000:08:06.0: restoring config space at offset
> 0x1 (was 0x2100000, writing 0x2100001)
> [ 202.697270] assign device 0:8:6.0
> [ 202.697325] deassign device 0:8:6.0
> [ 202.730080] pci-stub 0000:08:06.0: restoring config space at offset
> 0x1 (was 0x2100000, writing 0x2100001)
> [ 202.730107] pci-stub 0000:08:06.0: PCI INT A disabled
>
> This time the pci-stub claimed lines are not all bunched up and there
> is only one per device, rather than three per device.
> Also for the first time it says "assign device 0:8:6.0" rather than
> "assign device 0:8:6.0 failed"
> It them immediately deassigns the device and stops.
>
> test.log shows:
>
> Failed to assign irq for "hostdev0": Operation not permitted
> Perhaps you are assigning a device that shares an IRQ with another device?
>
> lspsci -vv for the relevant devices shows:
> http://pastebin.com/EUtUMj8x
>
> 00:14.4 now appears to be using pci-stub as it's driver, as well as
> 08:06.1, 2, 3 but not 0e.0

How are you determining this? The lspci paste above has pci-stub for all
of them. The easiest thing might be to start with manually disabling
host driver and reassigning pci-stub to: 00:14.4, 08: 06.2,3 and 0e.0
Then giving the guest only 08:06.1.

> Anyway, that's all for now.

Thanks for testing.

> I think I'll try 'amd_iommu_dump' next, does it write to dmesg?

Yes it does.