USB Passthrough 1.1 performance problem...
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.
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
Quoted 7 lines · Erik Brakkee
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.
Are there some tuning parameters I can use or perhaps even kernel configuration paramters on the host to solve this?
Quoted 7 lines
Cheers
ErikHost: Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
OS: Opensuse 11.3 64 bitGuest: 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
o supporting cases where memory is not aligned on a 4K boundary
* 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).
From the above, PCI passthrough improvements are most important as they will also allow (cheap) workarounds for USB passthrough issues.
I am definitely interested in hearing about new releases from KVM. Is there a mailing list I should subscribe to get information about the latest releases without intermediate discussions? I would also be interested in using latest stable versions of KVM for opensuse. Is there any repository I can configure to get those?
Cheers
Erik
Quoted 9 lines · Erik Brakkee
Quoted 8 lines · Erik Brakkee
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.
Quoted 53 lines
Quoted 11 lines
Are there some tuning parameters I can use or perhaps even kernel configuration paramters on the host to solve this?
Cheers
ErikHost: Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
OS: Opensuse 11.3 64 bitGuest: 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=0x31aThe 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.
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 4 lines
* 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
Quoted 54 lines · Jan Kiszka
Quoted 54 lines
Quoted 4 lines
Are there some tuning parameters I can use or perhaps even kernel configuration paramters on the host to solve this?
Quoted 8 lines
Cheers
ErikHost: Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
OS: Opensuse 11.3 64 bitGuest: 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=0x31aThe 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.
Quoted 9 lines
Quoted 7 lines
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 supportAddressed by the series I sent out today.
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now? What version is this and where can I get this for opensuse?
I still have the setup I used for testing with the host OS still installed but not running so it would be really easy to try out new releases of KVM (it is not a serious production server after all but mainly used to run some websites and mailing lists).
Quoted 6 lines
Quoted 3 lines
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.
In my case, the domain just didn't start.
Btw. I was using 0.12.5 on opensuse 11.3 but could only find the sources for 0.12.3 on download.opensuse.org (perhaps I looked wrong) and I patched those for th 4K issue. PCI passthrough also did not work with my wintv pci card with KVM 0.12.5.
Quoted 6 lines
Quoted 6 lines
* 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).
Quoted 8 lines
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
Is your point in this case that USB in a VM based on PCI passthrough will always have problems when it comes to more real-time issues or does this only apply to USB passthrough? I can imagine that PCI passthrough is better since it uses hardware support. By the way, I have seen issues in the past whereby the tv card stopped working because of high load on the server running natively so real-time issues also exist apart from virtualization.
Apart from this, I am definitely interested in getting updates for KVM on opensuse. Is there a channel for that?
Quoted 70 lines · Erik Brakkee
Quoted 54 lines · Jan Kiszka
Quoted 54 lines
Quoted 4 lines
Are there some tuning parameters I can use or perhaps even kernel configuration paramters on the host to solve this?
Quoted 8 lines
Cheers
ErikHost: Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
OS: Opensuse 11.3 64 bitGuest: 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=0x31aThe 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.
Quoted 9 lines
Quoted 7 lines
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 supportAddressed by the series I sent out today.
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now? What version is this and where can I get this for opensuse?
I still have the setup I used for testing with the host OS still installed but not running so it would be really easy to try out new releases of KVM (it is not a serious production server after all but mainly used to run some websites and mailing lists).
Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.
In my case, the domain just didn't start.
Btw. I was using 0.12.5 on opensuse 11.3 but could only find the sources for 0.12.3 on download.opensuse.org (perhaps I looked wrong) and I patched those for th 4K issue. PCI passthrough also did not work with my wintv pci card with KVM 0.12.5.
The source rpm for the 11.3 update channel is here:
http://download.opensuse.org/update/11.3/rpm/src/kvm-0.12.5-1.2.1.src.rpm
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
* 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.
Quoted 4 lines
Quoted 3 lines
Jan
Is your point in this case that USB in a VM based on PCI passthrough will always have problems when it comes to more real-time issues or does this only apply to USB passthrough? I can imagine that PCI passthrough is better since it uses hardware support. By the way, I have seen issues in the past whereby the tv card stopped working because of high load on the server running natively so real-time issues also exist apart from virtualization.
IIRC the reason that PCI passthrough with EHCI performs as badly as it does is that BARs < 4k get passed through using the slow path (trap to qemu, issue MMIO in user space). Unfortunately, EHCI seems to have a 256 byte BAR region usually that is used for some handshaking:
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at c8014400 (32-bit, non-prefetchable) [size=256]
Quoted 1 line
Apart from this, I am definitely interested in getting updates for KVM on opensuse. Is there a channel for that?
The most current development version for the user space part is in the openSUSE build service on the Virtualization repo:
http://download.opensuse.org/repositories/Virtualization/openSUSE_11.3/
Please be aware that that version is less tested than the one delivered with the distribution :).
Alex
Quoted 5 lines · Alexander Graf
Quoted 2 lines
Quoted 1 line
Is your point in this case that USB in a VM based on PCI passthrough will always have problems when it comes to more real-time issues or does this only apply to USB passthrough? I can imagine that PCI passthrough is better since it uses hardware support. By the way, I have seen issues in the past whereby the tv card stopped working because of high load on the server running natively so real-time issues also exist apart from virtualization.
IIRC the reason that PCI passthrough with EHCI performs as badly as it does is that BARs< 4k get passed through using the slow path (trap to qemu, issue MMIO in user space). Unfortunately, EHCI seems to have a 256 byte BAR region usually that is used for some handshaking:
Quoted 8 lines
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory atc8014400(32-bit, non-prefetchable) [size=256]
That could certainly be optimized. If the BAR is all along in its page, both on guest and host (if not, we can migrate it, at least on the host), we can use the same offset within the page on the host as it appears on the guest, and assign the entire page.
We should make sure SeaBIOS uses a minimum alignment of 4k for mmio BARs.
Signature · 1 line
error compiling committee.c: too many arguments to function
Am 14.12.2010 um 11:02 schrieb Avi Kivity <[email protected]>:
Quoted 15 lines · Alexander Graf
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
Is your point in this case that USB in a VM based on PCI passthrough will always have problems when it comes to more real-time issues or does this only apply to USB passthrough? I can imagine that PCI passthrough is better since it uses hardware support. By the way, I have seen issues in the past whereby the tv card stopped working because of high load on the server running natively so real-time issues also exist apart from virtualization.
IIRC the reason that PCI passthrough with EHCI performs as badly as it does is that BARs< 4k get passed through using the slow path (trap to qemu, issue MMIO in user space). Unfortunately, EHCI seems to have a 256 byte BAR region usually that is used for some handshaking:
Quoted 8 lines
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory atc8014400(32-bit, non-prefetchable) [size=256]
Quoted 3 lines
That could certainly be optimized. If the BAR is all along in its page, both on guest and host (if not, we can migrate it, at least on the host), we can use the same offset within the page on the host as it appears on the guest, and assign the entire page.
We should make sure SeaBIOS uses a minimum alignment of 4k for mmio BARs.
Yep, I agree :). Back when I tried that, it seemed rather hard to change BAR mappings after init from user space. But it's certainly a thing the vfio stuff could easily tackle!
Alex
Quoted 6 lines · Avi Kivity
That could certainly be optimized. If the BAR is all along in its page, both on guest and host (if not, we can migrate it, at least on the host), we can use the same offset within the page on the host as it appears on the guest, and assign the entire page.
We should make sure SeaBIOS uses a minimum alignment of 4k for mmio BARs.
Shouldn't be too hard to do that.
-Kevin
src/pciinit.c +3 -0
@@ -10,6 +10,7 @@#include "biosvar.h" // GET_EBDA #include "pci_ids.h" // PCI_VENDOR_ID_INTEL #include "pci_regs.h" // PCI_COMMAND +#include "memmap.h" // PAGE_SIZE #include "dev-i440fx.h" #define PCI_ROM_SLOT 6
@@ -90,6 +91,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num) type ="prefmem" ; msg ="decrease BUILD_PCIMEM_SIZE and recompile. size %x" ; }else { +if (size <PAGE_SIZE ) + size =PAGE_SIZE ; r = &pci_bios_mem_region; type ="mem" ; msg ="increase BUILD_PCIMEM_SIZE and recompile." ;
Quoted 59 lines · Erik Brakkee
Quoted 58 lines · Jan Kiszka
Quoted 58 lines
Quoted 4 lines
Are there some tuning parameters I can use or perhaps even kernel configuration paramters on the host to solve this?
Quoted 8 lines
Cheers
ErikHost: Motherboard Supermicro X8DTi-F, Intel Xeon L5630, 12MB
OS: Opensuse 11.3 64 bitGuest: 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=0x31aThe 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:
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
* Extended PCI passthrough support
o shared IRQ supportAddressed by the series I sent out today.
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now?
What version is this and where can I get this for opensuse?
Currently you have to clone my git trees [1, 2], then build and install those to have the feature. Will take a while to see it in releases, and after that also Opensuse packages.
Jan
[1] git://git.kiszka.org/linux-kvm.git queues/dev-assign
[2] git://git.kiszka.org/qemu-kvm.git queues/dev-assign
2010/12/12 Erik Brakkee <[email protected]>:
Quoted 2 lines
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".
On the other hand, I've never had success with passthrough of USB. I've spend a bunch of time trying to get various USB cards to work with passthrough, I even purchased 3 USB cards, just to test USB passthrough with different brands, interfaces and versions (PCI, PCIe, USB 2.0, USB 3.0, etc). I gave up on that 5 months ago -
http://article.gmane.org/gmane.comp.emulators.kvm.devel/56719
Quoted 1 line
What version is this and where can I get this for opensuse?
I can't remember if I started out with the PVR-500 card with 0.11 or 0.12 ...I think it was 0.11...but anyway, you'll hopefully not run with such an old version today, so any version should work.
Best regards
Kenni
A message that is not in the archive (sent off-list or not yet received): [email protected]
2010/12/14 Erik Brakkee <[email protected]>:
Quoted 13 lines
Quoted 5 lines
From: Kenni Lund <[email protected]>
Quoted 3 lines
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500
might work now?Quoted 7 lines
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".
Quoted 2 lines
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 --
Best regards
Kenni
A message that is not in the archive (sent off-list or not yet received): [email protected]
2010/12/14 Erik Brakkee <[email protected]>:
Quoted 48 lines
Quoted 42 lines
From: Kenni Lund <[email protected]>
2010/12/14 Erik Brakkee <[email protected]>:Quoted 15 lines
Quoted 7 lines
From: Kenni Lund <[email protected]>
Quoted 4 lines
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500
might work now?Quoted 7 lines
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".
Quoted 2 lines
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.localboot 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_idQuoted 5 lines
# 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
Quoted 5 lines
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?
Anyway, it's coming from lspci -n. See the wiki page:
http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
I can't remember why I run remove_id in the end, it's probably unneeded, but I can't remember (and it works, so I don't toch it).
Best regards
Kenni
Quoted 51 lines · Kenni Lund
2010/12/14 Erik Brakkee <[email protected]>:
Quoted 50 lines
Quoted 42 lines
From: Kenni Lund <[email protected]>
2010/12/14 Erik Brakkee <[email protected]>:Quoted 15 lines
Quoted 7 lines
From: Kenni Lund <[email protected]>
Quoted 4 lines
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500
might work now?Quoted 7 lines
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".
Quoted 2 lines
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.localboot 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_idQuoted 5 lines
# 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_idI did not try unbinding the usb device so I can also try that.
Quoted 7 lines
Quoted 3 lines
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
Quoted 62 lines · Daniel P. Berrange
Quoted 52 lines · Kenni Lund
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 50 lines
Quoted 42 lines
From: Kenni Lund<[email protected]>
2010/12/14 Erik Brakkee<[email protected]>:Quoted 14 lines
Quoted 6 lines
From: Kenni Lund<[email protected]>
Quoted 4 lines
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500
might work now?Quoted 8 lines
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".
Quoted 3 lines
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.localboot 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_idQuoted 6 lines
# 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_idI did not try unbinding the usb device so I can also try that.
Quoted 8 lines
Quoted 4 lines
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?
Quoted 9 lines
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.
2010/12/14 Erik Brakkee <[email protected]>:
Quoted 103 lines
Quoted 75 lines · Daniel P. Berrange
Quoted 67 lines · Kenni Lund
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 56 lines
Quoted 49 lines
From: Kenni Lund<[email protected]>
2010/12/14 Erik Brakkee<[email protected]>:Quoted 18 lines
Quoted 9 lines
From: Kenni Lund<[email protected]>
Quoted 5 lines
Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500
might work now?Quoted 8 lines
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".
Quoted 4 lines
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.localboot 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_idQuoted 6 lines
# 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_idQuoted 7 lines
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?Quoted 4 lines
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?
Quoted 9 lines
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-fasteoiata_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
Quoted 1 line
So I have IRQ sharing with usb1, usb8, usb5, usb7.
Uff....and your ata HDD controller. I guess i was much luckier than you are, my ivtv0 didn't conflict at all and ivtv1 only conflicted with USB.
Quoted 4 lines
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?
Play around with:
lspci -v
lspci -n
lsusb -v
lsusb -t
You can also just start by unbinding the first one and take note when you hit the right ones...once you unbind one, it will disappear from cat /proc/interrupts. When you're down to having only ivtv0 on one interrupt and only ivtv1 on another interrupt, then you're ready to bind with pci-stub and boot your guest.
Quoted 3 lines
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.
You also have your conflicting ata controller to take into consideration. I don't remember if "ata_piix" and "ata_piix" is IDE only, if it is, you might not even use it. Otherwise it might be easier for you to run qemu-kvm git with the new patches for shared interrupts...it really depends on your setup.
Quoted 4 lines
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.
Most likely, the PCIe USB 3.0 card I bought supported MSI-X, so it got its own unique IRQs which wasn't shared with anything.
Best regards
Kenni
<quote who="Kenni Lund">
Quoted 155 lines
2010/12/14 Erik Brakkee <[email protected]>:
Quoted 111 lines
Quoted 82 lines · Daniel P. Berrange
Quoted 74 lines · Kenni Lund
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 61 lines
Quoted 54 lines
From: Kenni Lund<[email protected]>
2010/12/14 Erik Brakkee<[email protected]>:Quoted 21 lines
Quoted 10 lines
From: Kenni Lund<[email protected]>
Quoted 6 lines
Does this mean I have a chance now that PCI passthrough of my WinTV
PVR-500
might work now?Quoted 10 lines
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".Quoted 4 lines
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.localboot 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_idQuoted 6 lines
# 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_idQuoted 9 lines
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?Quoted 4 lines
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?
Quoted 9 lines
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:usb6Quoted 1 line
So I have IRQ sharing with usb1, usb8, usb5, usb7.
Uff....and your ata HDD controller. I guess i was much luckier than you are, my ivtv0 didn't conflict at all and ivtv1 only conflicted with USB.
Quoted 5 lines
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?Play around with:
lspci -v
lspci -n
lsusb -v
lsusb -tYou can also just start by unbinding the first one and take note when you hit the right ones...once you unbind one, it will disappear from cat
/proc/interrupts. When you're down to having only ivtv0 on one interrupt and only ivtv1 on another interrupt, then you're ready to bind with pci-stub and boot your guest.Quoted 4 lines
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.You also have your conflicting ata controller to take into consideration. I don't remember if "
ata_piix" and "ata_piix" is IDE only, if it is, you might not even use it. Otherwise it might be easier for you to run qemu-kvm git with the new patches for shared interrupts...it really depends on your setup.Quoted 7 lines
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.
Quoted 3 lines
Most likely, the PCIe USB 3.0 card I bought supported MSI-X, so it got its own unique IRQs which wasn't shared with anything.
I think I am a bit out of luck here. The two IRQs that are interesting are 18 and 19. One of them has the SMBUS and the other one has SATA drives. I think the best for me is to wait until shared IRQ support in KVM is available. My only option is to try it out every once in a while.
Quoted 161 lines · Erik Brakkee
<quote who="Kenni Lund">
Quoted 159 lines
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 111 lines
Quoted 81 lines · Daniel P. Berrange
Quoted 73 lines · Kenni Lund
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 60 lines
Quoted 53 lines
From: Kenni Lund<[email protected]>
2010/12/14 Erik Brakkee<[email protected]>:Quoted 20 lines
Quoted 9 lines
From: Kenni Lund<[email protected]>
Quoted 6 lines
Does this mean I have a chance now that PCI passthrough of my WinTV
PVR-500
might work now?Quoted 11 lines
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".Quoted 5 lines
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.localboot 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_idQuoted 7 lines
# 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_idQuoted 10 lines
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?Quoted 5 lines
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?
Quoted 10 lines
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:usb6Quoted 2 lines
So I have IRQ sharing with usb1, usb8, usb5, usb7.
Uff....and your ata HDD controller. I guess i was much luckier than you are, my ivtv0 didn't conflict at all and ivtv1 only conflicted with USB.
Quoted 6 lines
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?Play around with:
lspci -v
lspci -n
lsusb -v
lsusb -tYou can also just start by unbinding the first one and take note when you hit the right ones...once you unbind one, it will disappear from cat
/proc/interrupts. When you're down to having only ivtv0 on one interrupt and only ivtv1 on another interrupt, then you're ready to bind with pci-stub and boot your guest.Quoted 5 lines
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.You also have your conflicting ata controller to take into consideration. I don't remember if "
ata_piix" and "ata_piix" is IDE only, if it is, you might not even use it. Otherwise it might be easier for you to run qemu-kvm git with the new patches for shared interrupts...it really depends on your setup.Quoted 8 lines
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.
Quoted 12 lines
Quoted 4 lines
Most likely, the PCIe USB 3.0 card I bought supported MSI-X, so it got its own unique IRQs which wasn't shared with anything.
I think I am a bit out of luck here. The two IRQs that are interesting are 18 and 19. One of them has the SMBUS and the other one has SATA drives. I think the best for me is to wait until shared IRQ support in KVM is available. My only option is to try it out every once in a while.
Meanwhile, I haven't given up and experimented with determining the effect of unbinding the various USB PCI devices. I haven't tried virtualization yet though. The problem is I managed to free up one tuner (ivtv0) from shared IRQs, all USB ports are still operational, but then how would I determine which USB ports still support USB 2.0?
I have now at least found a way to make ivtv0 available without any shared IRQ by unbinding two USB PCI devices: one UHCI and one EHCI device.
The list of USB PCI devices is:
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
I unbound 00:1a.7 and 00:1d.2. To my great surprise, all USB ports on the server are still operational. I tried this by inserting a USB memory stick and trying to mount it. The motherboard has a total of 8 USB connections with 6 USB in use, I don't really understand this. Was I simply in luck?
The output of lsucb after doing the unbinding is:
Bus 005 Device 003: ID 046b:ff10 American Megatrends, Inc.
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 045e:001e Microsoft Corp. IntelliMouse Explorer Bus 006 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Alternatively, I am also considering to by a new PCIe card. In particular, the ASUS U3S6 looks interesting because it has 2 PCIe ports and 2 USB 3.0 ports. This means that I could disable 2 more USB devices (00:1a.2 and 00:1d.1) and get some extra USB devices. The ata_piix drivers are being used for an internal disk and CDROM. The RAID array is managed through arcmsr (Areca) so I don't have a problem there. Of course, if I managed to get completely free of shared IRQs with this add-on card, then the issue of determining which of the remaining ports is still USB 2.0 is not that important anymore.
So, enough ideas to try out.
Quoted 187 lines · Erik Brakkee
Quoted 147 lines · Erik Brakkee
<quote who="Kenni Lund">
Quoted 146 lines
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 106 lines
Quoted 71 lines · Daniel P. Berrange
Quoted 65 lines · Kenni Lund
2010/12/14 Erik Brakkee<[email protected]>:
Quoted 54 lines
Quoted 37 lines
From: Kenni Lund<[email protected]>
2010/12/14 Erik Brakkee<[email protected]>:Quoted 17 lines
Quoted 7 lines
From: Kenni Lund<[email protected]>
Quoted 5 lines
Does this mean I have a chance now that PCI passthrough of my WinTV
PVR-500
might work now?Quoted 10 lines
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".Quoted 4 lines
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.Quoted 17 lines
My
/etc/rc.localboot script looks like the following today:Signature · 14 lines
#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_idQuoted 9 lines
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?Quoted 4 lines
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?
Quoted 9 lines
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-fasteoiata_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:usb6Quoted 1 line
So I have IRQ sharing with usb1, usb8, usb5, usb7.
Uff....and your ata HDD controller. I guess i was much luckier than you are, my ivtv0 didn't conflict at all and ivtv1 only conflicted with USB.
Quoted 5 lines
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?Play around with:
lspci -v
lspci -n
lsusb -v
lsusb -tYou can also just start by unbinding the first one and take note when you hit the right ones...once you unbind one, it will disappear from cat
/proc/interrupts. When you're down to having only ivtv0 on one interrupt and only ivtv1 on another interrupt, then you're ready to bind with pci-stub and boot your guest.Quoted 4 lines
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.You also have your conflicting ata controller to take into consideration. I don't remember if "
ata_piix" and "ata_piix" is IDE only, if it is, you might not even use it. Otherwise it might be easier for you to run qemu-kvm git with the new patches for shared interrupts...it really depends on your setup.Quoted 7 lines
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.Quoted 10 lines
Quoted 3 lines
Most likely, the PCIe USB 3.0 card I bought supported MSI-X, so it got its own unique IRQs which wasn't shared with anything.
I think I am a bit out of luck here. The two IRQs that are interesting are 18 and 19. One of them has the SMBUS and the other one has SATA drives. I think the best for me is to wait until shared IRQ support in KVM is available. My only option is to try it out every once in a while.
Meanwhile, I haven't given up and experimented with determining the effect of unbinding the various USB PCI devices. I haven't tried virtualization yet though. The problem is I managed to free up one tuner (ivtv0) from shared IRQs, all USB ports are still operational, but then how would I determine which USB ports still support USB 2.0?
I have now at least found a way to make ivtv0 available without any shared IRQ by unbinding two USB PCI devices: one UHCI and one EHCI device.
The list of USB PCI devices is:
00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
I unbound 00:1a.7 and 00:1d.2. To my great surprise, all USB ports on the server are still operational. I tried this by inserting a USB memory stick and trying to mount it. The motherboard has a total of 8 USB connections with 6 USB in use, I don't really understand this. Was I simply in luck?
The output of lsucb after doing the unbinding is:
Bus 005 Device 003: ID 046b:ff10 American Megatrends, Inc.
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 045e:001e Microsoft Corp. IntelliMouse Explorer Bus 006 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Quoted 4 lines
Alternatively, I am also considering to by a new PCIe card. In particular, the ASUS U3S6 looks interesting because it has 2 PCIe ports and 2 USB 3.0 ports. This means that I could disable 2 more USB devices (00:1a.2 and 00:1d.1) and get some extra USB devices. The
ata_piixdrivers are being used for an internal disk and CDROM. The RAID array is managed through arcmsr (Areca) so I don't have a problem there. Of course, if I managed to get completely free of shared IRQs with this add-on card, then the issue of determining which of the remaining ports is still USB 2.0 is not that important anymore.So, enough ideas to try out.
In the mean while I figured it out completely. I disabled the 4 USB PCI devices as mentioned above which leads to one USB port becoming unusable (acceptable). Then I could configure the SATA 'handling' in the BIOS. The default was plain SATA, but I could also select Intel RAID, Adaptec RAID, and AHCI. In any case Intel RAID and AHCI solved the problem with the ata_piix shared IRQ (did not check), so I used the most modern one (Intel RAID). (motherboard Supermicro X8DTi-F).
Meanwhile I did a successful PCI passthrough test recording two channels simultanesously and it worked!
PS. I used to do backups to a backup SATA disk over USB but since I turned on the Intel RAID, the SATA ports on the motherboard became hot swappable so I can now backup over (e)SATA which gives me a 5 times speedup in bandwidth and frees up one USB port, compensating for the one I lost.
So all is well and I can continue my virtualized setup according to my original plans.
Cheers
Erik
Hi,
Quoted 5 lines
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.
There is a patch series from Hans de Goede on qemu-devel which adds buffering for isochronous usb transfers to the usb passthrough code. Certainly worth a try.
cheers,
Gerd