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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> On 2012-01-23 15:46, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-23 12:59, Stefano Stabellini wrote:
> >>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >>>>>> Or what is the ordering
> >>>>>> of init, RAM restore, and initial device reset now?
> >>>>>
> >>>>> RAM restore (done by Xen)
> >>>>>
> >>>>> physmap rebuild (done by xen_hvm_init in qemu)
> >>>>> pc_init()
> >>>>> qemu_system_reset()
> >>>>> load_vmstate()
> >>>>
> >>>> Hmm, are you sure that this is the only case where a device init or
> >>>> reset handler writes to already restored guest memory? Preloading the
> >>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
> >>>> fragile. Does restoring happen before QEMU is even started, or can this
> >>>> point be controlled from QEMU?
> >>>
> >>> Consider that this only happens with non-MMIO device memory, in practice
> >>> only videoram.
> >>> Vmware VGA does not memset the videoram in the reset handler, while QXL
> >>> already has the following:
> >>>
> >>>     /* pre loadvm reset must not touch QXLRam.  This lives in
> >>>      * device memory, is migrated together with RAM and thus
> >>>      * already loaded at this point */ if (!loadvm) {
> >>>      qxl_reset_state(d); }
> >>
> >> Yes, but QEMU restores the RAM _after_ device reset, not before it.
> >> That's the problem with the Xen way - it is against the current
> >> QEMU standard.
> > 
> > QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
> 
> But it does otherwise, and that's the scenario the code you cited was
> written for. It won't work as is under Xen.

Ah, I see your point now.
In that regard, is the comment above even correct?
I am referring to "migrated together with RAM and thus already loaded at
this point"?


> > 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
> > difficult).
> 
> 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.
 
OK.
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 
memory;
- the fact that Qemu might be running in a very limited stub-domain.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel