[Top][All Lists]
[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