Re: PCI passthrough resource remapping

[Chris Wright <chrisw@redhat.com>]

* Kenni Lund (kenni@kelu.dk) wrote:
> 2010/3/30 Chris Wright <chrisw@redhat.com>:
> > * Kenni Lund (kenni@kelu.dk) wrote:
> >> Client dmesg: http://pastebin.com/uNG4QK5j
> >> Host dmesg: http://pastebin.com/jZu3WKZW
> >>
> >> I just verified it and I do get the call trace in the host (which
> >> disables IRQ 19, used by the PCI USB card), exactly at the same second
> >
> > It looks like IRQ 19 is shared between the ehci controller and the
> > ivtv tuner.  What do you see in /proc/interrupts on the host (before
> > you unbind and after you bind to pci stub)?
> 
> Ahh, and even if the ivtv module is not loaded, I will still have a
> shared IRQ, right? I didn't see ivtv in /proc/interrupts before, as I
> unload the ivtv driver on boot in /etc/rc.local, before unbinding the
> ivtv tuner and binding it to pci stub. (the ivtv tuner is normally
> assigned to the same guest, but not now while testing the PCI USB
> card).
> 
> If I don't unload (and unbind/bind) the ivtv driver/tuner on boot in
> /etc/local, I get the following in /proc/interrupts on a clean boot:
> http://pastebin.com/SFQj58LC
> 
> If I now unbind and bind the PCI USB card to pci stub, I get no
> changes in /proc/interrupts.

Sorry, I meant bind to pci_stub and launch guest.  IOW, you should see
kvm_assigned_{msi,msix,intx}_device (from your lspci, I'd expect intx).

What's odd is a device is asserting an interrupt to a line w/ no handler
acking.  The IRQ 19, should have kvm handling the interrupt, in which
case it'd always return IRQ_HANDLED.  And for the case of shared
interrupts, we won't let you start the guest with an assigned device
that's sharing an interrupt.  IOW, we do request_irq() w/out specifying
IRQF_SHARED (meaning we want an exclusive irq).

> So I suppose I'll need to get rid of this shared IRQ before I can
> conclude anything on the patch in git. Hmm, is there some cleaver way
> of fixing this in Linux, or do I have to fix it by changing BIOS IRQ
> settings, disabling hardware and/or moving the hardware around in
> various PCI slots?

The way I typically work around this is simply unbinding the driver from
the device in the host (and thus freeing the irq).

thanks,
-chris