On Fri, Aug 21, 2026 at 01:11:23PM -0700, Dongli Zhang wrote: > So far I only added support for cpr-exec. I have not tried othe modes. > > In my opinion, cpr-transfer could also use a memfd-backed channel, but I am > not > sure it is necessary. > > For cpr-transfer, the source and destination are separate QEMU processes. If > we > want to pass a memfd between them, we still need an IPC mechanism that can > transfer file descriptors, such as a Unix domain socket with SCM_RIGHTS. That > reduces the value of using memfd as the migration channel, because we need at > least one Unix domain socket anyway to pass the memfd fd and coordinate the > handoff. > > If a Unix domain socket is already required, the main benefit of memfd would > likely be performance, especially when the device state is large.
I'm actually not sure dumping everything into one fd, then share it via the other unix socket will be faster: the destination side can already start parsing concurrently while reading things out, rather than waiting for everything to land the page cache inside the memfd. So I actually don't know if this will ever be useful by anything except cpr-exec. > > cpr-exec is different. The new QEMU is started via exec(), so the memfd fd can > be preserved across exec by clearing CLOEXEC and passing the fd number through > an environment variable. This allows us to add a memfd-backed migration > channel > without needing an external file or socket for the device state. > > One potential future use case is LUO/KHO support for QEMU. In that case, > device > state could be preserved in memory as a memfd and potentially survive across a > KHO kexec. We won't need to preserve anything on storage. Indeed, I did some > internal tests using memfd to preserve device state across kexec although > using > different implementation, and it worked. IIUC we can already do it: migrate file:/dev/shm/something, then make that file handle persistent. Then the question is, can we stick with that too for your feature? Instead of introducing the "memfd:" type, just use file? Note that non-huge memfd should literally be shmem at least on Linux. Thanks, -- Peter Xu
