From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Avi Kivity <avi@redhat.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.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 11:21:41 +0100 [thread overview]
Message-ID: <4F1E8635.2020608@redhat.com> (raw)
In-Reply-To: <4F1D9A8E.1080102@codemonkey.ws>
Hi,
>>> 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.
>>>
>>> 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.
>> To my understanding, QXL will break identically on Xen for the same
>> reason: the reset handler assumes it can deal with the VRAM as it likes.
Yes. Some data structures for host <-> guest communication are living
in device memory, and a reset initializes these.
> QXL also has a VGA BIOS that it could use to initialize VRAM. A similar
> change could be made for it.
Hmm. Not sure this is a good idea.
cheers,
Gerd
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Avi Kivity <avi@redhat.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 11:21:41 +0100 [thread overview]
Message-ID: <4F1E8635.2020608@redhat.com> (raw)
In-Reply-To: <4F1D9A8E.1080102@codemonkey.ws>
Hi,
>>> 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.
>>>
>>> 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.
>> To my understanding, QXL will break identically on Xen for the same
>> reason: the reset handler assumes it can deal with the VRAM as it likes.
Yes. Some data structures for host <-> guest communication are living
in device memory, and a reset initializes these.
> QXL also has a VGA BIOS that it could use to initialize VRAM. A similar
> change could be made for it.
Hmm. Not sure this is a good idea.
cheers,
Gerd
next prev parent reply other threads:[~2012-01-24 10:22 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 ` Gerd Hoffmann [this message]
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 ` [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=4F1E8635.2020608@redhat.com \
--to=kraxel@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.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.