From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 17:39:47 +0200 [thread overview]
Message-ID: <4F1ED0C3.7030008@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
On 01/24/2012 02:00 PM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
> > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > > >>>
> > > >>> But viewing RAM as just another device, having Xen only restore a
> > > >>> subset of
> > > >>> devices should be a reasonable thing to do moving forward.
> > >
> > > I don't think modeling device memory (i.e. vga vram) as something
> > > independent from the device (vga) is a good idea. Because it isn't.
> >
> > Right. We should have VMSTATE_RAM() to express the dependency.
>
> So if I understand correctly you are planning on removing the call to
> vmstate_register_ram_global in hw/vga.c?
I can't say I'm planning to do so, but that's the direction I think we
need to go.
> In that case it might be better if I wait for your "VMSTATE_RAM" patch
> before I can send a new patch to save only non-RAM devices, because I
> guess they will clash with one another.
I don't understand what sense a patch to save non-RAM devices makes (or
even, what non-RAM devices are).
We have a special case here where Xen manages the RAM even though qemu
thinks it does. IMO an if (xen) is the best way to express this
specialness.
--
error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 17:39:47 +0200 [thread overview]
Message-ID: <4F1ED0C3.7030008@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
On 01/24/2012 02:00 PM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
> > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > > >>>
> > > >>> But viewing RAM as just another device, having Xen only restore a
> > > >>> subset of
> > > >>> devices should be a reasonable thing to do moving forward.
> > >
> > > I don't think modeling device memory (i.e. vga vram) as something
> > > independent from the device (vga) is a good idea. Because it isn't.
> >
> > Right. We should have VMSTATE_RAM() to express the dependency.
>
> So if I understand correctly you are planning on removing the call to
> vmstate_register_ram_global in hw/vga.c?
I can't say I'm planning to do so, but that's the direction I think we
need to go.
> In that case it might be better if I wait for your "VMSTATE_RAM" patch
> before I can send a new patch to save only non-RAM devices, because I
> guess they will clash with one another.
I don't understand what sense a patch to save non-RAM devices makes (or
even, what non-RAM devices are).
We have a special case here where Xen manages the RAM even though qemu
thinks it does. IMO an if (xen) is the best way to express this
specialness.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-01-24 15:40 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 17:20 [Qemu-devel] [PATCH v4 0/6] save/restore on Xen Stefano Stabellini
2012-01-20 17:20 ` Stefano Stabellini
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 1/6] vl.c: do not save the RAM state when Xen is enabled Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-23 15:58 ` [Qemu-devel] " Anthony Liguori
2012-01-23 15:58 ` Anthony Liguori
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 2/6] xen mapcache: check if memory region has moved Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 3/6] Set runstate to INMIGRATE earlier Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 4/6] cirrus_vga: do not reset videoram on resume Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 5/6] xen: record physmap changes to xenstore Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-20 17:21 ` [Qemu-devel] [PATCH v4 6/6] xen: change memory access behavior during migration Stefano Stabellini
2012-01-20 17:21 ` Stefano Stabellini
2012-01-20 17:59 ` [Qemu-devel] [PATCH v4 0/6] save/restore on Xen Jan Kiszka
2012-01-20 17:59 ` Jan Kiszka
2012-01-23 10:47 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 10:47 ` Stefano Stabellini
2012-01-23 11:50 ` [Qemu-devel] " Jan Kiszka
2012-01-23 11:50 ` Jan Kiszka
2012-01-23 11:59 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 11:59 ` Stefano Stabellini
2012-01-23 12:10 ` [Qemu-devel] " Jan Kiszka
2012-01-23 12:10 ` Jan Kiszka
2012-01-23 14:46 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 14:46 ` Stefano Stabellini
2012-01-23 15:46 ` [Qemu-devel] " Jan Kiszka
2012-01-23 15:46 ` Jan Kiszka
2012-01-23 16:16 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 16:16 ` Stefano Stabellini
2012-01-23 16:22 ` [Qemu-devel] " Anthony Liguori
2012-01-23 16:22 ` Anthony Liguori
2012-01-23 17:13 ` [Qemu-devel] " Jan Kiszka
2012-01-23 17:13 ` Jan Kiszka
2012-01-23 17:18 ` [Qemu-devel] " Anthony Liguori
2012-01-23 17:18 ` Anthony Liguori
2012-01-23 17:31 ` [Qemu-devel] " Jan Kiszka
2012-01-23 17:31 ` Jan Kiszka
2012-01-23 17:36 ` [Qemu-devel] " Anthony Liguori
2012-01-23 17:36 ` Anthony Liguori
2012-01-24 10:21 ` [Qemu-devel] " Gerd Hoffmann
2012-01-24 10:21 ` Gerd Hoffmann
2012-01-24 11:13 ` [Qemu-devel] " Avi Kivity
2012-01-24 11:13 ` Avi Kivity
2012-01-24 12:00 ` [Qemu-devel] " Stefano Stabellini
2012-01-24 12:00 ` Stefano Stabellini
2012-01-24 15:39 ` Avi Kivity [this message]
2012-01-24 15:39 ` Avi Kivity
2012-01-24 13:18 ` [Qemu-devel] " Anthony Liguori
2012-01-24 13:18 ` Anthony Liguori
2012-01-24 15:43 ` [Qemu-devel] " Avi Kivity
2012-01-24 15:43 ` Avi Kivity
2012-01-24 13:25 ` [Qemu-devel] " Anthony Liguori
2012-01-24 13:25 ` Anthony Liguori
2012-01-24 15:47 ` [Qemu-devel] " Avi Kivity
2012-01-24 15:47 ` Avi Kivity
2012-01-24 11:10 ` [Qemu-devel] " Avi Kivity
2012-01-24 11:10 ` Avi Kivity
2012-01-24 11:27 ` [Qemu-devel] " Paolo Bonzini
2012-01-24 11:27 ` Paolo Bonzini
2012-01-24 11:32 ` [Qemu-devel] " Avi Kivity
2012-01-24 11:32 ` Avi Kivity
2012-01-24 11:44 ` [Qemu-devel] " Paolo Bonzini
2012-01-24 11:44 ` Paolo Bonzini
2012-01-24 15:48 ` [Qemu-devel] " Avi Kivity
2012-01-24 15:48 ` Avi Kivity
2012-01-24 11:52 ` [Qemu-devel] " Stefano Stabellini
2012-01-24 11:52 ` Stefano Stabellini
2012-01-24 13:15 ` [Qemu-devel] " Anthony Liguori
2012-01-24 13:15 ` Anthony Liguori
2012-01-24 13:14 ` [Qemu-devel] " Anthony Liguori
2012-01-24 13:14 ` Anthony Liguori
2012-01-24 15:56 ` [Qemu-devel] " Avi Kivity
2012-01-24 15:56 ` Avi Kivity
2012-01-24 17:51 ` [Qemu-devel] " Anthony Liguori
2012-01-24 17:51 ` Anthony Liguori
2012-01-23 16:00 ` [Qemu-devel] " Anthony Liguori
2012-01-23 16:00 ` Anthony Liguori
2012-01-23 16:46 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 16:46 ` Stefano Stabellini
2012-01-23 16:54 ` [Qemu-devel] " Anthony Liguori
2012-01-23 16:54 ` Anthony Liguori
2012-01-23 17:05 ` [Qemu-devel] " Stefano Stabellini
2012-01-23 17:05 ` Stefano Stabellini
2012-01-23 17:07 ` [Qemu-devel] " Anthony Liguori
2012-01-23 17:07 ` Anthony Liguori
-- strict thread matches above, loose matches on Subject: below --
2012-01-25 13:04 [Qemu-devel] " Stefano Stabellini
2012-01-31 15:50 ` Stefano Stabellini
2012-02-13 12:20 ` Stefano Stabellini
2012-02-21 10:22 ` Stefano Stabellini
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=4F1ED0C3.7030008@redhat.com \
--to=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kraxel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.