David Ahern wrote:
On 03/09/11 08:40, erik.rull@xxxxxxxxxxxxx wrote:
But some things are not working and cause my Windows guest to stop booting
or getting slowed down:
-device usb-tablet
-device usb-mouse
do not really work. (I have connected a PS/2 mouse to have no interference
with the rest of the USB system that works fine without the patch)
If I add them to the command line, windows does not boot up (it hangs
before the GUI comes up with ~ 12% CPU time on the host side)
If I add them at runtime via the qemu console it has no influence to the
guest - I still see no possibility grabbing the mouse to the client
Did those work with the previous qemu-kvm releases you tested?
I've tried it long time ago with kvm-88, but there it was working but
extremely slow. (At least the mouse was reacting there)
-device usb-host
(for adding all USB devices automatically to the client) works only partly.
The client is slowed down when having activated this function but e.g. the
USB key gets detected - but not completely, Windows seem to hang somewhere
after having got the hardware and before displaying the key in the Explorer
(works without the patch)
Similarly, how does this compare to prior qemu-kvm releases?
I'm not sure if that had worked with kvm-88 automatically - sorry.
If one of the above options are enabled I get sometimes a "USB Stall"
displayed in the qemu-console.
Additonally these lines appear:
ehci: PERIODIC list base register set while periodic schedule
and
ehci: ASYNC list address register set while async schedule
According to the EHCI spec an OS is not allowed to do that when the
schedule and controller are enabled. It's more informational than
anything that OS is not compliant.
ok. (Windows is the OS :-))
If I can help you or give you more feedback or even try out new patches,
just let me know.
I'm really interested in solving the "missing features".
Someone needs to dig into the EHCI spec and the code. I lost momentum on
it last summer for various reasons.
David
Hm, okay.
As far as I understood it, the auto-add feature should be similar to the
USB 1.1, right? It seems to work basically but not fully - the system is
somehow slowed down, maybe the polling timer is too fast? (I will play a
little bit with that and review and compare as well the auto routine)
And the usb-tablet should be an uhci-emulated component, that should then
not interfere with the ehci-emulation, right?
If you have any additional hints where to start digging, just let me know.
Best regards,
Erik
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html