Re: USB Passthrough 1.1 performance problem...
On Tue, Dec 14, 2010 at 12:02:03PM +0200, Avi Kivity wrote:
> 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
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -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.";
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
Erik Brakkee wrote: Erik Brakkee wrote: 2010/12/14 Erik Brakkee: 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 ":00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:08.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:08.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 0016"> /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:09.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:09.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 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 0016. I configured the pci card in kvm and I believe kvm does the binding to pci-stub in recent versions. Where is the 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. Uffand 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. 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. 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
Re: USB Passthrough 1.1 performance problem...
Erik Brakkee wrote: 2010/12/14 Erik Brakkee: 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 ":00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:08.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:08.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 0016"> /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:09.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:09.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 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 0016. I configured the pci card in kvm and I believe kvm does the binding to pci-stub in recent versions. Where is the 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. Uffand 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. 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. 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
Re: USB Passthrough 1.1 performance problem...
> 2010/12/14 Erik Brakkee : >> 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 ":00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind >> >> # ivtv0 >> echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id >> echo ":04:08.0"> /sys/bus/pci/drivers/ivtv/unbind >> echo ":04:08.0"> /sys/bus/pci/drivers/pci-stub/bind >> echo " 0016"> /sys/bus/pci/drivers/pci-stub/remove_id >> >> # ivtv1 >> echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id >> echo ":04:09.0"> /sys/bus/pci/drivers/ivtv/unbind >> echo ":04:09.0"> /sys/bus/pci/drivers/pci-stub/bind >> echo " 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 0016. I > configured > the > pci card in kvm and I believe kvm does the binding to pci-stub in > recent > versions. Where is the 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. > > Uffand 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. > >> 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 o
Re: USB Passthrough 1.1 performance problem...
2010/12/14 Erik Brakkee : > 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 ":00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind > > # ivtv0 > echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id > echo ":04:08.0"> /sys/bus/pci/drivers/ivtv/unbind > echo ":04:08.0"> /sys/bus/pci/drivers/pci-stub/bind > echo " 0016"> /sys/bus/pci/drivers/pci-stub/remove_id > > # ivtv1 > echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id > echo ":04:09.0"> /sys/bus/pci/drivers/ivtv/unbind > echo ":04:09.0"> /sys/bus/pci/drivers/pci-stub/bind > echo " 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 0016. I configured the pci card in kvm and I believe kvm does the binding to pci-stub in recent versions. Where is the 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. Uffand 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. > 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
Re: USB Passthrough 1.1 performance problem...
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 ":00:1b.0"> /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:08.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:08.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 0016"> /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo " 0016"> /sys/bus/pci/drivers/pci-stub/new_id echo ":04:09.0"> /sys/bus/pci/drivers/ivtv/unbind echo ":04:09.0"> /sys/bus/pci/drivers/pci-stub/bind echo " 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 0016. I configured the pci card in kvm and I believe kvm does the binding to pci-stub in recent versions. Where is the 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
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 ":00:1b.0" > /sys/bus/pci/drivers/HDA\ Intel/unbind > >> > >> # ivtv0 > >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id > >> echo ":04:08.0" > /sys/bus/pci/drivers/ivtv/unbind > >> echo ":04:08.0" > /sys/bus/pci/drivers/pci-stub/bind > >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/remove_id > >> > >> # ivtv1 > >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id > >> echo ":04:09.0" > /sys/bus/pci/drivers/ivtv/unbind > >> echo ":04:09.0" > /sys/bus/pci/drivers/pci-stub/bind > >> echo " 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 0016. I configured the > > pci card in kvm and I believe kvm does the binding to pci-stub in recent > > versions. Where is the 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
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 ":00:1b.0" > /sys/bus/pci/drivers/HDA\ Intel/unbind >> >> # ivtv0 >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id >> echo ":04:08.0" > /sys/bus/pci/drivers/ivtv/unbind >> echo ":04:08.0" > /sys/bus/pci/drivers/pci-stub/bind >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/remove_id >> >> # ivtv1 >> echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id >> echo ":04:09.0" > /sys/bus/pci/drivers/ivtv/unbind >> echo ":04:09.0" > /sys/bus/pci/drivers/pci-stub/bind >> echo " 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 0016. I configured the > pci card in kvm and I believe kvm does the binding to pci-stub in recent > versions. Where is the 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
Am 14.12.2010 um 11:02 schrieb Avi Kivity : > On 12/13/2010 10:25 AM, Alexander Graf wrote: >> >> >> > 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-SERR-> 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] >> > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
On 12/13/2010 10:25 AM, Alexander Graf wrote: >> > 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-SERR- 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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
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 ":00:1b.0" > /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id echo ":04:08.0" > /sys/bus/pci/drivers/ivtv/unbind echo ":04:08.0" > /sys/bus/pci/drivers/pci-stub/bind echo " 0016" > /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo " 0016" > /sys/bus/pci/drivers/pci-stub/new_id echo ":04:09.0" > /sys/bus/pci/drivers/ivtv/unbind echo ":04:09.0" > /sys/bus/pci/drivers/pci-stub/bind echo " 0016" > /sys/bus/pci/drivers/pci-stub/remove_id -- Best regards Kenni -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
2010/12/12 Erik Brakkee : > 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 > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
Am 12.12.2010 23:31, Erik Brakkee wrote: > Jan Kiszka wrote: >> 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. >> > 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 signature.asc Description: OpenPGP digital signature
Re: 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. 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
On 12.12.2010, at 23:31, Erik Brakkee wrote: > Jan Kiszka wrote: >> 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. >> > 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). > >> >>> 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 >> >>>* 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 >> >> > 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 qe
Re: USB Passthrough 1.1 performance problem...
Jan Kiszka wrote: 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. 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). 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. * 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 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Passthrough 1.1 performance problem...
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 signature.asc Description: OpenPGP digital signature
Re: USB Passthrough 1.1 performance problem...
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. 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 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
