From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lqihn-0006Md-CG for qemu-devel@nongnu.org; Mon, 06 Apr 2009 02:53:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lqihi-0006MR-NS for qemu-devel@nongnu.org; Mon, 06 Apr 2009 02:53:14 -0400 Received: from [199.232.76.173] (port=37693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lqihi-0006MO-JS for qemu-devel@nongnu.org; Mon, 06 Apr 2009 02:53:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:58835) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lqihi-0000oV-2Q for qemu-devel@nongnu.org; Mon, 06 Apr 2009 02:53:10 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lqihh-0002wI-2q for qemu-devel@nongnu.org; Mon, 06 Apr 2009 02:53:09 -0400 Message-ID: <49D9A6CD.30602@redhat.com> Date: Mon, 06 Apr 2009 08:53:01 +0200 From: Gerd Hoffmann 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> In-Reply-To: <88ADCEFD-E057-4264-8447-9E53A661B35D@suse.de> Content-Type: text/plain; charset=ISO-8859-1 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: xen-devel@lists.xensource.com, Laurent Vivier , qemu-devel 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. Hmm. I suspect xen's direct paging mode makes that quite intrusive as the kvm mmu code would have to know about this extra p2m translation step to get the shadow/ept/ntp tables right. Given that this most likely would be a odd and rarely tested use case I don't think this would be a good idea ... cheers, Gerd