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

[Anthony Liguori]

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

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 :-)).

Regards,

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.
>
> cheers,
>    Gerd