Re: [PATCH] Add query-tdx-capabilities

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jan 09, 2026 at 10:30:32AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Tue, Jan 06, 2026 at 10:36:20PM +0400, marcandre.lureau@redhat.com wrote:
> >> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >> 
> >> Return an empty TdxCapability struct, for extensibility and matching
> >> query-sev-capabilities return type.
> >> 
> >> Fixes: https://issues.redhat.com/browse/RHEL-129674
> >> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >> ---
> >>  qapi/misc-i386.json        | 30 ++++++++++++++++++++++++++++++
> >>  target/i386/kvm/kvm_i386.h |  1 +
> >>  target/i386/kvm/kvm.c      |  5 +++++
> >>  target/i386/kvm/tdx-stub.c |  8 ++++++++
> >>  target/i386/kvm/tdx.c      | 21 +++++++++++++++++++++
> >>  5 files changed, 65 insertions(+)
> >> 
> >> diff --git a/qapi/misc-i386.json b/qapi/misc-i386.json
> >> index 05a94d6c416..f10e4338b48 100644
> >> --- a/qapi/misc-i386.json
> >> +++ b/qapi/misc-i386.json
> >> @@ -225,6 +225,36 @@
> >>  ##
> >>  { 'command': 'query-sev-capabilities', 'returns': 'SevCapability' }
> >>  
> >> +##
> >> +# @TdxCapability:
> >> +#
> >> +# The struct describes capability for Intel Trust Domain Extensions
> >> +# (TDX) feature.
> >> +#
> >> +# Since: 11.0
> >> +##
> >> +{ 'struct': 'TdxCapability',
> >> +  'data': { } }
> >> +
> >> +##
> >> +# @query-tdx-capabilities:
> >> +#
> >> +# Get TDX capabilities.
> >> +#
> >> +# This is only supported on Intel X86 platforms with KVM enabled.
> >> +#
> >> +# Errors:
> >> +#     - If TDX is not available on the platform, GenericError
> >> +#
> >> +# Since: 11.0
> >> +#
> >> +# .. qmp-example::
> >> +#
> >> +#     -> { "execute": "query-tdx-capabilities" }
> >> +#     <- { "return": {} }
> >> +##
> >> +{ 'command': 'query-tdx-capabilities', 'returns': 'TdxCapability' }
> >
> > This matches the conceptual design used with query-sev-capabilities,
> > where the lack of SEV support has to be inferred from the command
> > returning "GenericError".
> 
> Such guesswork is brittle.  An interface requiring it is flawed, and
> should be improved.
> 
> Our SEV interface doesn't actually require it: query-sev tells you
> whether we have SEV.  Just run that first.

Actually these commands are intended for different use cases.

"query-sev" only returns info if you have launched qemu with

  $QEMU -object sev-guest,id=cgs0  -machine confidential-guest-support=cgs0

The goal of "query-sev-capabilities" is to allow you to determine
if the combination of host+kvm+qemu are capable of running a guest
with "sev-guest".

IOW, query-sev-capabilities alone is what you want/need in order
to probe host features.

query-sev is for examining running guest configuration

> This patch adds query-tdx-capabilities without query-tdx.  This results
> in a flawed interface.
> 
> Should we add a query-tdx instead?

No, per the above explanation of the differences.

> 
> >                           On the one hand this allows the caller to
> > distinguish different scenarios - unsupported due to lack of HW
> > support, vs unsupported due to lack of KVM support. On the other
> > hand 'GenericError' might reflect other things that should be
> > considered fatal errors, rather than indicitive of lack of support
> > in the host.
> >
> > With the other 'query-sev' command, we have "enabled: bool" field,
> > and when enabled == false, the other fields are documented to have
> > undefined values.
> 
> Clunky, but works.
> 
> The doc comment calls them "unspecified", which is more precise.
> 
> > I tend towards suggesting that 'query-sev-capabilities' (and thus
> > also this new query-tdx-capabilities) should have been more like
> > query-sev,  and had a a "supported: bool" field to denote the lack
> > of support in the host.
> 
> Maybe.  What we have there is workable, though.
> 
> > This would not have allowed callers to disinguish the reason why
> > SEV/TDX is not supported (hardware vs KVM), but I'm not sure that
> > reason matters for callers - lack of KVM support is more of an
> > OS integration problem.
> 
> Let's not complicate interfaces without an actual use case :)
> 
> [...]
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|