| Message ID | 20240904103722.946194-1-jmarcin@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | virtio-mem: Implement support for suspend+wake-up with plugged memory | expand |
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.
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(-)