RE: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Can you give me some details about the device? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerb Stralko Sent: Friday, February 29, 2008 4:17 PM To: Arnon Gilboa Cc: [EMAIL PROTECTED]; qemu-devel@nongnu.org Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation On Fri, Feb 29, 2008 at 2:33 AM, Arnon Gilboa <[EMAIL PROTECTED]> wrote: > In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); > With usb_ehci_init(pci_bus, piix3_devfn + 2); With these changes.. I can't add the usb devices anymore to a Windows XP (32 bit). This is the command i use to start kvm: /usr/local/bin/kvm/qemu-system-x86_64 -localtime -m 512 -usb -hda win32xp.img To add usb device i normally go to the qemu console and type: info usbhost usb_add host:03f0:01cda But with your patch, when i try to add a usb device i get: Could not add 'USB device host:03f0:01cda' Since i'm using EHCI emulation, do i need to add usb devices in a different way? Or should it work exactly the same way? Thanks, Jerry > Note my comments on the original post: > -tested on XP guest > -does not support ISO transfers > -timing issues > > > > -Original Message- > From: Gerb Stralko [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 28, 2008 9:46 PM > To: Arnon Gilboa > Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] > Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation > > > Attached is a repost of the preliminary patch implementing USB 2.0 > > EHCI emulation. > > I want to start testing your patches for the EHCI stuff. Do i need > to enable anything inorder to get EHCI emulation working after > applying your patch? > > Unfortunately, with this patch it doesn't work for me. My guest host > (windows vista) still became really slow when I add the a usb device. > > > > Waiting for your comments, > > Arnon > > > > Thanks, > > Jerry >
Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Fri, Feb 29, 2008 at 2:33 AM, Arnon Gilboa <[EMAIL PROTECTED]> wrote: > In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); > With usb_ehci_init(pci_bus, piix3_devfn + 2); With these changes.. I can't add the usb devices anymore to a Windows XP (32 bit). This is the command i use to start kvm: /usr/local/bin/kvm/qemu-system-x86_64 -localtime -m 512 -usb -hda win32xp.img To add usb device i normally go to the qemu console and type: info usbhost usb_add host:03f0:01cda But with your patch, when i try to add a usb device i get: Could not add 'USB device host:03f0:01cda' Since i'm using EHCI emulation, do i need to add usb devices in a different way? Or should it work exactly the same way? Thanks, Jerry > Note my comments on the original post: > -tested on XP guest > -does not support ISO transfers > -timing issues > > > > -Original Message- > From: Gerb Stralko [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 28, 2008 9:46 PM > To: Arnon Gilboa > Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] > Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation > > > Attached is a repost of the preliminary patch implementing USB 2.0 > > EHCI emulation. > > I want to start testing your patches for the EHCI stuff. Do i need > to enable anything inorder to get EHCI emulation working after applying > your patch? > > Unfortunately, with this patch it doesn't work for me. My guest host > (windows vista) still became really slow when I add the a usb device. > > > > Waiting for your comments, > > Arnon > > > > Thanks, > > Jerry >
RE: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With usb_ehci_init(pci_bus, piix3_devfn + 2); Note my comments on the original post: -tested on XP guest -does not support ISO transfers -timing issues -Original Message- From: Gerb Stralko [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 9:46 PM To: Arnon Gilboa Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation > Attached is a repost of the preliminary patch implementing USB 2.0 > EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. > > Waiting for your comments, > Arnon > Thanks, Jerry
Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
> Attached is a repost of the preliminary patch implementing USB 2.0 EHCI > emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. > > Waiting for your comments, > Arnon > Thanks, Jerry
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Paul Brook wrote: On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: -The host kernel was configured with dynamic tick & hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. Surely qemu should read the time and adjust? For example, a 1000Hz guest running on a 100Hz host will see a 10x slowdown in real time. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tuesday 08 January 2008, Dor Laor wrote: > On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: > > > -The host kernel was configured with dynamic tick & hi-res timers, to > > > allow the desired timer resolution. USB 2.0 microframe is 125usec. > > It still works even without accurate timing demands. > Only isochronous mode will have problems and it is not yet supported for > ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. > > Requiring a 8kHz timer is a non-starter. > > > > The 100kHz "retry" timer is even more bogus. > > > > Qemu isn't capable of this kind of realtime response. You need to figure > > out an implementation that doesn't require extremely fine grained timers. > > In paractice you're unlikely to get better than 10ms timer resolution, > > and 100ms latency isn't that uncommon. > > > > Paul > > Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good > accuracy, surely it can provide 1khz and probably even 8khz Only if the host is lightly loaded. qemu tends to use a lot of CPU, so scheduler heuristics will tend to give it a low priority. c.f. an mp3 player that uses a small amount of CPU, so the scheduler will try hard to provide prompt signal delivery. Paul
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: > > -The host kernel was configured with dynamic tick & hi-res timers, to > > allow the desired timer resolution. USB 2.0 microframe is 125usec. > It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. > Requiring a 8kHz timer is a non-starter. > > The 100kHz "retry" timer is even more bogus. > > Qemu isn't capable of this kind of realtime response. You need to figure out > an implementation that doesn't require extremely fine grained timers. In > paractice you're unlikely to get better than 10ms timer resolution, and 100ms > latency isn't that uncommon. > > Paul Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good accuracy, surely it can provide 1khz and probably even 8khz Dor
RE: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
The WinXP guest seems to work fine with the timer resolution, accuracy and latency of qemu. The problem with linux guests might be related to this issue. I will test the ehci emulation without the specified kernel config and see how can we handle timing issues in a more qemu-oriented way. Any tip? Arnon -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 3:30 AM To: qemu-devel@nongnu.org Cc: Arnon Gilboa; KVM; Roni Luxenberg Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation > -The host kernel was configured with dynamic tick & hi-res timers, to > allow the desired timer resolution. USB 2.0 microframe is 125usec. Requiring a 8kHz timer is a non-starter. The 100kHz "retry" timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
> -The host kernel was configured with dynamic tick & hi-res timers, to > allow the desired timer resolution. USB 2.0 microframe is 125usec. Requiring a 8kHz timer is a non-starter. The 100kHz "retry" timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul
