[PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms

Ani Sinha posted 34 patches 1 month, 3 weeks ago
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, Eduardo Habkost <eduardo@habkost.net>, Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, "Philippe Mathieu-Daudé" <philmd@linaro.org>, Yanan Wang <wangyanan55@huawei.com>, Zhao Liu <zhao1.liu@intel.com>, "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>, Richard Henderson <richard.henderson@linaro.org>, "Michael S. Tsirkin" <mst@redhat.com>, Bernhard Beschow <shentey@gmail.com>, Alex Williamson <alex@shazbot.org>, "Cédric Le Goater" <clg@redhat.com>, Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>, Ani Sinha <anisinha@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>
There is a newer version of this series
[PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Ani Sinha 1 month, 3 weeks ago
Through the new 'confidential-guest-reset' property, control plane should be
able to detect if the hypervisor supports x86 confidential guest resets. Older
hypervisors that do not support resets will not have this property populated.

Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
---
 qapi/qom.json | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/qapi/qom.json b/qapi/qom.json
index 6f5c9de0f0..c653248f85 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -1009,13 +1009,19 @@
 #     designated guest firmware page for measured boot with -kernel
 #     (default: false) (since 6.2)
 #
+# Features:
+#
+# @confidential-guest-reset: If present, the hypervisor supports
+#     confidential guest resets (since 11.0).
+#
 # Since: 9.1
 ##
 { 'struct': 'SevCommonProperties',
   'data': { '*sev-device': 'str',
             '*cbitpos': 'uint32',
             'reduced-phys-bits': 'uint32',
-            '*kernel-hashes': 'bool' } }
+            '*kernel-hashes': 'bool' },
+  'features': ['confidential-guest-reset']}
 
 ##
 # @SevGuestProperties:
@@ -1136,6 +1142,11 @@
 #     it, the guest will not be able to get a TD quote for
 #     attestation.
 #
+# Features:
+#
+# @confidential-guest-reset: If present, the hypervisor supports
+#     confidential guest resets (since 11.0).
+#
 # Since: 10.1
 ##
 { 'struct': 'TdxGuestProperties',
@@ -1144,7 +1155,8 @@
             '*mrconfigid': 'str',
             '*mrowner': 'str',
             '*mrownerconfig': 'str',
-            '*quote-generation-socket': 'SocketAddress' } }
+            '*quote-generation-socket': 'SocketAddress' },
+   'features': ['confidential-guest-reset']}
 
 ##
 # @ThreadContextProperties:
-- 
2.42.0


Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Daniel P. Berrangé 1 month, 2 weeks ago
On Wed, Feb 18, 2026 at 05:12:26PM +0530, Ani Sinha wrote:
> Through the new 'confidential-guest-reset' property, control plane should be
> able to detect if the hypervisor supports x86 confidential guest resets. Older
> hypervisors that do not support resets will not have this property populated.
> 
> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> ---
>  qapi/qom.json | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|


Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Markus Armbruster 1 month, 3 weeks ago
Ani Sinha <anisinha@redhat.com> writes:

> Through the new 'confidential-guest-reset' property, control plane should be
> able to detect if the hypervisor supports x86 confidential guest resets. Older
> hypervisors that do not support resets will not have this property populated.

Double-checking...  This is an static ability of QEMU, and QEMU alone.
It does not depend on QEMU's run-time environment (host kernel, ...) or
the guest.  Correct?

> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Ani Sinha <anisinha@redhat.com>

Patch looks sane.
Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Ani Sinha 1 month, 3 weeks ago

> On 19 Feb 2026, at 2:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
> 
> Ani Sinha <anisinha@redhat.com> writes:
> 
>> Through the new 'confidential-guest-reset' property, control plane should be
>> able to detect if the hypervisor supports x86 confidential guest resets. Older
>> hypervisors that do not support resets will not have this property populated.
> 
> Double-checking...  This is an static ability of QEMU, and QEMU alone.
> It does not depend on QEMU's run-time environment (host kernel, ...) or
> the guest.  Correct?

