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.
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:
> > #
> > @@ -1033,6 +1048,7 @@
> > # Since: 9.1
> > ##
> > { 'struct': 'SevCommonProperties',
> > + 'base': 'ConfidentialGuestSupportProperties',
> > 'data': { '*sev-device': 'str',
> > '*cbitpos': 'uint32',
> > 'reduced-phys-bits': 'uint32',
>
> Can you explain why you put @convert-in-place into a new base type
> instead of right here?
>
I tried to touch on this as part of the commit message, but I don't think I
explained the rationale very well and I'm now second-guessing myself.
As part of this patch, a 'allow_convert_in_place' field is added to
ConfidentialGuestSupport, which is similar to the 'require_guest_memfd'
ConfidentialGuestSupport member in that it's configuring policy around the
usage of guest_memfd for Confidential machine instances. They also both
need to be ordered soon enough that they initialized in time for the related
KVM capability checks in kvm_init(), so another reason to place it there.
>From there my thinking was that the 'convert-in-place' property exposed on the
command-line would basically just set true/false based on whether the
'allow_convert_in_place' CGS value is set, and that that pattern would be the
same for TDX, who AFAIK are fully onboard with switching over to
convert-in-place=true as well, so I added the common base properties where other
archs could just subclass it expose the same feature.
But thinking more on some discoverability thing Daniel mentioned, that makes it
potentially problematic if more common features get added, and *then* another
CGS implementation wants to subclass the common QOM properties for 1
option/feature (e.g. @convert_in_place) but not some other option/features
that's since been added.
So keeping it as an architecture-defined property is probably the better call.
It's only a trivial amount of code duplication and some archs will just have it
always on anyway where it doesn't even make sense to expose it.
So I'll plan to take that approach for the next spin.
Thanks,
Mike
