On Fri, Aug 14, 2026 at 04:27:31PM +0100, Daniel P. Berrangé wrote: > Yes, if we think we can make QEMU "do the right thing" internally > that makes a separate object much less desirable. That would > be saying that we have a tri-state, guest_memfd=auto|on|off, > and such tri-state's would not invite a separate sub-class > design. The need for "auto" rather forces the approach you have > in this patch.
Just to mention, one option here is we don't introduce "auto" at all, guest-memfd=on could explicitly mean the init full shared mode too. IOW, when used in a CoCo context, memfd objects will be normally silently created with guest-memfds, like what we used to silently create guest-memfd 2nd layer without any cmdlines, but this time when in-place convertable it'll be the solo backend. User doesn't even need to know. Then, when guest-memfd=on is specified in such a CoCo context, it should be able to make this specific chunk of memory "init-shared", while the rest could still be in-place convertable. This may make the cmdline slightly more flexible to allow init shared also in CoCo. But I confess I don't know if that would be useful ultimately, and I didn't think all things through. Thanks, -- Peter Xu
