AW: Re: [Qemu-devel] VMport patch

AW: Re: [Qemu-devel] VMport patch

[Alexander Graf]

I think it would be great to maintain compatibility with the binary-only versions of the vm tools though.

Regards,

Alex

----- Ursprüngliche Nachricht -----
Von: Anthony Liguori <anthony@codemonkey.ws>
Gesendet: Sonntag, 20. Januar 2008 22:40
An: qemu-devel@nongnu.org
Betreff: Re: [Qemu-devel] VMport patch

Filip Navara wrote:
> Hello,
>
> the current version of QEMU emulates the VMware backdoor I/O port and 
> it works quite well. Unfortunately it doesn't emulate the VMware 
> behavior of ignoring the I/O permissions when accessing this special 
> port. The attached patch corrects it. It's important to ignore the 
> permissions, so that user mode VMware tools can communicate to the 
> backdoor. =

I really dislike that VMware relies on this.  It's very hard to 
implement in kqemu or KVM.  I think it would be better to modify 
open-vm-tools than to modify QEMU.

Regards,

Anthony Liguori

> Best regards,
> Filip Navara

Re: AW: Re: [Qemu-devel] VMport patch

[Anthony Liguori]

Alexander Graf wrote:
> I think it would be great to maintain compatibility with the binary-only versions of the vm tools though.
>   

But you're changing the semantics of the x86 instruction set.  You 
potentially break a real operating system.  It also eliminates the 
possibility of nesting with something like kqemu because you can't trap 
all PIO operations.

Regards,

Anthony Liguori

> Regards,
>
> Alex
>
> ----- Ursprüngliche Nachricht -----
> Von: Anthony Liguori <anthony@codemonkey.ws>
> Gesendet: Sonntag, 20. Januar 2008 22:40
> An: qemu-devel@nongnu.org
> Betreff: Re: [Qemu-devel] VMport patch
>
> Filip Navara wrote:
>   
>> Hello,
>>
>> the current version of QEMU emulates the VMware backdoor I/O port and 
>> it works quite well. Unfortunately it doesn't emulate the VMware 
>> behavior of ignoring the I/O permissions when accessing this special 
>> port. The attached patch corrects it. It's important to ignore the 
>> permissions, so that user mode VMware tools can communicate to the 
>> backdoor. =
>>     
>
> I really dislike that VMware relies on this.  It's very hard to 
> implement in kqemu or KVM.  I think it would be better to modify 
> open-vm-tools than to modify QEMU.
>
> Regards,
>
> Anthony Liguori
>
>   
>> Best regards,
>> Filip Navara
>>     
>
>
>
>
>
>
>   

Re: AW: Re: [Qemu-devel] VMport patch

[Mark Williamson]

> > I think it would be great to maintain compatibility with the binary-only
> > versions of the vm tools though.
>
> But you're changing the semantics of the x86 instruction set.  You
> potentially break a real operating system.  It also eliminates the
> possibility of nesting with something like kqemu because you can't trap
> all PIO operations.

Maybe have a commandline flag, and have it switched off by default?  Or, even 
better, would be to detect valid vmware tools behaviour and switch it on iff 
that happened; the default being to behave normally for OSes that aren't 
running the VMware tools..

Cheers,
Mark

> Regards,
>
> Anthony Liguori
>
> > Regards,
> >
> > Alex
> >
> > ----- Ursprüngliche Nachricht -----
> > Von: Anthony Liguori <anthony@codemonkey.ws>
> > Gesendet: Sonntag, 20. Januar 2008 22:40
> > An: qemu-devel@nongnu.org
> > Betreff: Re: [Qemu-devel] VMport patch
> >
> > Filip Navara wrote:
> >> Hello,
> >>
> >> the current version of QEMU emulates the VMware backdoor I/O port and
> >> it works quite well. Unfortunately it doesn't emulate the VMware
> >> behavior of ignoring the I/O permissions when accessing this special
> >> port. The attached patch corrects it. It's important to ignore the
> >> permissions, so that user mode VMware tools can communicate to the
> >> backdoor. =
> >
> > I really dislike that VMware relies on this.  It's very hard to
> > implement in kqemu or KVM.  I think it would be better to modify
> > open-vm-tools than to modify QEMU.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >> Best regards,
> >> Filip Navara



-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

Re: AW: Re: [Qemu-devel] VMport patch

[Anthony Liguori]

Mark Williamson wrote:
>>> I think it would be great to maintain compatibility with the binary-only
>>> versions of the vm tools though.
>>>       
>> But you're changing the semantics of the x86 instruction set.  You
>> potentially break a real operating system.  It also eliminates the
>> possibility of nesting with something like kqemu because you can't trap
>> all PIO operations.
>>     
>
> Maybe have a commandline flag, and have it switched off by default?  Or, even 
> better, would be to detect valid vmware tools behaviour and switch it on iff 
> that happened; the default being to behave normally for OSes that aren't 
> running the VMware tools..
>   

