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

[Jamie Lokier <jamie@shareable.org>]

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