Re: [RFC, PATCH 1/24] i386 Vmi documentation II

[Daniel Arai <arai@vmware.com>]

Andi Kleen wrote:
>>There was one other point I wanted to make but I forgot it now @)
> 
> 
> Ah yes the point was that since most of the implementations of the hypercalls
> likely need fast access to some per CPU state. How would you plan
> to implement that? Should it be covered in the specification?

I can explain how it works, but it's deliberately not part of the specification.

The whole point of the ROM layer is that it abstracts away the actual hypercall 
mechanism for the guest, and the hypervisor can implement whatever is 
appropriate for it.  This layer allows a VMI guest to run on VMware's 
hypervisor, as well as on top of Xen.

We reserve the top 64MB of linear address space for the hypervisor.

Part of this reserved space contains data structures that are shared by the VMI 
ROM layer and the hypervisor.  Simple VMI interface calls like "read CR 2" are 
implemented by reading or writing data from this shared data structure, and 
don't require a privilege level change.  Things like page table updates go into 
a queue in the shared area, so they can easily be batched and processed with 
only one actual call into the hypervisor.

Because the guest can manipulate this data page directly, the hypervisor has to 
treat any information in it as untrusted.  This is similar to how the kernel has 
to treat syscall arguments.  Guest user code can't touch the shared area, so it 
doesn't introduce any new kernel security holes.  The guest kernel could 
deliberately mess up the shared area contents, but guest kernel code could 
corrupt any arbitrary (virtual) machine state anyway.

Because this level of interface is hidden from the guest, we can (and do) make 
changes to it without changing VMI itself, or needing to recompile the guest. 
We deliberately do not document it.  A guest that adheres to the VMI interface 
can move to new versions of the ROM/hypervisor interface (that implement the 
same VMI interface) without changes.

Dan.