Re: USB Passthrough 1.1 performance problem...

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

Am 12.12.2010 21:59, Erik Brakkee wrote:
> Erik Brakkee wrote:
>> Hi,
>>
>>
>> I am using a tv card in a VM and get jerky video.As I understand it,
>> the VM is using USB 1.1. However, when I set the USB controller in the
>> BIOS of my server to Fullspeed (12 Mbit/s) which is the USB 1.1 speed
>> I am able to get perfect results on the host but still on the guest
>> the video is jerky.

USB-passthrough at device level implies USB host controller emulation.
This comes with some overhead and will probably never reach native
performance. Virtualization also comes with occasion high latency spikes
(due to host activity delaying time-critical guest jobs). Those issues
are inherent. Moreover, you may run into emulation bugs, but they are
fixable in principle.

>>
>> Are there some tuning parameters I can use or perhaps even kernel
>> configuration paramters on the host to solve this?
>>
>> Cheers
>>   Erik
>>
>> Host:    Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
>>              OS: Opensuse 11.3 64 bit
>>
>> Guest:   OS: Opensuse 11.3 64 bit
> I can say now that I am giving up on getting this to work. One
> alternative was to use PCI passthrough the USB hardware,  but that
> didn't work for the USB that was on the motherboard. So I bought a USB
> PCI card and tried to use PCI passthrough for that. Unfortunately other
> problems occured there.
> 
> For one, the problem with 4K alignment. But I could fix that by using
> the pci=resource_alignment=... kernel parameter. In my grub/menu.lst it
> says:
> 
>    kernel /vmlinuz-2.6.34.7-0.5-default root=/dev/hsystem/root quiet
>    showopts intel_iommu=on
>    pci=resource_alignment=01:04.0;01:04.1;01:04.2 noirqdebug vga=0x31a
> 
> 
> The noirqdebug flas was needed to avoid the host from disabling the IRQ
> (it was a shared IRQ).
> 
> Using this, I could configure PCI passthrough and start the VM. Also the
> USB device showed up there. Only it did not work at all.
> 
> Here is a summary of my journey up until know:
> 
> The original approach I wanted to use was to pass my old PCI card (WinTV
> PVR-500) to a VM. This card is a well supported card and has been doing
> fine for me. Because of the PCI passthrough problems with the wintv
> card, I decided to try a USB card instead. This gave me a 'ctrl buffer
> too small' issue that I could solve by taking the source RPM for kvm and
> applying a known patch from red hat (increasing buffer size from 2048 to
> 8192). But then I got jerky video, probably due to USB 1.1 issues. To
> bypass these I could use PCI passthrough for USB. But with the PCI
> passthrough of this card I am again running into issues probably related
> to Shared IRQs. So, after all this I am back to square one.
> 
> I have now modified my approach so instead of running a separate minimal
> host with my old server as a guest, I am now running the old server
> (same install) on the new hardware, using it as a host. I would
> definitely be interested in trying this out further in the future. I
> even tried Xen for a brief moment, only to realize that my host and
> guest felt slower (slower startup and execution) and much more difficult
> to handle.
> 
> From the experience of the last two days fulltime trying to get things
> working I can only conclude that the following two features would be
> really important to have:
> 
>    * Extended PCI passthrough support
>          o shared IRQ support

Addressed by the series I sent out today.

>          o supporting cases where memory is not aligned on a 4K boundary

Hmm, I'm seeing warnings here when passing through one of my EHCIs, but
no fatal errors.

>    * USB passthrough
>          o support USB 2.0
>          o support USB 3.0 (but taking one step at a time, 2.0 would
>            also be great).

Note that this will not solve any real-time issue (if that is part of
your problem). E.g.: While my EHCIs work nicely in PCI-passthrough
scenarios, I'm unable to use certain webcams that sooner or later run
out of sync.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]