[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/24/2012 04:21 AM, Gerd Hoffmann wrote:

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.

It is, but probably not in the way you're assuming that I mean it is.

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.

This should be done by firmware or system software. Devices don't initialize memory with data structures on power up. The first problem with doing this is that it assumes a reset order which would lengthen the quiescing process. The second problem is that this would require fairly sophisticated logic that could just as well live in firmware.

The advantage of not enabling a device to behave like this is it lets us do a much simpler reset model. To model this properly, we would have to support multiple reset propagation hooks (at least a preorder and postorder hook). This adds a fair amount of complication for not a lot of benefit (the only benefit is moving firmware logic into QEMU which is really a downside :-)).


Anthony Liguori

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.


Xen-devel mailing list



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