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

[Anthony Liguori <anthony@codemonkey.ws>]

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