Re: [PATCH V2 00/11] allow cpr-reboot for vfio

[David Hildenbrand <david@redhat.com>]

On 15.01.24 11:48, David Hildenbrand wrote:
> On 12.01.24 16:04, Steve Sistare wrote:
>> Allow cpr-reboot for vfio if the guest is in the suspended runstate.  The
>> guest drivers' suspend methods flush outstanding requests and re-initialize
>> the devices, and thus there is no device state to save and restore.  The
>> user is responsible for suspending the guest before initiating cpr, such as
>> by issuing guest-suspend-ram to the qemu guest agent.
> 
> Can you briefly explain what cpr-reboot is, or do you have a pointer to
> some more details?
> 
> What is is good for, why would you use it, how does it work?
> 
> I *suspect* that you want to live-migrate a VM with vfio devices
> attached, whereby you don't want to migrate device state.
> 

Ah, found it:

+# @cpr-reboot: The migrate command saves state to a file, allowing one to
+#              quit qemu, reboot to an updated kernel, and restart an updated
+#              version of qemu.  The caller must specify a migration URI
+#              that writes to and reads from a file.  Unlike normal mode,
+#              the use of certain local storage options does not block the
+#              migration, but the caller must not modify guest block devices
+#              between the quit and restart.  To avoid saving guest RAM to the
+#              file, the memory backend must be shared, and the @x-ignore-shared
+#              migration capability must be set.  Guest RAM must be non-volatile
+#              across reboot, such as by backing it with a dax device, but this
+#              is not enforced.  The restarted qemu arguments must match those
+#              used to initially start qemu, plus the -incoming option.
+#              (since 8.2)

I'll note that the use of "reboot" is extremely confusing in this context.
You *might* want to reboot the hypervisor, but that's actually completely
independent from the QEMU implementation.

-- 
Cheers,

David / dhildenb