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

[Jan Kiszka <jan.kiszka@xxxxxxxxxxx>]

On 2012-01-23 17:16, 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"?

The comment is correct. It refers to the invocation of the function from
the vmload handler. Here, a flag is passed that says "don't overwrite".

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

Your problem is not the fact that guest RAM is restored by an external
component. Your problem is that QEMU has no control over the when. If
you fix this, you could coordinate the restoring with the initial device
reset and would solve all potential current and future issues, not only
this single cirrus related one.

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