The run time environment is the same as what is needed to spawn confidential guests. That is, the host should support confidential technology. The host kernel/distribution should support confidential technologies. Plus the guest should support confidential technologies. There is nothing additionally needed to support resets. There are no additional dependencies with host kernel/environment and/or the guest etc to support reset.

> 
>> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> 
> Patch looks sane.
> 
Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Markus Armbruster 1 month, 3 weeks ago
Ani Sinha <anisinha@redhat.com> writes:

>> On 19 Feb 2026, at 2:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> 
>> Ani Sinha <anisinha@redhat.com> writes:
>> 
>>> Through the new 'confidential-guest-reset' property, control plane should be
>>> able to detect if the hypervisor supports x86 confidential guest resets. Older
>>> hypervisors that do not support resets will not have this property populated.
>> 
>> Double-checking...  This is an static ability of QEMU, and QEMU alone.
>> It does not depend on QEMU's run-time environment (host kernel, ...) or
>> the guest.  Correct?
>
> The run time environment is the same as what is needed to spawn confidential guests. That is, the host should support confidential technology. The host kernel/distribution should support confidential technologies. Plus the guest should support confidential technologies. There is nothing additionally needed to support resets. There are no additional dependencies with host kernel/environment and/or the guest etc to support reset.

So...  if a QEMU with this feature succeeded at starting a confidential
guest, then x86 confidential guest reset is definitely supported for
that guest.  Correct?

>> 
>>> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>> 
>> Patch looks sane.
>> 
Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Ani Sinha 1 month, 3 weeks ago

> On 19 Feb 2026, at 2:57 PM, Markus Armbruster <armbru@redhat.com> wrote:
> 
> Ani Sinha <anisinha@redhat.com> writes:
> 
>>> On 19 Feb 2026, at 2:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>> 
>>> Ani Sinha <anisinha@redhat.com> writes:
>>> 
>>>> Through the new 'confidential-guest-reset' property, control plane should be
>>>> able to detect if the hypervisor supports x86 confidential guest resets. Older
>>>> hypervisors that do not support resets will not have this property populated.
>>> 
>>> Double-checking...  This is an static ability of QEMU, and QEMU alone.
>>> It does not depend on QEMU's run-time environment (host kernel, ...) or
>>> the guest.  Correct?
>> 
>> The run time environment is the same as what is needed to spawn confidential guests. That is, the host should support confidential technology. The host kernel/distribution should support confidential technologies. Plus the guest should support confidential technologies. There is nothing additionally needed to support resets. There are no additional dependencies with host kernel/environment and/or the guest etc to support reset.
> 
> So...  if a QEMU with this feature succeeded at starting a confidential
> guest, then x86 confidential guest reset is definitely supported for
> that guest.  Correct?

Yes :-) 
Re: [PATCH v5 33/34] qom: add 'confidential-guest-reset' property for x86 confidential vms
Posted by Markus Armbruster 1 month, 3 weeks ago
Ani Sinha <anisinha@redhat.com> writes:

>> On 19 Feb 2026, at 2:57 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> 
>> Ani Sinha <anisinha@redhat.com> writes:
>> 
>>>> On 19 Feb 2026, at 2:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
>>>> 
>>>> Ani Sinha <anisinha@redhat.com> writes:
>>>> 
>>>>> Through the new 'confidential-guest-reset' property, control plane should be
>>>>> able to detect if the hypervisor supports x86 confidential guest resets. Older
>>>>> hypervisors that do not support resets will not have this property populated.
>>>> 
>>>> Double-checking...  This is an static ability of QEMU, and QEMU alone.
>>>> It does not depend on QEMU's run-time environment (host kernel, ...) or
>>>> the guest.  Correct?
>>> 
>>> The run time environment is the same as what is needed to spawn confidential guests. That is, the host should support confidential technology. The host kernel/distribution should support confidential technologies. Plus the guest should support confidential technologies. There is nothing additionally needed to support resets. There are no additional dependencies with host kernel/environment and/or the guest etc to support reset.
>> 
>> So...  if a QEMU with this feature succeeded at starting a confidential
>> guest, then x86 confidential guest reset is definitely supported for
>> that guest.  Correct?
>
> Yes :-) 

Thank you!

Reviewed-by: Markus Armbruster <armbru@redhat.com>