[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
On 01/23/2012 10:16 AM, Stefano Stabellini wrote:
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.
A runstate is not the right approach. Don't abuse existing commands/protocols
to make them have a different function on Xen.
Just introduce a new command that has the behavior you want.
Regards,
Anthony Liguori
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
