All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.