Currently, the virtio-mem device would unplug all the memory with any
reset request, including when the machine wakes up from a suspended
state (deep sleep). This would lead to a loss of the contents of the
guest memory and therefore is disabled by the virtio-mem Linux Kernel
driver unless the VIRTIO_MEM_F_PERSISTENT_SUSPEND virtio feature is
exposed. [1]

To make deep sleep with virtio-mem possible, we need to differentiate
cold start reset from wake-up reset. The first patch updates
qemu_system_reset() and MachineClass children to accept ResetType
instead of ShutdownCause, which then could be passed down the device
tree. The second patch then introduces the new reset type for the
wake-up event and updates the i386 wake-up method (only architecture
using the explicit wake-up method).

The third patch replaces LegacyReset with the Resettable interface in
virtio-mem, so the memory device can access the reset type in the hold
phase. The last patch of the series implements the final support in the
hold phase of the virtio-mem reset callback and exposes
VIRTIO_MEM_F_PERSISTENT_SUSPEND to the kernel.

[1]: https://lore.kernel.org/all/20240318120645.105664-1-david@redhat.com/

v3:
- Updated RESET_TYPE_WAKEUP documentation so it is more clear when reset
  could occur and when reset type should be used, thanks to Peter and
  David for feedback

v2:
- Removed unnecessary include directive changes
- Updated RESET_TYPE_WAKEUP documentation
- Removed unnecessary interface from VirtIOMEMClass type info

Juraj Marcin (4):
  reset: Use ResetType for qemu_devices_reset() and
    MachineClass::reset()
  reset: Add RESET_TYPE_WAKEUP
  virtio-mem: Use new Resettable framework instead of LegacyReset
  virtio-mem: Add support for suspend+wake-up with plugged memory

 docs/devel/reset.rst           | 11 ++++++++
 hw/arm/aspeed.c                |  4 +--
 hw/arm/mps2-tz.c               |  4 +--
 hw/core/reset.c                |  5 +---
 hw/hppa/machine.c              |  4 +--
 hw/i386/microvm.c              |  4 +--
 hw/i386/pc.c                   |  6 ++---
 hw/ppc/pegasos2.c              |  4 +--
 hw/ppc/pnv.c                   |  4 +--
 hw/ppc/spapr.c                 |  6 ++---
 hw/s390x/s390-virtio-ccw.c     |  4 +--
 hw/virtio/virtio-mem.c         | 48 ++++++++++++++++++++++++----------
 hw/virtio/virtio-qmp.c         |  3 +++
 include/hw/boards.h            |  3 ++-
 include/hw/resettable.h        |  2 ++
 include/hw/virtio/virtio-mem.h |  4 +++
 include/sysemu/reset.h         |  5 ++--
 system/runstate.c              | 13 +++++++--
 18 files changed, 91 insertions(+), 43 deletions(-)

-- 
2.46.0

On 04.09.24 12:37, Juraj Marcin wrote:
> Currently, the virtio-mem device would unplug all the memory with any
> reset request, including when the machine wakes up from a suspended
> state (deep sleep). This would lead to a loss of the contents of the
> guest memory and therefore is disabled by the virtio-mem Linux Kernel
> driver unless the VIRTIO_MEM_F_PERSISTENT_SUSPEND virtio feature is
> exposed. [1]
> 
> To make deep sleep with virtio-mem possible, we need to differentiate
> cold start reset from wake-up reset. The first patch updates
> qemu_system_reset() and MachineClass children to accept ResetType
> instead of ShutdownCause, which then could be passed down the device
> tree. The second patch then introduces the new reset type for the
> wake-up event and updates the i386 wake-up method (only architecture
> using the explicit wake-up method).
> 
> The third patch replaces LegacyReset with the Resettable interface in
> virtio-mem, so the memory device can access the reset type in the hold
> phase. The last patch of the series implements the final support in the
> hold phase of the virtio-mem reset callback and exposes
> VIRTIO_MEM_F_PERSISTENT_SUSPEND to the kernel.
> 
> [1]: https://lore.kernel.org/all/20240318120645.105664-1-david@redhat.com/

Thanks, I'll queue this to

https://github.com/davidhildenbrand/qemu.git mem-next

@Peter, it would be great if you could have another look at patch #2, 
thanks.

-- 
Cheers,

David / dhildenb