public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Erik Brakkee <erik@brakkee.org>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Kenni Lund <kenni@kelu.dk>, kvm <kvm@vger.kernel.org>
Subject: Re: USB Passthrough 1.1 performance problem...
Date: Tue, 14 Dec 2010 22:47:35 +0100	[thread overview]
Message-ID: <4D07E5F7.1000400@brakkee.org> (raw)
In-Reply-To: <20101214120519.GH32153@redhat.com>

Daniel P. Berrange wrote:
> On Tue, Dec 14, 2010 at 12:55:04PM +0100, Kenni Lund wrote:
>    
>> 2010/12/14 Erik Brakkee<erik@brakkee.org>:
>>      
>>>> From: Kenni Lund<kenni@kelu.dk>
>>>> 2010/12/14 Erik Brakkee<erik@brakkee.org>:
>>>>          
>>>>>> From: Kenni Lund<kenni@kelu.dk>
>>>>>>              
>>>>>>> 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.





  reply	other threads:[~2010-12-14 21:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-12 11:47 USB Passthrough 1.1 performance problem Erik Brakkee
2010-12-12 20:59 ` Erik Brakkee
2010-12-12 22:16   ` Jan Kiszka
2010-12-12 22:31     ` Erik Brakkee
2010-12-13  8:25       ` Alexander Graf
2010-12-14 10:02         ` Avi Kivity
2010-12-14 10:11           ` Alexander Graf
2010-12-31 17:00           ` Kevin O'Connor
2010-12-13 23:27       ` Jan Kiszka
2010-12-13 23:50       ` Kenni Lund
     [not found]         ` <3047113345.976756218@brakkee.org>
2010-12-14  0:47           ` Kenni Lund
     [not found]             ` <5085473063.976781602@brakkee.org>
2010-12-14 11:55               ` Kenni Lund
2010-12-14 12:05                 ` Daniel P. Berrange
2010-12-14 21:47                   ` Erik Brakkee [this message]
2010-12-14 23:44                     ` Kenni Lund
2010-12-16 16:23                       ` Erik Brakkee
2010-12-16 21:46                         ` Erik Brakkee
2010-12-24 18:19                           ` Erik Brakkee
2010-12-13 10:36 ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D07E5F7.1000400@brakkee.org \
    --to=erik@brakkee.org \
    --cc=berrange@redhat.com \
    --cc=kenni@kelu.dk \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox