From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqQfn-0003Gl-LQ for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:37:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqQfi-0003Fl-EU for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:37:58 -0400 Received: from [199.232.76.173] (port=33620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqQfi-0003Fi-8y for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:37:54 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45173) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqQfh-0008EQ-Qo for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:37:54 -0400 Message-ID: <49D8980D.1070000@redhat.com> Date: Sun, 05 Apr 2009 14:37:49 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/10] xen: pv domain support. References: <1238621982-18333-1-git-send-email-kraxel@redhat.com> <1238706878.5426.1.camel@Quad> <49D6708D.4000601@redhat.com> <88ADCEFD-E057-4264-8447-9E53A661B35D@suse.de> <49D87044.3030406@redhat.com> <803692EA-B562-4D41-A809-7EF552180B8F@suse.de> In-Reply-To: <803692EA-B562-4D41-A809-7EF552180B8F@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel , xen-devel@lists.xensource.com, Gerd Hoffmann , Laurent Vivier Alexander Graf wrote: > > On 05.04.2009, at 10:48, Avi Kivity wrote: > >> Alexander Graf wrote: >>> >>> One idea I had for full virtualization in a Xen environment would be >>> an PV vmenter/vmexit framework - either by implementing a completely >>> new abstraction or simple traps for privileged operations like VMRUN. >>> >>> That way we could have a kvm that talks to xen for the VM, rendering >>> kvm useful on Xen dom0s, giving people the best of both worlds. >>> >>> That was only one of the ideas that came up while talking to people >>> why running kvm on xen isn't as easy as just recompiling :-). Would >>> you think of such a thing as useful? >>> >>> >> >> Why would anyone want to do that? If you've got Xen running, just >> start up a Xen guest. > > I'm not saying it's a great idea - that's why I didn't even consider > to develop it yet :-). > > Basically it would solve two problems: > > 1) Migration path. If you could already use KVM on a Xen host, you > could have Xen PV guests and KVM guests in parallel, easing migration > to KVM for customers. I like this, of course, but we have a path through Xenner. Maybe this (kvm-on-xen) path will be easier to take. > > 2) Alternative to HVM. That's how this came up from Gerd's mail. We do > have KVM support in upstream qemu, but we don't have Xen HVM support. > That way you could use the same binary for all your needs. Admittedly, > it might make more sense to just implement HVM support :-). I was under the impression that this is underway. > > Again, I just like talking to others about random ideas I have and > this was one. I don't think it's worth it - IMHO it'd be more useful > to create an in-kernel xen-like module that exposes Xen PV > functionality, so you get all the PV benefits without the performance > hit from full virtualization and duplication of code. > With npt/ept pv performance might be higher running under kvm+xenner than with software-only Xen by letting the guest kernel access pagetables directly. Though Gerd had some issues with 64-bit guests IIRC, which is a pity since it's there that the pv performance hit is greatest. -- error compiling committee.c: too many arguments to function