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