On Sat, Sep 12, 2026 at 07:52:43AM +0200, Markus Armbruster wrote: > Michael Roth <[email protected]> writes: > > > On Wed, Sep 09, 2026 at 08:20:36AM +0200, Markus Armbruster wrote: > >> Michael Roth <[email protected]> writes: > >> > >> > For confidential guests, guest_memfd is currently used only for private > >> > guest memory, and normal guest memory comes from the configured memory > >> > backend just as it does for a non-confidential guest. It is now possible > >> > to use the same physical memory to back a particular GPA regardless of > >> > whether it is in a shared or private state. This avoids the need to > >> > rely on discarding memory between shared/private conversions (to avoid > >> > doubled memory usage), and is intended to be the primary mode of using > >> > guest_memfd for confidential guests moving forward, and future features > >> > like hugepage support will likely require it. > >> > > >> > Add an option to enable this support. Since ConfidentialGuestSupport is > >> > already used to track some guest_memfd-related functionality (e.g. > >> > whether it is required for the configured machine), similarly introduce > >> > this option as a property of ConfidentialGuestSupport. > >> > > >> > Also add the KVM-specific checks to enable this support, but leave the > >> > option disabled until other required changes are implemented for > >> > CGS variants that intend to make use of KVM's in-place conversion > >> > support. > >> > > >> > While technically the convert-in-place option could be introduced as an > >> > SEV-specific option, it is a given that TDX will also be introducing > >> > in-place conversion support based on the same guest_memfd kernel > >> > infrastructure, so introduce it via a new > >> > ConfidentialGuestSupportProperties base class that other confidential VM > >> > implementations can utilized for common options. > >> > > >> > Signed-off-by: Michael Roth <[email protected]> > >> > >> [...] > >> > >> > diff --git a/qapi/qom.json b/qapi/qom.json > >> > index 909add4299..20d6fefb04 100644 > >> > --- a/qapi/qom.json > >> > +++ b/qapi/qom.json > >> > @@ -1005,6 +1005,21 @@ > >> > 'if': 'CONFIG_IGVM', > >> > 'data': { 'file': 'str' } } > >> > > >> > +## > >> > +# @ConfidentialGuestSupportProperties: > >> > +# > >> > +# Properties for ConfidentialGuestSupport base class. > >> > +# > >> > +# @convert-in-place: If true, the same physical pages are reused > >> > +# when memory is converted between shared and private states. > >> > +# If false (default), separate allocations are used depending > >> > +# on whether the page is private or shared. > >> > >> Any guidance on when to enable @convert-in-place? > > > > A lot of it boils down to more Confidential Compute architectures > > now requiring it for new features (hugepage support and SEV-TIO will > > require it for instance). convert-in-place=true maps more closely to > > a normal VM, and not having more complicated memory management > > requirements avoids additional complications up the stack (like > > accounting for instances where memory usage might balloon passed > > expected resource limits due to needing to management multiple > > memory allocations for a given GPA range). > > > > convert-in-place=false will likely become a legacy path unless other > > use-case arise, but they'd probably need to be super-duper useful > > to warrant enabling new things on top of it going forward. > > What are the use cases for false *now*? > > Can a change from false to true upset a guest?
Yes, since the in-place conversion support is advertised through a combination of new KVM capability bits and gmem flags, and those will only be available in new kernels, so it would break most existing SNP/TDX deployments. So we'd likely want to keep convert-in-place=false as the default for some time, or at least keep it set to false for older machine types that support SNP/TDX but predate QEMU in-place conversion support. But even for new machine types where we might consider defaulting to convert-in-place=true, we'd want some way to switch it off for SNP/TDX so they can still run on older kernels, because it's not a deprecated mode (yet) and does still enable a few things that won't be available for in-place=true for a while (like being able to use THP/hugepages for non-private GPA ranges at least). But we also don't want to automatically choose between in-place=false vs. in-place=true based on kernel capabilities because userspace needs to be aware of which mode it is running in due to differences in how memory needs to be accounted/managed further up the stack. So for SNP/TDX I think a knob is needed, but for newer architectures I'd imagine they'd just want to enable in-place=true from the start and not deal with the legacy support.... Actually...I hadn't even noticed yet, but the ARM Realm/CCA support[1] is based on v1 of this series, and it looks like they'd be setting convert-in-place=true from the start. So for that series, it would probably make sense to not expose the 'convert-in-place' option at all (which should be easier when I rework that option for v3 to be implementation-specific instead of via a common base type). Thanks, Mike [1] https://lore.kernel.org/qemu-devel/[email protected]/ > > > I'll try to work something along that line into the guest-memfd.rst > > I proposed for Peter's series and add/reference that as part of this > > patch. > > > >> > >> > +# > >> > +# Since: 11.2 > >> > +## > >> > +{ 'struct': 'ConfidentialGuestSupportProperties', > >> > + 'data': { '*convert-in-place': 'bool' } } > >> > + > >> > ## > >> > # @SevCommonProperties: > >> > # > > [...] >
