Re: [PATCH v2 07/19] accel/kvm: Add CGS option to control in-place conversion support

[Markus Armbruster <armbru@redhat.com>]

Michael Roth <michael.roth@amd.com> writes:

> On Wed, Sep 09, 2026 at 08:20:36AM +0200, Markus Armbruster wrote:
>> Michael Roth <michael.roth@amd.com> 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 <michael.roth@amd.com>
>> 
>> [...]
>> 
>> > 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?

> 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:
>> >  #

[...]