[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen

On 01/23/2012 11:31 AM, Jan Kiszka wrote:
On 2012-01-23 18:18, Anthony Liguori wrote:
On 01/23/2012 11:13 AM, Jan Kiszka wrote:
To reply to your previous question more clearly: at restore time Qemu on
Xen would run in a non-standard scenario; the restore of the RAM happens
before QEMU is even started.

That is unfortunate but it would be very hard to change (I can give you
more details if you are interested in the reasons why it would be so

If you can't change this, you need to properly introduce this new
scenario - pre-initialized RAM - to the QEMU device model. Or you will
see breakage outside cirrus sooner or later as well. So it might be good
to explain the reason why it can't be changed under Xen when motivating
this concept extension to QEMU.

Are you thinking about introducing this concept as a new runstate?
This special runstate could be set at restore time only on Xen.

BTW the main reasons for having Xen saving the RAM are:

- the need to support PV guests, that often run without Qemu;
- the current save format, that is built around the fact that Xen saves the 
- the fact that Qemu might be running in a very limited stub-domain.

Your problem is not the fact that guest RAM is restored by an external
component. Your problem is that QEMU has no control over the when. If
you fix this, you could coordinate the restoring with the initial device
reset and would solve all potential current and future issues, not only
this single cirrus related one.

Generally speaking, RAM is an independent device in most useful cases.  Onboard
RAM is a very special case because it's extremely unusual.

But since some video cards can make use of dedicated external RAM, I don't think
any video card really depends on initial RAM state.

What's most likely here is that the VGA BIOS of a Cirrus card sets an initial
RAM state during device initialization.

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.  The main problem
here I believe is that we have part of the VGA Bios functionality in the
hardware emulation.

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.

QXL also has a VGA BIOS that it could use to initialize VRAM. A similar change could be made for it.

In general, devices shouldn't make assumptions about the state of other devices during reset. Writing to RAM assumes that RAM has been fully initialized. We don't express reset dependencies right now and it's not clear to me that this is something that we should be modeling.


Anthony Liguori


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.