Xenner design and kvm msr handling

[Gerd Hoffmann <kraxel@redhat.com>]

On 04/20/09 15:45, Avi Kivity wrote:

> Please elaborate. What hypercalls are so simple that an exit into the
> hypervisor is not necessary?

Ok, that becomes a longer story.  I try to keep it short though ...


xenner today (pure-pv only)
===========================

There is the xenner userspace application.  Handles start-of-day 
creation and the guest <=> host communication (well, not all of it, but 
these details are not relevant here).

There is emu.  Lives in guest address space, in the xen hypervisor 
address space hole.  Kida micro-kernel.  Handles all the hypercalls. 
Most stuff it can do internally, without leaving guest contect.  In a 
few cases it has to ask the xenner application for help.  That is the 
case for guest <-> host communication things, event channel setup for 
example.

xenner and emu talk to each other using an ioport based interface.


xenner future plans
===================

I want merge the userspace bits into qemu, so qemu can emulate xen 
guests (both tcg and kvm mode).

xenner application goes away.
emu will stay the same.
Likewise the ioport interface for emu.


xenner & pv-on-hvm
==================

Once we have all this in qemu it is just a small step to also support 
xenish pv-on-hvm drivers in qemu using the xenner emulation bits. 
Hypercalls are handled by a small pic binary loaded into the hypercall 
pages.  Loading of the binary is triggered by the msr writes discussed. 
Size of the binary is only two pages: one hypercall entry points, one 
code.  Communication path is the very same ioport interface also used by 
emu, i.e. it does *not* use vmcall and thus no opcode changes are needed 
on migration.

Hope the whole picture is more clear now ...

cheers,
   Gerd

PS: bitrotted (and IIRC also broken) code is here:
http://git.et.redhat.com/?p=qemu-kraxel.git;a=shortlog;h=refs/heads/xenner-old

Needs un-rotting once the first batch of xen patches is merged.