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.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
