From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqQM5-0004Ua-EW for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:17:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqQM0-0004PQ-Mh for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:17:37 -0400 Received: from [199.232.76.173] (port=53499 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqQM0-0004PF-FM for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:17:32 -0400 Received: from cantor.suse.de ([195.135.220.2]:37009 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LqQM0-0006Vq-5e for qemu-devel@nongnu.org; Sun, 05 Apr 2009 07:17:32 -0400 Message-Id: <803692EA-B562-4D41-A809-7EF552180B8F@suse.de> From: Alexander Graf In-Reply-To: <49D87044.3030406@redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Qemu-devel] [PATCH 00/10] xen: pv domain support. Date: Sun, 5 Apr 2009 13:17:23 +0200 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> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel , xen-devel@lists.xensource.com, Gerd Hoffmann , Laurent Vivier 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. 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 :-). 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. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 00/10] xen: pv domain support. Date: Sun, 5 Apr 2009 13:17:23 +0200 Message-ID: <803692EA-B562-4D41-A809-7EF552180B8F@suse.de> 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> Reply-To: qemu-devel@nongnu.org Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49D87044.3030406@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Avi Kivity Cc: qemu-devel , xen-devel@lists.xensource.com, Gerd Hoffmann , Laurent Vivier List-Id: xen-devel@lists.xenproject.org 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. 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 :-). 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. Alex