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