On Tue, Dec 30, 2025 at 3:30 AM Li Chen <[email protected]> wrote: > > Hi Pasha, > > Thanks for the detailed clarification, that's very helpful. > > ---- On Mon, 29 Dec 2025 23:50:35 +0800 Pasha Tatashin > <[email protected]> wrote --- > > 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. > > Ack, and sorry for my cover letter text over-simplified the design. > > > > 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". > > One question: in the intended LUOD/session architecture, do you still expect > clients (or a wrapper) to inject the retrieved guest RAM memfd FD into QEMU > via -add-fd + /dev/fdset/<id> at QEMU startup? (as this patchset does) > > Or is the longer-term plan that QEMU itself connects to LUOD over UDS, > retrieves > the session/resource FD directly, and consumes it as the RAM backing without > going through -add-fd?
The latter, I expect QEMU and other VMMs use their LUO session FDs that they receive from LUOD to retrieve and restore the preserved resources: memfd+iommufd+vfiofd and resume the suspended VMs. > > If the latter, I think we'd likely need a QEMU-side interface to > consume an inherited/pre-opened FD for RAM backing during early machine init. > > Regards, > > Li >
