Xenner design and kvm msr handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux