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

Daniel Arai
2006-03-22T22:43:57Z

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.