From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.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>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 07:14:47 -0600 [thread overview]
Message-ID: <4F1EAEC7.5050304@codemonkey.ws> (raw)
In-Reply-To: <4F1E91AF.9040402@redhat.com>
On 01/24/2012 05:10 AM, Avi Kivity wrote:
> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>> Generally speaking, RAM is an independent device in most useful cases.
>
> Can you give examples? Do you mean a subdevice with composition, or a
> really independent device?
I expect we'll have one Ram device. It's size will be configurable. One Ram
device will hang off of the machine which would be the main ram.
A video card would have a Ram device via composition.
The important consideration about reset is how it propagates. My expectation is
that we'll propagate reset through the composition tree in a preorder
transversal. That means in the VGA device reset function, it's child device
(Ram) has not been reset yet.
>> Onboard RAM is a very special case because it's extremely unusual.
>
> What's unusual (or even extremely unusual) about it? I don't see a
> difference between a few billion bits of state and, say, the few bits of
> state in an RTC device.
Okay, but let's not get philosophical here :-) There are very few devices that
have a DRAM chip that is mapped through a bar into the main address space and
behaves (usually) like normal RAM.
>> We really should view RAM as just another device so I don't like the
>> idea of propagating a global concept of "when RAM is restored" because
>> that treats it specially compared to other devices.
>
> Agree. In fact the first step has been taken as now creating a RAM
> region with memory_region_init_ram() doesn't register it for migration.
> The next step would be a VMSTATE_RAM() to make it part of the containing
> device.
That's not necessary (or wise).
Let's not confuse a Ram device with a MemoryRegion. They are separate things
and should be treated as separate things. I thought we discussed that
MemoryRegions are stateless (or at least, there state is all derived) and don't
need to be serialized?
Regards,
Anthony Liguori
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.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>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 07:14:47 -0600 [thread overview]
Message-ID: <4F1EAEC7.5050304@codemonkey.ws> (raw)
In-Reply-To: <4F1E91AF.9040402@redhat.com>
On 01/24/2012 05:10 AM, Avi Kivity wrote:
> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>> Generally speaking, RAM is an independent device in most useful cases.
>
> Can you give examples? Do you mean a subdevice with composition, or a
> really independent device?
I expect we'll have one Ram device. It's size will be configurable. One Ram
device will hang off of the machine which would be the main ram.
A video card would have a Ram device via composition.
The important consideration about reset is how it propagates. My expectation is
that we'll propagate reset through the composition tree in a preorder
transversal. That means in the VGA device reset function, it's child device
(Ram) has not been reset yet.
>> Onboard RAM is a very special case because it's extremely unusual.
>
> What's unusual (or even extremely unusual) about it? I don't see a
> difference between a few billion bits of state and, say, the few bits of
> state in an RTC device.
Okay, but let's not get philosophical here :-) There are very few devices that
have a DRAM chip that is mapped through a bar into the main address space and
behaves (usually) like normal RAM.
>> We really should view RAM as just another device so I don't like the
>> idea of propagating a global concept of "when RAM is restored" because
>> that treats it specially compared to other devices.
>
> Agree. In fact the first step has been taken as now creating a RAM
> region with memory_region_init_ram() doesn't register it for migration.
> The next step would be a VMSTATE_RAM() to make it part of the containing
> device.
That's not necessary (or wise).
Let's not confuse a Ram device with a MemoryRegion. They are separate things
and should be treated as separate things. I thought we discussed that
MemoryRegions are stateless (or at least, there state is all derived) and don't
need to be serialized?
Regards,
Anthony Liguori
next prev parent reply other threads:[~2012-01-24 13:15 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 ` [Qemu-devel] " Avi Kivity
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 ` Anthony Liguori [this message]
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=4F1EAEC7.5050304@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=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.