From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik Brakkee Subject: Re: USB Passthrough 1.1 performance problem... Date: Tue, 14 Dec 2010 22:47:35 +0100 Message-ID: <4D07E5F7.1000400@brakkee.org> References: <4D04B645.3010100@brakkee.org> <4D0537A8.8000607@brakkee.org> <4D0549AA.2020007@web.de> <4D054D37.7040107@brakkee.org> <3047113345.976756218@brakkee.org> <5085473063.976781602@brakkee.org> <20101214120519.GH32153@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Kenni Lund , kvm To: "Daniel P. Berrange" Return-path: Received: from cpsmtp-fia01.kpnxchange.com ([195.121.247.4]:4982 "EHLO cpsmtp-fia01.kpnxchange.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757521Ab0LNVrb (ORCPT ); Tue, 14 Dec 2010 16:47:31 -0500 In-Reply-To: <20101214120519.GH32153@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Daniel P. Berrange wrote: > On Tue, Dec 14, 2010 at 12:55:04PM +0100, Kenni Lund wrote: > >> 2010/12/14 Erik Brakkee: >> >>>> From: Kenni Lund >>>> 2010/12/14 Erik Brakkee: >>>> >>>>>> From: Kenni Lund >>>>>> >>>>>>> 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 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.