Hi Li, Thanks for the series. I have a few comments regarding the interaction with the LUO agent and the broader architecture.
> In the LUO/KHO update flow [1], a LUO agent coordinates a host kexec reboot > while keeping VM RAM content intact. LUO creates the guest RAM backing as a > memfd and passes it to QEMU via -add-fd on the initial launch, so that I am currently working on the LUO agent (LUOD) documentation, and the intended behavior differs slightly from this description. Rather than the agent simply passing FDs, the design involves LUOD opening /dev/liveupdate and creating a UDS socket (e.g., at /run/luod/liveupdate.sock). Live-update-capable clients connect to this socket, create a LUO session, and preserve their resources into that session. Once all clients notify LUOD that they are ready, LUOD performs the kexec reboot while keeping /dev/liveupdate open, ensuring the LUO sessions survive. After the reboot, the restarted clients reconnect to LUOD via UDS and request their preserved sessions. The sessions are passed as FDs back to the clients. From those sessions, the clients retrieve the resources, restore them, and resume suspended operations. Finally, the clients "finish" their sessions, fully reclaiming ownership of the preserved resources from LUO back to userspace. > memory-backend-file can use it as the shared RAM backing. On update, LUO > checkpoints QEMU, reboots the host kernel via kexec, and then re-launches QEMU > to restore vmstate while reusing the same preserved memfd-backed RAM FD. > Today LUO only supports handing off guest RAM via memfd [2]. > > To re-attach that preserved RAM backing without reopening non-persistent > paths, QEMU needs to let memory-backend-file consume the pre-opened FD using > mem-path=/dev/fdset/<id>. However, memory-backend-file currently uses > open()/creat() directly, so /dev/fdset/<id> cannot be resolved through the > fdset mechanism, making this workflow impossible. > > This series allows /dev/fdset/<id> for file-backed RAM, documents the setup, > and adds qtests to validate that x-ignore-shared keeps RAM transfer minimal > in the cpr-reboot path. Sessions become particularly relevant when we look beyond guest RAM. For complex resources like VFIO or IOMMU, simply passing the FD is insufficient. These resources require specific ioctls to be issued by clients after the FD is retrieved, but before vCPUs are resumed or the session is "finished". Pasha
