linux-kernel - Xenner design and kvm msr handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49ED8E6D.80005@redhat.com>
Date:	Tue, 21 Apr 2009 11:14:21 +0200
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Huang Ying <ying.huang@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Xenner design and kvm msr handling

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/