Daniel P. Berrange wrote:
On Tue, Dec 14, 2010 at 12:55:04PM +0100, Kenni Lund wrote:
2010/12/14 Erik Brakkee<erik@xxxxxxxxxxx>:
From: Kenni Lund<kenni@xxxxxxx>
2010/12/14 Erik Brakkee<erik@xxxxxxxxxxx>:
From: Kenni Lund<kenni@xxxxxxx>
Does this mean I have a chance now that PCI passthrough of my WinTV
PVR-500
might work now?
Passthrough of a PVR-500 has been working for a long time. I've been
running with passthrough of a PVR-500 in my HTPC, since
November/December 2009...so it should work with any recent kernel and
any recent version of qemu-kvm you can find today - No patching
needed. The only issue I had with the PVR-500 card, was when *I*
didn't free up the shared interrupts...once I fixed that, it "just
worked".
How did you free up those shared interrupts then? I tried different slots
but always get conflicts with the USB irqs.
I did an unbind of the conflicting device (eg. disabled it). I moved
the PVR-500 card around in the different slots and once I got a
conflict with the integrated sound card, I left the PVR-500 card in
that slot (it's a headless machine, so no need for sound) and
configured unbind of the sound card at boot time. On my old system I
think it was conflicting with one of the USB controllers as well, but
it didn't really matter, as I only lost a few of the ports on the back
of the computer for that particular USB controller - I still had
plenty of USB ports left and if I really needed more ports, I could
just plug in an extra USB PCI card.
My /etc/rc.local boot script looks like the following today:
--
#Remove HDA conflicting with ivtv1
echo "0000:00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind
# ivtv0
echo "4444 0016"> /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:04:08.0"> /sys/bus/pci/drivers/ivtv/unbind
echo "0000:04:08.0"> /sys/bus/pci/drivers/pci-stub/bind
echo "4444 0016"> /sys/bus/pci/drivers/pci-stub/remove_id
# ivtv1
echo "4444 0016"> /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:04:09.0"> /sys/bus/pci/drivers/ivtv/unbind
echo "0000:04:09.0"> /sys/bus/pci/drivers/pci-stub/bind
echo "4444 0016"> /sys/bus/pci/drivers/pci-stub/remove_id
I did not try unbinding the usb device so I can also try that.
I don'.t understand what is happening with the 4444 0016. I configured the
pci card in kvm and I believe kvm does the binding to pci-stub in recent
versions. Where is the 4444 0016%oming from?
Okay, qemu-kvm might do it today, I don't know - I haven't changed
that script for the past year. But are you sure that it's not
libvirt/virsh/virt-manager which does that for you?
If you use the managed="yes" attribute on the<hostdev> in libvirt
XML, then libvirt will automatically do the pcistub bind/unbind,
followed by a device reset at guest startup& the reverse at shutdown.
If you have conflicting devices on the bus though, libvirt won't
attempt to unbind them, unless you had also explicitly assigned all
those conflicting devices to the same guest.
Daniel
I definitely have to try again (right now having some stability problems
on the server that I am debugging).
The shared IRQs are as follows:
16: 0 0 0 0 0
0 0 0 IO-APIC-fasteoi uhci_hcd:usb3
18: 252995 0 0 0 0
0 0 0 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb8, ivtv0
19: 58281 0 0 0 0
0 0 0 IO-APIC-fasteoi ata_piix, ata_piix,
uhci_hcd:usb5, uhci_hcd:usb7, ivtv1
21: 0 0 0 0 0
0 0 0 IO-APIC-fasteoi uhci_hcd:usb4
23: 713 6906 0 76919 0
0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
So I have IRQ sharing with usb1, usb8, usb5, usb7. I have also read that
ehci refers to USB 2.0 and uhci to USB 1.1 is that correct? Anyway, how
would I now identify the USB PCI devices that I would need to unbind to
get rid of the sharing with the USB ports? It also doesn't really matter
in which slot I put the PVR-500 card because both cards share IRQs with
USB in all cases.
I have also used an add on USB PCI card but still got these conflicts. I
was considering to get a PCIe USB card instead to try out in the hope
that that would use different IRQs. Is that a realistic expectation?
That way, I could disable all on-board USB (in the BIOS even) and use
the add-on USB only.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
