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.
