qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: UHCI idle detection


From: Alexander Graf
Subject: Re: [Qemu-devel] Re: UHCI idle detection
Date: Tue, 4 Jan 2011 16:51:38 +0100

On 04.01.2011, at 15:22, Anthony Liguori wrote:

> On 01/04/2011 08:16 AM, Gerd Hoffmann wrote:
>> On 01/04/11 14:49, Anthony Liguori wrote:
>>> On 01/04/2011 07:43 AM, Gerd Hoffmann wrote:
>>>> Hi,
>>>> 
>>>>>> Windows guests needs some registry hackery and Linux guests some
>>>>>> udev rules
>>>>>> to enable remote wakeup permanently.
>>>>> 
>>>>> That commit inspired me to look at UHCI. If the solution requires
>>>>> modifying the guest then it is not widely useful.
>>>> 
>>>> Well, long-term this shouldn't be a big issue. I expect guest agents
>>>> become commonplace soonish as some features require guest cooperation,
>>>> so the guest agents can also care about this kind of tweaks. Also for
>>>> linux we can try to send the changes to upstream udev to have it
>>>> spread into linux distros.
>>> 
>>> I think we're long overdue for a paravirtual mouse. Basically, a virtio
>>> version of xenkbd-front.c. In fact, it's probably possible to reuse the
>>> protocol.
>> 
>> Oh, there already is one.  vmmouse.  Recent Xorg versions even use it 
>> automagically.  With Fedora 14 (as guest) you can drop the usb tablet and 
>> you still have an absolute mouse pointer because of that ;)
>> 
>> Windows is more tricky as it doesn't work out-of-the-box but that wouldn't 
>> be different with a virtio-based mouse.
> 
> vmmouse relies on the VMware backdoor interface.  The backdoor interface 
> requires that a certain PIO port be accessible from CPL=3 even if IOPL=0.
> 
> It works in Linux because Xorg generally changes IOPL=3 because it implements 
> device drivers but in the long run, I hope that no longer becomes true.  With 
> Windows, I've always been under the impression that their input driver runs 
> in CPL=3 and there is no interface to change IOPL.
> 
> Supporting the backdoor interface properly in KVM would be really ugly.  We'd 
> have to shadow the IDT which means write protecting it and all of the 
> ugliness that goes along with it.

Are you sure this is still true for recent versions of VMware? I don't see how 
they'd hold onto this with vmx.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]