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

[Jan Kiszka <jan.kiszka@xxxxxxxxxxx>]

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.

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

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

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