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.