From: Jan Kiszka <jan.kiszka@siemens.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
Xen Devel <xen-devel@lists.xensource.com>,
Alexander Graf <agraf@suse.de>,
QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine
Date: Wed, 13 Apr 2011 13:28:07 +0200 [thread overview]
Message-ID: <4DA588C7.9010100@siemens.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1104131139180.22672@kaball-desktop>
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
next prev parent reply other threads:[~2011-04-13 11:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 18:27 [Qemu-devel] [PATCH V12 00/17] Xen device model support anthony.perard
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 01/17] xen: Replace some tab-indents with spaces (clean-up) anthony.perard
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 02/17] xen: Make Xen build once anthony.perard
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 03/17] xen: Support new libxc calls from xen unstable anthony.perard
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 04/17] xen: Add initialisation of Xen anthony.perard
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 05/17] xen: Add xenfv machine anthony.perard
2011-04-08 13:48 ` [Qemu-devel] " Jan Kiszka
2011-04-11 18:10 ` [Qemu-devel] " Anthony PERARD
2011-04-11 19:55 ` Jan Kiszka
2011-04-12 14:57 ` Anthony PERARD
2011-04-12 15:52 ` Jan Kiszka
2011-04-13 10:56 ` Stefano Stabellini
2011-04-13 11:28 ` Jan Kiszka [this message]
2011-04-13 11:49 ` Stefano Stabellini
2011-04-13 13:05 ` Jan Kiszka
2011-04-13 15:22 ` Stefano Stabellini
2011-03-29 18:27 ` [Qemu-devel] [PATCH V12 06/17] xen: Add the Xen platform pci device anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 07/17] piix_pci: Introduces Xen specific call for irq anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 08/17] xen: Introduce Xen Interrupt Controller anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 09/17] xen: Introduce the Xen mapcache anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 10/17] xen: Adds a cap to the number of map cache entries anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 11/17] configure: Always use 64bits target physical addresses with xen enabled anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 12/17] Introduce qemu_put_ram_ptr anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 13/17] pci: Use of qemu_put_ram_ptr in pci_add_option_rom anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 14/17] vl.c: Introduce getter for shutdown_requested and reset_requested anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 15/17] xen: Initialize event channels and io rings anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 16/17] xen: Set running state in xenstore anthony.perard
2011-03-29 18:28 ` [Qemu-devel] [PATCH V12 17/17] xen: Add Xen hypercall for sleep state in the cmos_s3 callback anthony.perard
2011-03-30 10:56 ` [Qemu-devel] Re: [PATCH V12 00/17] Xen device model support Alexander Graf
2011-03-31 11:48 ` [Qemu-devel] Re: [Xen-devel] " Anthony PERARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DA588C7.9010100@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=agraf@suse.de \
--cc=anthony.perard@citrix.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).