There is no way to know for sure that it's vm-tools running.  You would 
have to make use of the cpu option to support it I reckon.

Regards,

Anthony Liguori

> Cheers,
> Mark
>
>   
>> Regards,
>>
>> Anthony Liguori
>>
>>     
>>> Regards,
>>>
>>> Alex
>>>
>>> ----- Ursprüngliche Nachricht -----
>>> Von: Anthony Liguori <anthony@codemonkey.ws>
>>> Gesendet: Sonntag, 20. Januar 2008 22:40
>>> An: qemu-devel@nongnu.org
>>> Betreff: Re: [Qemu-devel] VMport patch
>>>
>>> Filip Navara wrote:
>>>       
>>>> Hello,
>>>>
>>>> the current version of QEMU emulates the VMware backdoor I/O port and
>>>> it works quite well. Unfortunately it doesn't emulate the VMware
>>>> behavior of ignoring the I/O permissions when accessing this special
>>>> port. The attached patch corrects it. It's important to ignore the
>>>> permissions, so that user mode VMware tools can communicate to the
>>>> backdoor. =
>>>>         
>>> I really dislike that VMware relies on this.  It's very hard to
>>> implement in kqemu or KVM.  I think it would be better to modify
>>> open-vm-tools than to modify QEMU.
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>       
>>>> Best regards,
>>>> Filip Navara
>>>>         
>
>
>
>   

Re: AW: Re: [Qemu-devel] VMport patch

[Alexander Graf]

On Jan 21, 2008, at 3:41 AM, Anthony Liguori wrote:

> Mark Williamson wrote:
>>>> I think it would be great to maintain compatibility with the  
>>>> binary-only
>>>> versions of the vm tools though.
>>>>
>>> But you're changing the semantics of the x86 instruction set.  You
>>> potentially break a real operating system.  It also eliminates the
>>> possibility of nesting with something like kqemu because you can't  
>>> trap
>>> all PIO operations.
>>>
>>
>> Maybe have a commandline flag, and have it switched off by  
>> default?  Or, even better, would be to detect valid vmware tools  
>> behaviour and switch it on iff that happened; the default being to  
>> behave normally for OSes that aren't running the VMware tools..
>>
>
> There is no way to know for sure that it's vm-tools running.  You  
> would have to make use of the cpu option to support it I reckon.
>

I completely agree with the point of breaking x86 semantics is bad.  
Yes, it is. What is the point in emulating the VMWare interface  
though, if the only program actually requiring that interface does not  
work, namely vmware tools, especially the windows version. So as far  
as I know VMWare uses VMX to run 64-bit code on Intel as well, so  
there has to be a way to forcefully break the checks.

Regards,

Alex

> Regards,
>
> Anthony Liguori
>
>> Cheers,
>> Mark
>>
>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>
>>>> Regards,
>>>>
>>>> Alex
>>>>
>>>> ----- Ursprüngliche Nachricht -----
>>>> Von: Anthony Liguori <anthony@codemonkey.ws>
>>>> Gesendet: Sonntag, 20. Januar 2008 22:40
>>>> An: qemu-devel@nongnu.org
>>>> Betreff: Re: [Qemu-devel] VMport patch
>>>>
>>>> Filip Navara wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> the current version of QEMU emulates the VMware backdoor I/O  
>>>>> port and
>>>>> it works quite well. Unfortunately it doesn't emulate the VMware
>>>>> behavior of ignoring the I/O permissions when accessing this  
>>>>> special
>>>>> port. The attached patch corrects it. It's important to ignore the
>>>>> permissions, so that user mode VMware tools can communicate to the
>>>>> backdoor. =
>>>>>
>>>> I really dislike that VMware relies on this.  It's very hard to
>>>> implement in kqemu or KVM.  I think it would be better to modify
>>>> open-vm-tools than to modify QEMU.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>
>>>>> Best regards,
>>>>> Filip Navara
>>>>>
>>
>>
>>
>>
>
>
>

Re: AW: Re: [Qemu-devel] VMport patch

[Anthony Liguori]

Alexander Graf wrote:
>
> On Jan 21, 2008, at 3:41 AM, Anthony Liguori wrote:
>
>> Mark Williamson wrote:
>>>>> I think it would be great to maintain compatibility with the 
>>>>> binary-only
>>>>> versions of the vm tools though.
>>>>>
>>>> But you're changing the semantics of the x86 instruction set.  You
>>>> potentially break a real operating system.  It also eliminates the
>>>> possibility of nesting with something like kqemu because you can't 
>>>> trap
>>>> all PIO operations.
>>>>
>>>
>>> Maybe have a commandline flag, and have it switched off by default?  
>>> Or, even better, would be to detect valid vmware tools behaviour and 
>>> switch it on iff that happened; the default being to behave normally 
>>> for OSes that aren't running the VMware tools..
>>>
>>
>> There is no way to know for sure that it's vm-tools running.  You 
>> would have to make use of the cpu option to support it I reckon.
>>
>
> I completely agree with the point of breaking x86 semantics is bad. 
> Yes, it is. What is the point in emulating the VMWare interface 
> though, if the only program actually requiring that interface does not 
> work, namely vmware tools, especially the windows version. So as far 
> as I know VMWare uses VMX to run 64-bit code on Intel as well, so 
> there has to be a way to forcefully break the checks.

vmmouse uses the vmport interface but runs in ring 0 under Linux so it's 
not an issue.  FWIW, the folks on open-vm-tools-devel have expressed an 
interest in moving to a different interface then their "backdoor" interface.

Regards,

Anthony Liguori

> Regards,
>
> Alex
>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Cheers,
>>> Mark
>>>
>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Alex
>>>>>
>>>>> ----- Ursprüngliche Nachricht -----
>>>>> Von: Anthony Liguori <anthony@codemonkey.ws>
>>>>> Gesendet: Sonntag, 20. Januar 2008 22:40
>>>>> An: qemu-devel@nongnu.org
>>>>> Betreff: Re: [Qemu-devel] VMport patch
>>>>>
>>>>> Filip Navara wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> the current version of QEMU emulates the VMware backdoor I/O port 
>>>>>> and
>>>>>> it works quite well. Unfortunately it doesn't emulate the VMware
>>>>>> behavior of ignoring the I/O permissions when accessing this special
>>>>>> port. The attached patch corrects it. It's important to ignore the
>>>>>> permissions, so that user mode VMware tools can communicate to the
>>>>>> backdoor. =
>>>>>>
>>>>> I really dislike that VMware relies on this.  It's very hard to
>>>>> implement in kqemu or KVM.  I think it would be better to modify
>>>>> open-vm-tools than to modify QEMU.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>>>
>>>>>
>>>>>> Best regards,
>>>>>> Filip Navara
>>>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

Re: AW: Re: [Qemu-devel] VMport patch

[Jamie Lokier]

Mark Williamson wrote:
> > > I think it would be great to maintain compatibility with the binary-only
> > > versions of the vm tools though.
> >
> > But you're changing the semantics of the x86 instruction set.  You
> > potentially break a real operating system.  It also eliminates the
> > possibility of nesting with something like kqemu because you can't trap
> > all PIO operations.
> 
> Maybe have a commandline flag, and have it switched off by default?
> Or, even better, would be to detect valid vmware tools behaviour and
> switch it on iff that happened; the default being to behave normally
> for OSes that aren't running the VMware tools..

When nesting with kqemu/kvm, and you run a VMware tool inside the
inner emulator, the question is should the tool control the inner
emulator or the outer one?  Most often you'll want the inner one.  But
_at the same time_, tools run in the outer emulator should not trap,
but control the outer one.

So neither of the simple defaults gives the desired behaviour.  Those
defaults being (1) disallow the VMware I/Os from bypassing privilege
checking, or (2) allow the VMware I/Os to bypass privilege checking

We can get sensible behaviour when nesting, but it's a little more
complicated:

   (a) Allow VMware tools to do their thing with I/O, bypassing I/O
       privelege checking.

   (b) Add a function (it must be per-emulated-CPU) where something like
       kqemu/kvm run inside the outer emulator can request to disable
       the special function of those I/O ports while it is running -
       so the kqemu/kvm receives traps for them instead, and the
       VMware tools run inside the inner emulator are handled by the
       inner emulator.  VMware tools run inside the outer emulator
       will continue to be handled by the outer emulator - because
       this function to trap them is only active them kqemu/kvm are
       running.

   (c) It might be possible that the function in (b) could be
       automatic, without requiring changes to kqemu/kvm/(many
       others), if there's a reliable way for the outer emulator to
       detect an emulator.  At least, it should be possible in the
       case of kvm and anything else using Pacifica/VT because there
       is already a CPU state for it, and vm86 should be counted too
       so that DOS and DPMI emulators also work automatically.  An
       explicit switch should be available, though, for others.

Despite the above, I'm not convinced that VMware tools should be able
to bypass privilege checking at all.  It's perfect reasonable that
they should request privilege for controlling the machine, just like
any other tools that control the machine (real or virtual),
e.g. hwclock.

However, if there's a consensus that privilege checking should be
allowed, to behave more like VMware, either by default or by a command
line option, then please think about the suggested approach to making
sure that nestable emulators work (or can work) without affecting the
behaviour of tools in either level of emulator.

-- Jamie