From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9zlQ-0007rm-Vn for qemu-devel@nongnu.org; Wed, 13 Apr 2011 09:05:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9zlL-0005CT-3i for qemu-devel@nongnu.org; Wed, 13 Apr 2011 09:05:44 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9zlK-0005CB-Q3 for qemu-devel@nongnu.org; Wed, 13 Apr 2011 09:05:39 -0400 Message-ID: <4DA59F97.8020005@siemens.com> Date: Wed, 13 Apr 2011 15:05:27 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1301423290-12443-1-git-send-email-anthony.perard@citrix.com> <1301423290-12443-6-git-send-email-anthony.perard@citrix.com> <4D9F1249.6080305@siemens.com> <4DA35CC8.6030909@web.de> <4DA47551.90103@siemens.com> <4DA588C7.9010100@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , Xen Devel , Alexander Graf , QEMU-devel On 2011-04-13 13:49, Stefano Stabellini wrote: > On Wed, 13 Apr 2011, Jan Kiszka wrote: >> On 2011-04-13 12:56, Stefano Stabellini wrote: >>> On Tue, 12 Apr 2011, Jan Kiszka wrote: >>>> Well, either you have a use for the VCPU state (how do you do migration >>>> in Xen without it?), or you should probably teach QEMU in a careful & >>>> clean way to run its device model without VCPUs - and without any >>>> TCG-related memory consumption. For the latter, you would likely receive >>>> kudos from KVM people as well. >>>> >>>> BTW, if you happen to support that crazy vmport under Xen, not updating >>>> the VCPU state will break your neck. Also, lacking VCPUs prevent the >>>> usage of analysis and debugging features of QEMU (monitor, gdbstub). >>> >>> We don't use the vcpu state in qemu because qemu takes care of device >>> emulation only; under xen the vcpu state is saved and restored by the >>> hypervisor. >> >> Just out of curiosity: So you are extracting the device states out of >> QEMU on migration, do the same with the VCPU states from the hypervisor >> (which wouldn't be that different from KVM in fact), and then transfer >> that to the destination node? Is there a technical or historical reason >> for this split-up? I mean, you still need some managing instance that >> does the state transportation and VM control on both sides, i.e. someone >> for the job that QEMU is doing for TCG or KVM migrations. > > That someone is the "toolstack", I guess libvirt would be the closest > thing to our toolstack in the kvm world. > The reason why we have a toolstack performing this task rather than qemu > is that pure PV guests don't need device emulation, so we don't even > have qemu running most of the times if there are only linux guests > installed in the system. Ah, for that use case it makes some sense to me. I bet there would also be some value in consolidating the "toolstack" functionality over bare qemu/libvirt infrastructure (if we ignored all existing interfaces and dependencies for a moment). Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux