WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine
From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
Date: Wed, 13 Apr 2011 13:28:07 +0200
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alexander Graf <agraf@xxxxxxx>, QEMU-devel <qemu-devel@xxxxxxxxxx>
Delivery-date: Wed, 13 Apr 2011 04:29:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1104131139180.22672@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1301423290-12443-1-git-send-email-anthony.perard@xxxxxxxxxx> <1301423290-12443-6-git-send-email-anthony.perard@xxxxxxxxxx> <4D9F1249.6080305@xxxxxxxxxxx> <alpine.DEB.1.10.1104111852190.9096@xxxxxxxxxxxxxxxxxxxxxxx> <4DA35CC8.6030909@xxxxxx> <BANLkTincWhTd6WWciScRRP9wn+3+D=okBg@xxxxxxxxxxxxxx> <4DA47551.90103@xxxxxxxxxxx> <alpine.DEB.2.00.1104131139180.22672@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel