[PATCH] Add query-tdx-capabilities

[PATCH] Add query-tdx-capabilities

[marcandre.lureau]

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' }
+
 ##
 # @sev-inject-launch-secret:
 #
diff --git a/target/i386/kvm/kvm_i386.h b/target/i386/kvm/kvm_i386.h
index 2b653442f4d..71dd45be47a 100644
--- a/target/i386/kvm/kvm_i386.h
+++ b/target/i386/kvm/kvm_i386.h
@@ -61,6 +61,7 @@ void kvm_put_apicbase(X86CPU *cpu, uint64_t value);
 
 bool kvm_has_x2apic_api(void);
 bool kvm_has_waitpkg(void);
+bool kvm_has_tdx(void);
 
 uint64_t kvm_swizzle_msi_ext_dest_id(uint64_t address);
 void kvm_update_msi_routes_all(void *private, bool global,
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 7b9b740a8e5..8ce25d7e785 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -6582,6 +6582,11 @@ bool kvm_has_waitpkg(void)
     return has_msr_umwait;
 }
 
+bool kvm_has_tdx(void)
+{
+    return kvm_is_vm_type_supported(KVM_X86_TDX_VM);
+}
+
 #define ARCH_REQ_XCOMP_GUEST_PERM       0x1025
 
 void kvm_request_xsave_components(X86CPU *cpu, uint64_t mask)
diff --git a/target/i386/kvm/tdx-stub.c b/target/i386/kvm/tdx-stub.c
index 1f0e108a69e..c4e7f2c58c8 100644
--- a/target/i386/kvm/tdx-stub.c
+++ b/target/i386/kvm/tdx-stub.c
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
 #include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qapi/qapi-commands-misc-i386.h"
 
 #include "tdx.h"
 
@@ -30,3 +32,9 @@ void tdx_handle_get_tdvmcall_info(X86CPU *cpu, struct kvm_run *run)
 void tdx_handle_setup_event_notify_interrupt(X86CPU *cpu, struct kvm_run *run)
 {
 }
+
+TdxCapability *qmp_query_tdx_capabilities(Error **errp)
+{
+    error_setg(errp, "TDX is not available in this QEMU");
+    return NULL;
+}
diff --git a/target/i386/kvm/tdx.c b/target/i386/kvm/tdx.c
index 01619857685..b5ee3b1ab92 100644
--- a/target/i386/kvm/tdx.c
+++ b/target/i386/kvm/tdx.c
@@ -14,6 +14,7 @@
 #include "qemu/base64.h"
 #include "qemu/mmap-alloc.h"
 #include "qapi/error.h"
+#include "qapi/qapi-commands-misc-i386.h"
 #include "qapi/qapi-visit-sockets.h"
 #include "qom/object_interfaces.h"
 #include "crypto/hash.h"
@@ -1537,6 +1538,26 @@ static void tdx_guest_finalize(Object *obj)
 {
 }
 
+static TdxCapability *tdx_get_capabilities(Error **errp)
+{
+    if (!kvm_enabled()) {
+        error_setg(errp, "TDX is not available without KVM");
+        return NULL;
+    }
+
+    if (!kvm_has_tdx()) {
+        error_setg(errp, "TDX is not supported by this host");
+        return NULL;
+    }
+
+    return g_new0(TdxCapability, 1);
+}
+
+TdxCapability *qmp_query_tdx_capabilities(Error **errp)
+{
+    return tdx_get_capabilities(errp);
+}
+
 static void tdx_guest_class_init(ObjectClass *oc, const void *data)
 {
     ConfidentialGuestSupportClass *klass = CONFIDENTIAL_GUEST_SUPPORT_CLASS(oc);
-- 
2.52.0

Re: [PATCH] Add query-tdx-capabilities

[Daniel P. Berrangé]

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". 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.

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.

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.




> +
>  ##
>  # @sev-inject-launch-secret:
>  #
> diff --git a/target/i386/kvm/kvm_i386.h b/target/i386/kvm/kvm_i386.h
> index 2b653442f4d..71dd45be47a 100644
> --- a/target/i386/kvm/kvm_i386.h
> +++ b/target/i386/kvm/kvm_i386.h
> @@ -61,6 +61,7 @@ void kvm_put_apicbase(X86CPU *cpu, uint64_t value);
>  
>  bool kvm_has_x2apic_api(void);
>  bool kvm_has_waitpkg(void);
> +bool kvm_has_tdx(void);
>  
>  uint64_t kvm_swizzle_msi_ext_dest_id(uint64_t address);
>  void kvm_update_msi_routes_all(void *private, bool global,
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 7b9b740a8e5..8ce25d7e785 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -6582,6 +6582,11 @@ bool kvm_has_waitpkg(void)
>      return has_msr_umwait;
>  }
>  
> +bool kvm_has_tdx(void)
> +{
> +    return kvm_is_vm_type_supported(KVM_X86_TDX_VM);
> +}
> +
>  #define ARCH_REQ_XCOMP_GUEST_PERM       0x1025
>  
>  void kvm_request_xsave_components(X86CPU *cpu, uint64_t mask)
> diff --git a/target/i386/kvm/tdx-stub.c b/target/i386/kvm/tdx-stub.c
> index 1f0e108a69e..c4e7f2c58c8 100644
> --- a/target/i386/kvm/tdx-stub.c
> +++ b/target/i386/kvm/tdx-stub.c
> @@ -1,6 +1,8 @@
>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>  
>  #include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qapi/qapi-commands-misc-i386.h"
>  
>  #include "tdx.h"
>  
> @@ -30,3 +32,9 @@ void tdx_handle_get_tdvmcall_info(X86CPU *cpu, struct kvm_run *run)
>  void tdx_handle_setup_event_notify_interrupt(X86CPU *cpu, struct kvm_run *run)
>  {
>  }
> +
> +TdxCapability *qmp_query_tdx_capabilities(Error **errp)
> +{
> +    error_setg(errp, "TDX is not available in this QEMU");
> +    return NULL;
> +}
> diff --git a/target/i386/kvm/tdx.c b/target/i386/kvm/tdx.c
> index 01619857685..b5ee3b1ab92 100644
> --- a/target/i386/kvm/tdx.c
> +++ b/target/i386/kvm/tdx.c
> @@ -14,6 +14,7 @@
>  #include "qemu/base64.h"
>  #include "qemu/mmap-alloc.h"
>  #include "qapi/error.h"
> +#include "qapi/qapi-commands-misc-i386.h"
>  #include "qapi/qapi-visit-sockets.h"
>  #include "qom/object_interfaces.h"
>  #include "crypto/hash.h"
> @@ -1537,6 +1538,26 @@ static void tdx_guest_finalize(Object *obj)
>  {
>  }
>  
> +static TdxCapability *tdx_get_capabilities(Error **errp)
> +{
> +    if (!kvm_enabled()) {
> +        error_setg(errp, "TDX is not available without KVM");
> +        return NULL;
> +    }
> +
> +    if (!kvm_has_tdx()) {
> +        error_setg(errp, "TDX is not supported by this host");
> +        return NULL;
> +    }
> +
> +    return g_new0(TdxCapability, 1);
> +}
> +
> +TdxCapability *qmp_query_tdx_capabilities(Error **errp)
> +{
> +    return tdx_get_capabilities(errp);
> +}
> +
>  static void tdx_guest_class_init(ObjectClass *oc, const void *data)
>  {
>      ConfidentialGuestSupportClass *klass = CONFIDENTIAL_GUEST_SUPPORT_CLASS(oc);
> -- 
> 2.52.0
> 

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

Re: [PATCH] Add query-tdx-capabilities

[Markus Armbruster]

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.

This patch adds query-tdx-capabilities without query-tdx.  This results
in a flawed interface.

Should we add a query-tdx instead?

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

[...]

Re: [PATCH] Add query-tdx-capabilities

[Daniel P. Berrangé]

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

Re: [PATCH] Add query-tdx-capabilities

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

[...]

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

The doc comments fail to explain this.  Needs fixing.

Do management applications need to know more than "this combination of
host + KVM + QEMU can do SEV, yes / no?

If yes, what do they need?  "No" split up into serval "No, because X"?

I'd like to propose that "human user of management application needs to
know more to debug things" does not count.  The error's @desc should
tell them all they need.

>> 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.

Got it.

[...]

Re: [PATCH] Add query-tdx-capabilities

[Daniel P. Berrangé]

On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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>
> 
> [...]
> 
> >> > 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
> 
> The doc comments fail to explain this.  Needs fixing.
> 
> Do management applications need to know more than "this combination of
> host + KVM + QEMU can do SEV, yes / no?
> 
> If yes, what do they need?  "No" split up into serval "No, because X"?

When libvirt runs  query-sev-capabilities it does not care about the
reason for it being unsupported.   Any "GenericError" is considered
to mark the lack of host support, and no fine grained checks are
performed on the err msg.

If query-sev-capabilities succeeds (indicating SEV is supported), then
all the returned info is exposed to mgmt apps in the libvirt domain
capabilities XML document.

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

Re: [PATCH] Add query-tdx-capabilities

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > 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>
>> 
>> [...]
>> 
>> >> > 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
>> 
>> The doc comments fail to explain this.  Needs fixing.
>> 
>> Do management applications need to know more than "this combination of
>> host + KVM + QEMU can do SEV, yes / no?
>> 
>> If yes, what do they need?  "No" split up into serval "No, because X"?
>
> When libvirt runs  query-sev-capabilities it does not care about the
> reason for it being unsupported.   Any "GenericError" is considered
> to mark the lack of host support, and no fine grained checks are
> performed on the err msg.
>
> If query-sev-capabilities succeeds (indicating SEV is supported), then
> all the returned info is exposed to mgmt apps in the libvirt domain
> capabilities XML document.

So query-sev-capabilities is good enough as is?

If yes, then the proposed query-tdx-capabilities should also be good
enough, shouldn't it?

Re: [PATCH] Add query-tdx-capabilities

[Daniel P. Berrangé]

On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> 
> >> > 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>
> >> 
> >> [...]
> >> 
> >> >> > 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
> >> 
> >> The doc comments fail to explain this.  Needs fixing.
> >> 
> >> Do management applications need to know more than "this combination of
> >> host + KVM + QEMU can do SEV, yes / no?
> >> 
> >> If yes, what do they need?  "No" split up into serval "No, because X"?
> >
> > When libvirt runs  query-sev-capabilities it does not care about the
> > reason for it being unsupported.   Any "GenericError" is considered
> > to mark the lack of host support, and no fine grained checks are
> > performed on the err msg.
> >
> > If query-sev-capabilities succeeds (indicating SEV is supported), then
> > all the returned info is exposed to mgmt apps in the libvirt domain
> > capabilities XML document.
> 
> So query-sev-capabilities is good enough as is?

IIUC, essentially all QEMU errors that could possibly be seen with
query-sev-capabilities are "GenericError" these days, except for
the small possibility of "CommandNotFound".

The two scenarios with lack of SEV support are covered by GenericError
but I'm concerned that other things that should be considered fatal
will also fall under GenericError.

eg take a look at qmp_dispatch() and see countless places where we can
return GenericError which ought to be treated as fatal by callers. 

IMHO  "SEV not supported" is not conceptually an error, it is an
expected informational result of query-sev-capabilities, and thus
shouldn't be using the QMP error object, it should have been a
boolean result field.

> If yes, then the proposed query-tdx-capabilities should also be good
> enough, shouldn't it?

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

Re: [PATCH] Add query-tdx-capabilities

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
>> >> Daniel P. Berrangé <berrange@redhat.com> writes:
>> >> 
>> >> > 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>
>> >> 
>> >> [...]
>> >> 
>> >> >> > 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
>> >> 
>> >> The doc comments fail to explain this.  Needs fixing.
>> >> 
>> >> Do management applications need to know more than "this combination of
>> >> host + KVM + QEMU can do SEV, yes / no?
>> >> 
>> >> If yes, what do they need?  "No" split up into serval "No, because X"?
>> >
>> > When libvirt runs  query-sev-capabilities it does not care about the
>> > reason for it being unsupported.   Any "GenericError" is considered
>> > to mark the lack of host support, and no fine grained checks are
>> > performed on the err msg.
>> >
>> > If query-sev-capabilities succeeds (indicating SEV is supported), then
>> > all the returned info is exposed to mgmt apps in the libvirt domain
>> > capabilities XML document.
>> 
>> So query-sev-capabilities is good enough as is?
>
> IIUC, essentially all QEMU errors that could possibly be seen with
> query-sev-capabilities are "GenericError" these days, except for
> the small possibility of "CommandNotFound".
>
> The two scenarios with lack of SEV support are covered by GenericError
> but I'm concerned that other things that should be considered fatal
> will also fall under GenericError.
>
> eg take a look at qmp_dispatch() and see countless places where we can
> return GenericError which ought to be treated as fatal by callers. 
>
> IMHO  "SEV not supported" is not conceptually an error, it is an
> expected informational result of query-sev-capabilities, and thus
> shouldn't be using the QMP error object, it should have been a
> boolean result field.

I agree that errors should be used only for "abnormal" outcomes, not for
the "no" answer to a simple question like "is SEV available, and if yes,
what are its capabilities?"

I further agree that encoding "no" as GenericError runs the risk of
conflating "no" with other errors.  Since query-sev itself can fail just
one way, these can only come from the QMP core.  For the core's syntax
and type errors, the risk is only theoretical: just don't do that.
Errors triggered by state, like the one in qmp_command_available(), are
a bit more worrying.  I think they're easy enough to avoid if you're
aware, but "if you're aware" is admittedly rittle.

Anyway, that's what we have.  Badly designed, but it seems to be
workable.

Is the bad enough to justify revising the interface?  I can't see how to
do that compatibly.

Is it bad enough to justify new interfaces for similar things to be
dissimilar?

>> If yes, then the proposed query-tdx-capabilities should also be good
>> enough, shouldn't it?
>
> With regards,
> Daniel

Re: [PATCH] Add query-tdx-capabilities

[Marc-André Lureau]

Hi

On Fri, Jan 9, 2026 at 4:27 PM Markus Armbruster <armbru@redhat.com> wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >>
> >> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
> >> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> >>
> >> >> > 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>
> >> >>
> >> >> [...]
> >> >>
> >> >> >> > 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
> >> >>
> >> >> The doc comments fail to explain this.  Needs fixing.
> >> >>
> >> >> Do management applications need to know more than "this combination of
> >> >> host + KVM + QEMU can do SEV, yes / no?
> >> >>
> >> >> If yes, what do they need?  "No" split up into serval "No, because X"?
> >> >
> >> > When libvirt runs  query-sev-capabilities it does not care about the
> >> > reason for it being unsupported.   Any "GenericError" is considered
> >> > to mark the lack of host support, and no fine grained checks are
> >> > performed on the err msg.
> >> >
> >> > If query-sev-capabilities succeeds (indicating SEV is supported), then
> >> > all the returned info is exposed to mgmt apps in the libvirt domain
> >> > capabilities XML document.
> >>
> >> So query-sev-capabilities is good enough as is?
> >
> > IIUC, essentially all QEMU errors that could possibly be seen with
> > query-sev-capabilities are "GenericError" these days, except for
> > the small possibility of "CommandNotFound".
> >
> > The two scenarios with lack of SEV support are covered by GenericError
> > but I'm concerned that other things that should be considered fatal
> > will also fall under GenericError.
> >
> > eg take a look at qmp_dispatch() and see countless places where we can
> > return GenericError which ought to be treated as fatal by callers.
> >
> > IMHO  "SEV not supported" is not conceptually an error, it is an
> > expected informational result of query-sev-capabilities, and thus
> > shouldn't be using the QMP error object, it should have been a
> > boolean result field.
>
> I agree that errors should be used only for "abnormal" outcomes, not for
> the "no" answer to a simple question like "is SEV available, and if yes,
> what are its capabilities?"
>
> I further agree that encoding "no" as GenericError runs the risk of
> conflating "no" with other errors.  Since query-sev itself can fail just
> one way, these can only come from the QMP core.  For the core's syntax
> and type errors, the risk is only theoretical: just don't do that.
> Errors triggered by state, like the one in qmp_command_available(), are
> a bit more worrying.  I think they're easy enough to avoid if you're
> aware, but "if you're aware" is admittedly rittle.
>
> Anyway, that's what we have.  Badly designed, but it seems to be
> workable.
>
> Is the bad enough to justify revising the interface?  I can't see how to
> do that compatibly.
>
> Is it bad enough to justify new interfaces for similar things to be
> dissimilar?
>

Maybe query-{sev,tdx,*}-capabilities should only be called when the
host is actually capable, thus throwing an Error is fine.

What about a new "query-confidential-guest-supports" command that
checks the host capability and returns ["sev", "tdx", "pef"...] then ?

Or maybe this should be provided at the MachineInfo level instead
(query-machines).

-- 
Marc-André Lureau

Re: [PATCH] Add query-tdx-capabilities

[Markus Armbruster]

Cc: machine core maintainers for an opinion on query-machines.

Marc-André Lureau <marcandre.lureau@gmail.com> writes:

> Hi
>
> On Fri, Jan 9, 2026 at 4:27 PM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>>
>> > On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
>> >> Daniel P. Berrangé <berrange@redhat.com> writes:
>> >>
>> >> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
>> >> >> Daniel P. Berrangé <berrange@redhat.com> writes:
>> >> >>
>> >> >> > 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>

[...]

>> >> >> Do management applications need to know more than "this combination of
>> >> >> host + KVM + QEMU can do SEV, yes / no?
>> >> >>
>> >> >> If yes, what do they need?  "No" split up into serval "No, because X"?
>> >> >
>> >> > When libvirt runs  query-sev-capabilities it does not care about the
>> >> > reason for it being unsupported.   Any "GenericError" is considered
>> >> > to mark the lack of host support, and no fine grained checks are
>> >> > performed on the err msg.
>> >> >
>> >> > If query-sev-capabilities succeeds (indicating SEV is supported), then
>> >> > all the returned info is exposed to mgmt apps in the libvirt domain
>> >> > capabilities XML document.
>> >>
>> >> So query-sev-capabilities is good enough as is?
>> >
>> > IIUC, essentially all QEMU errors that could possibly be seen with
>> > query-sev-capabilities are "GenericError" these days, except for
>> > the small possibility of "CommandNotFound".
>> >
>> > The two scenarios with lack of SEV support are covered by GenericError
>> > but I'm concerned that other things that should be considered fatal
>> > will also fall under GenericError.
>> >
>> > eg take a look at qmp_dispatch() and see countless places where we can
>> > return GenericError which ought to be treated as fatal by callers.
>> >
>> > IMHO  "SEV not supported" is not conceptually an error, it is an
>> > expected informational result of query-sev-capabilities, and thus
>> > shouldn't be using the QMP error object, it should have been a
>> > boolean result field.
>>
>> I agree that errors should be used only for "abnormal" outcomes, not for
>> the "no" answer to a simple question like "is SEV available, and if yes,
>> what are its capabilities?"
>>
>> I further agree that encoding "no" as GenericError runs the risk of
>> conflating "no" with other errors.  Since query-sev itself can fail just
>> one way, these can only come from the QMP core.  For the core's syntax
>> and type errors, the risk is only theoretical: just don't do that.
>> Errors triggered by state, like the one in qmp_command_available(), are
>> a bit more worrying.  I think they're easy enough to avoid if you're
>> aware, but "if you're aware" is admittedly rittle.
>>
>> Anyway, that's what we have.  Badly designed, but it seems to be
>> workable.
>>
>> Is the bad enough to justify revising the interface?  I can't see how to
>> do that compatibly.
>>
>> Is it bad enough to justify new interfaces for similar things to be
>> dissimilar?
>>
>
> Maybe query-{sev,tdx,*}-capabilities should only be called when the
> host is actually capable, thus throwing an Error is fine.
>
> What about a new "query-confidential-guest-supports" command that
> checks the host capability and returns ["sev", "tdx", "pef"...] then ?

Some similarity to query-accelerators.  Feels reasonable.

> Or maybe this should be provided at the MachineInfo level instead
> (query-machines).

Also reasonable, I think.  Machine core maintainers, got an opinion?

Re: [PATCH] Add query-tdx-capabilities

[Daniel P. Berrangé]

On Tue, Feb 03, 2026 at 08:03:17AM +0100, Markus Armbruster wrote:
> Cc: machine core maintainers for an opinion on query-machines.
> 
> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> 
> > Hi
> >
> > On Fri, Jan 9, 2026 at 4:27 PM Markus Armbruster <armbru@redhat.com> wrote:
> >>
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >>
> >> > On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
> >> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> >>
> >> >> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
> >> >> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> >> >>
> >> >> >> > 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>
> 
> [...]
> 
> >> >> >> Do management applications need to know more than "this combination of
> >> >> >> host + KVM + QEMU can do SEV, yes / no?
> >> >> >>
> >> >> >> If yes, what do they need?  "No" split up into serval "No, because X"?
> >> >> >
> >> >> > When libvirt runs  query-sev-capabilities it does not care about the
> >> >> > reason for it being unsupported.   Any "GenericError" is considered
> >> >> > to mark the lack of host support, and no fine grained checks are
> >> >> > performed on the err msg.
> >> >> >
> >> >> > If query-sev-capabilities succeeds (indicating SEV is supported), then
> >> >> > all the returned info is exposed to mgmt apps in the libvirt domain
> >> >> > capabilities XML document.
> >> >>
> >> >> So query-sev-capabilities is good enough as is?
> >> >
> >> > IIUC, essentially all QEMU errors that could possibly be seen with
> >> > query-sev-capabilities are "GenericError" these days, except for
> >> > the small possibility of "CommandNotFound".
> >> >
> >> > The two scenarios with lack of SEV support are covered by GenericError
> >> > but I'm concerned that other things that should be considered fatal
> >> > will also fall under GenericError.
> >> >
> >> > eg take a look at qmp_dispatch() and see countless places where we can
> >> > return GenericError which ought to be treated as fatal by callers.
> >> >
> >> > IMHO  "SEV not supported" is not conceptually an error, it is an
> >> > expected informational result of query-sev-capabilities, and thus
> >> > shouldn't be using the QMP error object, it should have been a
> >> > boolean result field.
> >>
> >> I agree that errors should be used only for "abnormal" outcomes, not for
> >> the "no" answer to a simple question like "is SEV available, and if yes,
> >> what are its capabilities?"
> >>
> >> I further agree that encoding "no" as GenericError runs the risk of
> >> conflating "no" with other errors.  Since query-sev itself can fail just
> >> one way, these can only come from the QMP core.  For the core's syntax
> >> and type errors, the risk is only theoretical: just don't do that.
> >> Errors triggered by state, like the one in qmp_command_available(), are
> >> a bit more worrying.  I think they're easy enough to avoid if you're
> >> aware, but "if you're aware" is admittedly rittle.
> >>
> >> Anyway, that's what we have.  Badly designed, but it seems to be
> >> workable.
> >>
> >> Is the bad enough to justify revising the interface?  I can't see how to
> >> do that compatibly.
> >>
> >> Is it bad enough to justify new interfaces for similar things to be
> >> dissimilar?
> >>
> >
> > Maybe query-{sev,tdx,*}-capabilities should only be called when the
> > host is actually capable, thus throwing an Error is fine.
> >
> > What about a new "query-confidential-guest-supports" command that
> > checks the host capability and returns ["sev", "tdx", "pef"...] then ?
> 
> Some similarity to query-accelerators.  Feels reasonable.

It feels like if we do that, then we would fold the -capbilities into
this command too:

{ 'enum': 'ConfidentialGuestType',
  'data': ['sev', 'sev-snp', 'tdx', .. ] }

{ 'union': 'ConfidentialGuestSupport',
  'base': { 'type': 'ConfidentialGuestType' },
  'discriminator': { 'type' },
  'data': { 'sev': 'SevCapabilities',
            'sev-snp': 'SevCapabilities' } }

{ 'command': 'query-confidential-guest-capabilities',
  'returns': 'ConfidentialGuestCapability' }



> > Or maybe this should be provided at the MachineInfo level instead
> > (query-machines).
> 
> Also reasonable, I think.  Machine core maintainers, got an opinion?

MachineInfo level seems interesting because of the 'confidential-guest-support'
property against the machine classes.

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

Re: [PATCH] Add query-tdx-capabilities

[Marc-André Lureau]

Hi

On Fri, Jan 9, 2026 at 4:26 PM Markus Armbruster <armbru@redhat.com> wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >>
> >> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote:
> >> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> >>
> >> >> > 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>
> >> >>
> >> >> [...]
> >> >>
> >> >> >> > 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
> >> >>
> >> >> The doc comments fail to explain this.  Needs fixing.
> >> >>
> >> >> Do management applications need to know more than "this combination of
> >> >> host + KVM + QEMU can do SEV, yes / no?
> >> >>
> >> >> If yes, what do they need?  "No" split up into serval "No, because X"?
> >> >
> >> > When libvirt runs  query-sev-capabilities it does not care about the
> >> > reason for it being unsupported.   Any "GenericError" is considered
> >> > to mark the lack of host support, and no fine grained checks are
> >> > performed on the err msg.
> >> >
> >> > If query-sev-capabilities succeeds (indicating SEV is supported), then
> >> > all the returned info is exposed to mgmt apps in the libvirt domain
> >> > capabilities XML document.
> >>
> >> So query-sev-capabilities is good enough as is?
> >
> > IIUC, essentially all QEMU errors that could possibly be seen with
> > query-sev-capabilities are "GenericError" these days, except for
> > the small possibility of "CommandNotFound".
> >
> > The two scenarios with lack of SEV support are covered by GenericError
> > but I'm concerned that other things that should be considered fatal
> > will also fall under GenericError.
> >
> > eg take a look at qmp_dispatch() and see countless places where we can
> > return GenericError which ought to be treated as fatal by callers.
> >
> > IMHO  "SEV not supported" is not conceptually an error, it is an
> > expected informational result of query-sev-capabilities, and thus
> > shouldn't be using the QMP error object, it should have been a
> > boolean result field.
>
> I agree that errors should be used only for "abnormal" outcomes, not for
> the "no" answer to a simple question like "is SEV available, and if yes,
> what are its capabilities?"
>
> I further agree that encoding "no" as GenericError runs the risk of
> conflating "no" with other errors.  Since query-sev itself can fail just
> one way, these can only come from the QMP core.  For the core's syntax
> and type errors, the risk is only theoretical: just don't do that.
> Errors triggered by state, like the one in qmp_command_available(), are
> a bit more worrying.  I think they're easy enough to avoid if you're
> aware, but "if you're aware" is admittedly rittle.
>
> Anyway, that's what we have.  Badly designed, but it seems to be
> workable.
>
> Is the bad enough to justify revising the interface?  I can't see how to
> do that compatibly.
>
> Is it bad enough to justify new interfaces for similar things to be
> dissimilar?
>

Markus, as our QAPI maintainer, you have more weight on the decision.
Should the query return an union ( "unavailable": "reason..",
"available":  TdxCapability ) or the proposed patch is okay?


> >> If yes, then the proposed query-tdx-capabilities should also be good
> >> enough, shouldn't it?
> >
> > With regards,
> > Daniel
>