[dev][nova] Intel TDX support
Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton
Dear Anton, during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV. Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable. [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code [3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22 Kind regards, Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support
Best Regards, Anton
-- Markus Hentsch DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 00 markus.hentsch@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann
A few more points to add... * You probably need https://blueprints.launchpad.net/nova/+spec/libvirt-firmware-auto-selection to be implemented first for your work, so that an appropriate firmware with TDX support is selected during instance creation. * One mechanism we still have to implement for AMD SEV-SNP is an interface to allow users to pass down some additional fields such as hostData from api to actual guest domain. We don't really want that interface to be quite specific to a single technology and want it to be generic enough to cover multiple ones. However honestly I'm struggling to understand the requirements in TDX long after I played with it, and I'm unsure how we can make that interface "generic". If you can give some details about the required parameters for confidential computing use case with TDX that may be helpful to enhance that discussion. On 1/20/26 1:58 AM, Markus Hentsch wrote:
Dear Anton,
during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV.
Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable.
[1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687
[2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
[3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22
Kind regards,
Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support
Best Regards, Anton
On 1/19/26 18:56, Takashi Kajinami wrote:
A few more points to add...
* You probably need https://blueprints.launchpad.net/nova/+spec/libvirt- firmware-auto-selection to be implemented first for your work, so that an appropriate firmware with TDX support is selected during instance creation.
Yes that is definitely needed! Since it is planned for 2026.1 release could I effectively treat it as implemented in the TDX spec? Happy to help with reviews here to make sure it works as expected for TDX.
* One mechanism we still have to implement for AMD SEV-SNP is an interface to allow users to pass down some additional fields such as hostData from api to actual guest domain. We don't really want that interface to be quite specific to a single technology and want it to be generic enough to cover multiple ones. However honestly I'm struggling to understand the requirements in TDX long after I played with it, and I'm unsure how we can make that interface "generic". If you can give some details about the required parameters for confidential computing use case with TDX that may be helpful to enhance that discussion.
Is the aim to provide a generic interface for all additional fields or just the hostData field? The latter is very doable, but all fields will be harder to make generic. From the TDX point of view there are 5 fields of interest, see libvirt spec [1]. mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData in SNP, but are slightly larger (48-bytes each) and specific. Due to the size difference a common approach is to only look at the lower 32 bytes, thus unifying it with hostData. [4] contains some descriptions of the specific use cases of these 3 fields. It can be argued that both mrConfigId and mrOwnerConfig fit semantically. Azure [2] and Confidential Containers [3] do for example use the SHA256 hash digest for their init/host data interface and use mrConfigId in the TDX case. My suggestion is to do the same to keep it consistent across implementations. Remaining fields: The policy field in TDX is pretty much the as the one in SNP but the bits have different meaning. The quoteGenerationService is unique to TDX and a requirement for attestation. [1] https://libvirt.org/formatdomain.html#launch-security [2] https://learn.microsoft.com/en-us/rest/api/attestation/attestation/attest-td... [3] https://github.com/confidential-containers/confidential-containers/issues/17... [4] https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@inte...
On 1/20/26 1:58 AM, Markus Hentsch wrote:
Dear Anton,
during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV.
Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable. Great to see that TDX is already planned for. Glad to join in on reviews until TDX specifics are needed.
[1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687
[2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
[3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22
Kind regards,
Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- support
Best Regards, Anton
Hi Anton and Takashi, I'm very happy to see this topic gaining traction within the community. I wanted to add that my employer is highly interested in both AMD SEV-SNP and Intel TDX support, and seeing these technologies integrated is a significant priority for us. In light of the 2026.2 (Hibiscus) target, I wanted to ask about development capacity. Takashi, do you anticipate having the bandwidth to drive the AMD SEV-SNP support during the Hibiscus cycle? Anton, I have the same question for you regarding the TDX implementation. Finally, would you both be able to introduce this topic for discussion at the next PTG? Having a draft specification ready to review during the PTG would be extremely valuable. Best Regards, Rene On Wed, Jan 21, 2026 at 5:05 PM Anton Iacobaeus < anton.iacobaeus@canarybit.eu> wrote:
On 1/19/26 18:56, Takashi Kajinami wrote:
A few more points to add...
* You probably need https://blueprints.launchpad.net/nova/+spec/libvirt- firmware-auto-selection to be implemented first for your work, so that an appropriate firmware with TDX support is selected during instance creation.
Yes that is definitely needed! Since it is planned for 2026.1 release could I effectively treat it as implemented in the TDX spec? Happy to help with reviews here to make sure it works as expected for TDX.
* One mechanism we still have to implement for AMD SEV-SNP is an interface to allow users to pass down some additional fields such as hostData from api to actual guest domain. We don't really want that interface to be quite specific to a single technology and want it to be generic enough to cover multiple ones. However honestly I'm struggling to understand the requirements in TDX long after I played with it, and I'm unsure how we can make that interface "generic". If you can give some details about the required parameters for confidential computing use case with TDX that may be helpful to enhance that discussion.
Is the aim to provide a generic interface for all additional fields or just the hostData field? The latter is very doable, but all fields will be harder to make generic.
From the TDX point of view there are 5 fields of interest, see libvirt spec [1].
mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData in SNP, but are slightly larger (48-bytes each) and specific. Due to the size difference a common approach is to only look at the lower 32 bytes, thus unifying it with hostData. [4] contains some descriptions of the specific use cases of these 3 fields. It can be argued that both mrConfigId and mrOwnerConfig fit semantically.
Azure [2] and Confidential Containers [3] do for example use the SHA256 hash digest for their init/host data interface and use mrConfigId in the TDX case. My suggestion is to do the same to keep it consistent across implementations.
Remaining fields: The policy field in TDX is pretty much the as the one in SNP but the bits have different meaning. The quoteGenerationService is unique to TDX and a requirement for attestation.
[1] https://libvirt.org/formatdomain.html#launch-security
[2]
https://learn.microsoft.com/en-us/rest/api/attestation/attestation/attest-td...
[3]
https://github.com/confidential-containers/confidential-containers/issues/17...
[4]
https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@inte...
On 1/20/26 1:58 AM, Markus Hentsch wrote:
Dear Anton,
during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV.
Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable. Great to see that TDX is already planned for. Glad to join in on reviews until TDX specifics are needed.
[1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687
[2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
[3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22
Kind regards,
Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- support
Best Regards, Anton
Hi Rene, I will have the bandwidth to develop the TDX implementation during Hibiscus. There is already a proposed draft spec for TDX [1]. It depends on the generalize-sev-code blueprint [2] which is still in review, so some details might change. Any early feedback/review on the draft is greatly appreciated! Happy to introduce the topic and spec in the upcoming PTG. Best Regards, Anton [1] https://review.opendev.org/c/openstack/nova-specs/+/979608 [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code On 3/18/26 14:39, Rene Ribaud wrote:
Hi Anton and Takashi,
I'm very happy to see this topic gaining traction within the community. I wanted to add that my employer is highly interested in both AMD SEV- SNP and Intel TDX support, and seeing these technologies integrated is a significant priority for us.
In light of the 2026.2 (Hibiscus) target, I wanted to ask about development capacity. Takashi, do you anticipate having the bandwidth to drive the AMD SEV-SNP support during the Hibiscus cycle? Anton, I have the same question for you regarding the TDX implementation.
Finally, would you both be able to introduce this topic for discussion at the next PTG? Having a draft specification ready to review during the PTG would be extremely valuable.
Best Regards,
Rene
On Wed, Jan 21, 2026 at 5:05 PM Anton Iacobaeus <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>> wrote:
On 1/19/26 18:56, Takashi Kajinami wrote: > A few more points to add... > > * You probably need > https://blueprints.launchpad.net/nova/+spec/libvirt- <https:// blueprints.launchpad.net/nova/+spec/libvirt-> > firmware-auto-selection to be implemented first for your work, so that > an appropriate firmware with TDX support is selected during instance > creation. > Yes that is definitely needed! Since it is planned for 2026.1 release could I effectively treat it as implemented in the TDX spec? Happy to help with reviews here to make sure it works as expected for TDX.
> * One mechanism we still have to implement for AMD SEV-SNP is an > interface to allow users to pass down some additional fields such as > hostData from api to actual guest domain. We don't really want that > interface to be quite specific to a single technology and want it to > be generic enough to cover multiple ones. However honestly I'm > struggling to understand the requirements in TDX long after I played > with it, and I'm unsure how we can make that interface "generic". If > you can give some details about the required parameters for > confidential computing use case with TDX that may be helpful to > enhance that discussion. >
Is the aim to provide a generic interface for all additional fields or just the hostData field? The latter is very doable, but all fields will be harder to make generic.
From the TDX point of view there are 5 fields of interest, see libvirt spec [1].
mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData in SNP, but are slightly larger (48-bytes each) and specific. Due to the size difference a common approach is to only look at the lower 32 bytes, thus unifying it with hostData. [4] contains some descriptions of the specific use cases of these 3 fields. It can be argued that both mrConfigId and mrOwnerConfig fit semantically.
Azure [2] and Confidential Containers [3] do for example use the SHA256 hash digest for their init/host data interface and use mrConfigId in the TDX case. My suggestion is to do the same to keep it consistent across implementations.
Remaining fields: The policy field in TDX is pretty much the as the one in SNP but the bits have different meaning. The quoteGenerationService is unique to TDX and a requirement for attestation.
[1] https://libvirt.org/formatdomain.html#launch-security <https:// libvirt.org/formatdomain.html#launch-security>
[2] https://learn.microsoft.com/en-us/rest/api/attestation/attestation/ attest-tdx-vm?view=rest- attestation-2025-06-01&tabs=HTTP#inittimedata <https:// learn.microsoft.com/en-us/rest/api/attestation/attestation/attest- tdx-vm?view=rest-attestation-2025-06-01&tabs=HTTP#inittimedata>
[3] https://github.com/confidential-containers/confidential-containers/ issues/171#issue-1985098907 <https://github.com/confidential- containers/confidential-containers/issues/171#issue-1985098907>
[4] https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef- ab08-4813f4e0ff92@intel.com/ <https://lore.kernel.org/qemu- devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/>
> On 1/20/26 1:58 AM, Markus Hentsch wrote: >> Dear Anton, >> >> during the last PTG (project team gathering) there was some >> discussion about future extensions to the confidential computing >> support in Nova, not limited to just SEV-SNP [1]. As a result, there >> is currently ongoing work on extending the architecture to prepare >> for supporting multiple vendor's technologies [2][3], for example >> Intel TDX and ARM CCA, in addition to AMD SEV. >> >> Maybe you could help with reviewing the patchsets to ensure that the >> architecture changes will work for TDX and/or join in there at some >> point and contribute to the TDX-specific side of things directly. I >> think that either would be very valuable. Great to see that TDX is already planned for. Glad to join in on reviews until TDX specifics are needed.
>> >> >> [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687> >> >> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev- code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code> >> >> [3] https://review.opendev.org/q/topic:%22bp/generalize-sev- code%22 <https://review.opendev.org/q/topic:%22bp/generalize-sev- code%22> >> >> >> Kind regards, >> >> Markus >> >> >>> Hi, >>> >>> I work with confidential computing and has previously contributed to >>> Proxmox [1] to enable support for Intel TDX. I am looking to do the >>> same for Openstack Nova. >>> >>> I have proposed a blueprint [2] and am drafting a spec with target >>> for 2026.2 release. >>> >>> From what I gather, support for AMD SEV and SEV-ES is already >>> implemented in Nova, while SEV-SNP support is ongoing. TDX shares >>> some commonalities with SEV-SNP, and I believe that the work on both >>> can be conducted in tandem. I also have experience with SEV-SNP and >>> am happy to contribute if needed. >>> >>> Early feedback or any concerns and guidance are very welcome! >>> >>> [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1> [2] >>> https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-> >>> support >>> >>> Best Regards, Anton >> >
Hi Anton and Takashi, Anton, that's great news about your bandwidth for the TDX implementation during the Hibiscus cycle, and I appreciate you agreeing to introduce the topic at the next PTG. I'll make sure to add the TDX discussion point to the agenda. Takashi, I wanted to follow up and ask whether you also anticipate having the necessary bandwidth to support AMD SEV-SNP during this cycle. I apologize for being a bit persistent on this, but these technologies are a significant priority for my employer. If you foresee any capacity issues, please let me know, so I can explore an alternative plan to keep the work on track. Best Regards, Rene On Mon, Mar 23, 2026 at 11:38 AM Anton Iacobaeus < anton.iacobaeus@canarybit.eu> wrote:
Hi Rene,
I will have the bandwidth to develop the TDX implementation during Hibiscus.
There is already a proposed draft spec for TDX [1]. It depends on the generalize-sev-code blueprint [2] which is still in review, so some details might change. Any early feedback/review on the draft is greatly appreciated!
Happy to introduce the topic and spec in the upcoming PTG.
Best Regards, Anton
[1] https://review.opendev.org/c/openstack/nova-specs/+/979608 [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
On 3/18/26 14:39, Rene Ribaud wrote:
Hi Anton and Takashi,
I'm very happy to see this topic gaining traction within the community. I wanted to add that my employer is highly interested in both AMD SEV- SNP and Intel TDX support, and seeing these technologies integrated is a significant priority for us.
In light of the 2026.2 (Hibiscus) target, I wanted to ask about development capacity. Takashi, do you anticipate having the bandwidth to drive the AMD SEV-SNP support during the Hibiscus cycle? Anton, I have the same question for you regarding the TDX implementation.
Finally, would you both be able to introduce this topic for discussion at the next PTG? Having a draft specification ready to review during the PTG would be extremely valuable.
Best Regards,
Rene
On Wed, Jan 21, 2026 at 5:05 PM Anton Iacobaeus <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>> wrote:
On 1/19/26 18:56, Takashi Kajinami wrote: > A few more points to add... > > * You probably need > https://blueprints.launchpad.net/nova/+spec/libvirt- <https:// blueprints.launchpad.net/nova/+spec/libvirt-> > firmware-auto-selection to be implemented first for your work, so that > an appropriate firmware with TDX support is selected during instance > creation. > Yes that is definitely needed! Since it is planned for 2026.1 release could I effectively treat it as implemented in the TDX spec? Happy to help with reviews here to make sure it works as expected for TDX.
> * One mechanism we still have to implement for AMD SEV-SNP is an > interface to allow users to pass down some additional fields such as > hostData from api to actual guest domain. We don't really want that > interface to be quite specific to a single technology and want it to > be generic enough to cover multiple ones. However honestly I'm > struggling to understand the requirements in TDX long after I played > with it, and I'm unsure how we can make that interface "generic". If > you can give some details about the required parameters for > confidential computing use case with TDX that may be helpful to > enhance that discussion. >
Is the aim to provide a generic interface for all additional fields or just the hostData field? The latter is very doable, but all fields will be harder to make generic.
From the TDX point of view there are 5 fields of interest, see libvirt spec [1].
mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData in SNP, but are slightly larger (48-bytes each) and specific. Due to the size difference a common approach is to only look at the lower 32 bytes, thus unifying it with hostData. [4] contains some descriptions of the specific use cases of these 3 fields. It can be argued that both mrConfigId and mrOwnerConfig fit semantically.
Azure [2] and Confidential Containers [3] do for example use the SHA256 hash digest for their init/host data interface and use mrConfigId in the TDX case. My suggestion is to do the same to keep it consistent across implementations.
Remaining fields: The policy field in TDX is pretty much the as the one in SNP but the bits have different meaning. The quoteGenerationService is unique to TDX and a requirement for attestation.
[1] https://libvirt.org/formatdomain.html#launch-security <https:// libvirt.org/formatdomain.html#launch-security>
[2] https://learn.microsoft.com/en-us/rest/api/attestation/attestation/ attest-tdx-vm?view=rest- attestation-2025-06-01&tabs=HTTP#inittimedata <https:// learn.microsoft.com/en-us/rest/api/attestation/attestation/attest- tdx-vm?view=rest-attestation-2025-06-01&tabs=HTTP#inittimedata>
[3] https://github.com/confidential-containers/confidential-containers/ issues/171#issue-1985098907 <https://github.com/confidential- containers/confidential-containers/issues/171#issue-1985098907>
[4] https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef- ab08-4813f4e0ff92@intel.com/ <https://lore.kernel.org/qemu- devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/>
> On 1/20/26 1:58 AM, Markus Hentsch wrote: >> Dear Anton, >> >> during the last PTG (project team gathering) there was some >> discussion about future extensions to the confidential computing >> support in Nova, not limited to just SEV-SNP [1]. As a result, there >> is currently ongoing work on extending the architecture to prepare >> for supporting multiple vendor's technologies [2][3], for example >> Intel TDX and ARM CCA, in addition to AMD SEV. >> >> Maybe you could help with reviewing the patchsets to ensure that the >> architecture changes will work for TDX and/or join in there at some >> point and contribute to the TDX-specific side of things directly. I >> think that either would be very valuable. Great to see that TDX is already planned for. Glad to join in on reviews until TDX specifics are needed.
>> >> >> [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687> >> >> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev- code < https://blueprints.launchpad.net/nova/+spec/generalize-sev-code> >> >> [3] https://review.opendev.org/q/topic:%22bp/generalize-sev- code%22 <https://review.opendev.org/q/topic:%22bp/generalize-sev- code%22> >> >> >> Kind regards, >> >> Markus >> >> >>> Hi, >>> >>> I work with confidential computing and has previously contributed to >>> Proxmox [1] to enable support for Intel TDX. I am looking to do the >>> same for Openstack Nova. >>> >>> I have proposed a blueprint [2] and am drafting a spec with target >>> for 2026.2 release. >>> >>> From what I gather, support for AMD SEV and SEV-ES is already >>> implemented in Nova, while SEV-SNP support is ongoing. TDX shares >>> some commonalities with SEV-SNP, and I believe that the work on both >>> can be conducted in tandem. I also have experience with SEV-SNP and >>> am happy to contribute if needed. >>> >>> Early feedback or any concerns and guidance are very welcome! >>> >>> [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1> [2] >>> https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-> >>> support >>> >>> Best Regards, Anton >> >
Hi Rene, Sorry for my late reply. I'm personally interested in working on adding SEV-SNP support, because I've working in this area for some time and even completed per-requisite work in nova. However I've been packed a few other priorities from my downstream recently and likely get some challenges about my bandwidth, mainly about testing with actual hardware. So if anyone else is willing to work on it and have actual resources they can spend on it, I'm happy to have the topic taken over by them. I can still help with the development mainly with reviews, if that helps (I can also provide the draft spec to describe the plan I had earlier, early next week). Thank you, Takashi On 3/30/26 6:24 PM, Rene Ribaud wrote:
Hi Anton and Takashi,
Anton, that's great news about your bandwidth for the TDX implementation during the Hibiscus cycle, and I appreciate you agreeing to introduce the topic at the next PTG. I'll make sure to add the TDX discussion point to the agenda.
Takashi, I wanted to follow up and ask whether you also anticipate having the necessary bandwidth to support AMD SEV-SNP during this cycle. I apologize for being a bit persistent on this, but these technologies are a significant priority for my employer. If you foresee any capacity issues, please let me know, so I can explore an alternative plan to keep the work on track.
Best Regards,
Rene
On Mon, Mar 23, 2026 at 11:38 AM Anton Iacobaeus <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>> wrote:
Hi Rene,
I will have the bandwidth to develop the TDX implementation during Hibiscus.
There is already a proposed draft spec for TDX [1]. It depends on the generalize-sev-code blueprint [2] which is still in review, so some details might change. Any early feedback/review on the draft is greatly appreciated!
Happy to introduce the topic and spec in the upcoming PTG.
Best Regards, Anton
[1] https://review.opendev.org/c/openstack/nova-specs/+/979608 <https://review.opendev.org/c/openstack/nova-specs/+/979608> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code>
On 3/18/26 14:39, Rene Ribaud wrote: > Hi Anton and Takashi, > > I'm very happy to see this topic gaining traction within the community. > I wanted to add that my employer is highly interested in both AMD SEV- > SNP and Intel TDX support, and seeing these technologies integrated is a > significant priority for us. > > In light of the 2026.2 (Hibiscus) target, I wanted to ask about > development capacity. Takashi, do you anticipate having the bandwidth to > drive the AMD SEV-SNP support during the Hibiscus cycle? Anton, I have > the same question for you regarding the TDX implementation. > > Finally, would you both be able to introduce this topic for discussion > at the next PTG? Having a draft specification ready to review during the > PTG would be extremely valuable. > > Best Regards, > > Rene > > On Wed, Jan 21, 2026 at 5:05 PM Anton Iacobaeus > <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu> <mailto:anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>>> wrote: > > On 1/19/26 18:56, Takashi Kajinami wrote: > > A few more points to add... > > > > * You probably need > > https://blueprints.launchpad.net/nova/+spec/libvirt- <https://blueprints.launchpad.net/nova/+spec/libvirt-> <https:// > blueprints.launchpad.net/nova/+spec/libvirt- <http://blueprints.launchpad.net/nova/+spec/libvirt->> > > firmware-auto-selection to be implemented first for your work, so > that > > an appropriate firmware with TDX support is selected during instance > > creation. > > > Yes that is definitely needed! Since it is planned for 2026.1 release > could I effectively treat it as implemented in the TDX spec? Happy to > help with reviews here to make sure it works as expected for TDX. > > > * One mechanism we still have to implement for AMD SEV-SNP is an > > interface to allow users to pass down some additional fields such as > > hostData from api to actual guest domain. We don't really want that > > interface to be quite specific to a single technology and want it to > > be generic enough to cover multiple ones. However honestly I'm > > struggling to understand the requirements in TDX long after I played > > with it, and I'm unsure how we can make that interface "generic". If > > you can give some details about the required parameters for > > confidential computing use case with TDX that may be helpful to > > enhance that discussion. > > > > Is the aim to provide a generic interface for all additional fields or > just the hostData field? The latter is very doable, but all fields will > be harder to make generic. > > From the TDX point of view there are 5 fields of interest, see libvirt > spec [1]. > > mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData > in SNP, but are slightly larger (48-bytes each) and specific. Due to the > size difference a common approach is to only look at the lower 32 bytes, > thus unifying it with hostData. [4] contains some descriptions of the > specific use cases of these 3 fields. It can be argued that both > mrConfigId and mrOwnerConfig fit semantically. > > Azure [2] and Confidential Containers [3] do for example use the SHA256 > hash digest for their init/host data interface and use mrConfigId in the > TDX case. My suggestion is to do the same to keep it consistent across > implementations. > > Remaining fields: > The policy field in TDX is pretty much the as the one in SNP but the > bits have different meaning. The quoteGenerationService is unique to TDX > and a requirement for attestation. > > [1] https://libvirt.org/formatdomain.html#launch-security <https://libvirt.org/formatdomain.html#launch-security> <https:// > libvirt.org/formatdomain.html#launch-security <http://libvirt.org/formatdomain.html#launch-security>> > > [2] > https://learn.microsoft.com/en-us/rest/api/attestation/attestation/ <https://learn.microsoft.com/en-us/rest/api/attestation/attestation/> > attest-tdx-vm?view=rest- > attestation-2025-06-01&tabs=HTTP#inittimedata <https:// > learn.microsoft.com/en-us/rest/api/attestation/attestation/attest- <http://learn.microsoft.com/en-us/rest/api/attestation/attestation/attest-> > tdx-vm?view=rest-attestation-2025-06-01&tabs=HTTP#inittimedata> > > [3] > https://github.com/confidential-containers/confidential-containers/ <https://github.com/confidential-containers/confidential-containers/> > issues/171#issue-1985098907 <https://github.com/confidential- <https://github.com/confidential-> > containers/confidential-containers/issues/171#issue-1985098907> > > [4] > https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef- <https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef-> > ab08-4813f4e0ff92@intel.com/ <http://ab08-4813f4e0ff92@intel.com/> <https://lore.kernel.org/qemu- <https://lore.kernel.org/qemu-> > devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/ <http://31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/>> > > > On 1/20/26 1:58 AM, Markus Hentsch wrote: > >> Dear Anton, > >> > >> during the last PTG (project team gathering) there was some > >> discussion about future extensions to the confidential computing > >> support in Nova, not limited to just SEV-SNP [1]. As a result, there > >> is currently ongoing work on extending the architecture to prepare > >> for supporting multiple vendor's technologies [2][3], for example > >> Intel TDX and ARM CCA, in addition to AMD SEV. > >> > >> Maybe you could help with reviewing the patchsets to ensure that the > >> architecture changes will work for TDX and/or join in there at some > >> point and contribute to the TDX-specific side of things directly. I > >> think that either would be very valuable. > Great to see that TDX is already planned for. Glad to join in on reviews > until TDX specifics are needed. > > >> > >> > >> [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687> > <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687>> > >> > >> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev- <https://blueprints.launchpad.net/nova/+spec/generalize-sev-> > code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code>> > >> > >> [3] https://review.opendev.org/q/topic:%22bp/generalize-sev- <https://review.opendev.org/q/topic:%22bp/generalize-sev-> > code%22 <https://review.opendev.org/q/topic:%22bp/generalize-sev- <https://review.opendev.org/q/topic:%22bp/generalize-sev-> > code%22> > >> > >> > >> Kind regards, > >> > >> Markus > >> > >> > >>> Hi, > >>> > >>> I work with confidential computing and has previously > contributed to > >>> Proxmox [1] to enable support for Intel TDX. I am looking to do the > >>> same for Openstack Nova. > >>> > >>> I have proposed a blueprint [2] and am drafting a spec with target > >>> for 2026.2 release. > >>> > >>> From what I gather, support for AMD SEV and SEV-ES is already > >>> implemented in Nova, while SEV-SNP support is ongoing. TDX shares > >>> some commonalities with SEV-SNP, and I believe that the work on > both > >>> can be conducted in tandem. I also have experience with SEV-SNP and > >>> am happy to contribute if needed. > >>> > >>> Early feedback or any concerns and guidance are very welcome! > >>> > >>> [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1> > <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1>> [2] > >>> https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-> > <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt->> > >>> support > >>> > >>> Best Regards, Anton > >> > > >
Dear Takashi, we currently have a working downstream implementation of SEV-SNP for OpenStack in Yaook [1] which we were already able to verify with initial use cases in our infrastructure. So far, the implementation consists mainly of patches for the existing SEV-centric CC architecture of Nova from before the generalization [2] started taking place. We did this downstream for the time being because of a direct customer demand aiming at an existing OpenStack release and the fact that the generalization had already been discussed at a PTG and drafts already put for review, so we had to come up with an interim solution with the strong intent on porting it to the generalized structure once available. So once the base architectural changes of the generalization are finalized, we do plan on rebasing our implementation onto the new architecture and would be glad to contribute this to OpenStack officially. [1] https://docs.yaook.cloud/user/guides/amd-sev/index.html [2] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22 Kind regards, Markus Hentsch
Hi Rene,
Sorry for my late reply.
I'm personally interested in working on adding SEV-SNP support, because I've working in this area for some time and even completed per-requisite work in nova. However I've been packed a few other priorities from my downstream recently and likely get some challenges about my bandwidth, mainly about testing with actual hardware.
So if anyone else is willing to work on it and have actual resources they can spend on it, I'm happy to have the topic taken over by them. I can still help with the development mainly with reviews, if that helps (I can also provide the draft spec to describe the plan I had earlier, early next week).
Thank you, Takashi
On 3/30/26 6:24 PM, Rene Ribaud wrote:
Hi Anton and Takashi,
Anton, that's great news about your bandwidth for the TDX implementation during the Hibiscus cycle, and I appreciate you agreeing to introduce the topic at the next PTG. I'll make sure to add the TDX discussion point to the agenda.
Takashi, I wanted to follow up and ask whether you also anticipate having the necessary bandwidth to support AMD SEV-SNP during this cycle. I apologize for being a bit persistent on this, but these technologies are a significant priority for my employer. If you foresee any capacity issues, please let me know, so I can explore an alternative plan to keep the work on track.
Best Regards,
Rene
On Mon, Mar 23, 2026 at 11:38 AM Anton Iacobaeus <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>> wrote:
Hi Rene,
I will have the bandwidth to develop the TDX implementation during Hibiscus.
There is already a proposed draft spec for TDX [1]. It depends on the generalize-sev-code blueprint [2] which is still in review, so some details might change. Any early feedback/review on the draft is greatly appreciated!
Happy to introduce the topic and spec in the upcoming PTG.
Best Regards, Anton
[1] https://review.opendev.org/c/openstack/nova-specs/+/979608 <https://review.opendev.org/c/openstack/nova-specs/+/979608> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code>
On 3/18/26 14:39, Rene Ribaud wrote: > Hi Anton and Takashi, > > I'm very happy to see this topic gaining traction within the community. > I wanted to add that my employer is highly interested in both AMD SEV- > SNP and Intel TDX support, and seeing these technologies integrated is a > significant priority for us. > > In light of the 2026.2 (Hibiscus) target, I wanted to ask about > development capacity. Takashi, do you anticipate having the bandwidth to > drive the AMD SEV-SNP support during the Hibiscus cycle? Anton, I have > the same question for you regarding the TDX implementation. > > Finally, would you both be able to introduce this topic for discussion > at the next PTG? Having a draft specification ready to review during the > PTG would be extremely valuable. > > Best Regards, > > Rene > > On Wed, Jan 21, 2026 at 5:05 PM Anton Iacobaeus > <anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu> <mailto:anton.iacobaeus@canarybit.eu <mailto:anton.iacobaeus@canarybit.eu>>> wrote: > > On 1/19/26 18:56, Takashi Kajinami wrote: > > A few more points to add... > > > > * You probably need > > https://blueprints.launchpad.net/nova/+spec/libvirt- <https://blueprints.launchpad.net/nova/+spec/libvirt-> <https:// > blueprints.launchpad.net/nova/+spec/libvirt- <http://blueprints.launchpad.net/nova/+spec/libvirt->> > > firmware-auto-selection to be implemented first for your work, so > that > > an appropriate firmware with TDX support is selected during instance > > creation. > > > Yes that is definitely needed! Since it is planned for 2026.1 release > could I effectively treat it as implemented in the TDX spec? Happy to > help with reviews here to make sure it works as expected for TDX. > > > * One mechanism we still have to implement for AMD SEV-SNP is an > > interface to allow users to pass down some additional fields such as > > hostData from api to actual guest domain. We don't really want that > > interface to be quite specific to a single technology and want it to > > be generic enough to cover multiple ones. However honestly I'm > > struggling to understand the requirements in TDX long after I played > > with it, and I'm unsure how we can make that interface "generic". If > > you can give some details about the required parameters for > > confidential computing use case with TDX that may be helpful to > > enhance that discussion. > > > > Is the aim to provide a generic interface for all additional fields or > just the hostData field? The latter is very doable, but all fields will > be harder to make generic. > > From the TDX point of view there are 5 fields of interest, see libvirt > spec [1]. > > mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData > in SNP, but are slightly larger (48-bytes each) and specific. Due to the > size difference a common approach is to only look at the lower 32 bytes, > thus unifying it with hostData. [4] contains some descriptions of the > specific use cases of these 3 fields. It can be argued that both > mrConfigId and mrOwnerConfig fit semantically. > > Azure [2] and Confidential Containers [3] do for example use the SHA256 > hash digest for their init/host data interface and use mrConfigId in the > TDX case. My suggestion is to do the same to keep it consistent across > implementations. > > Remaining fields: > The policy field in TDX is pretty much the as the one in SNP but the > bits have different meaning. The quoteGenerationService is unique to TDX > and a requirement for attestation. > > [1] https://libvirt.org/formatdomain.html#launch-security <https://libvirt.org/formatdomain.html#launch-security> <https:// > libvirt.org/formatdomain.html#launch-security <http://libvirt.org/formatdomain.html#launch-security>> > > [2] > https://learn.microsoft.com/en-us/rest/api/attestation/attestation/ <https://learn.microsoft.com/en-us/rest/api/attestation/attestation/> > attest-tdx-vm?view=rest- > attestation-2025-06-01&tabs=HTTP#inittimedata <https:// > learn.microsoft.com/en-us/rest/api/attestation/attestation/attest- <http://learn.microsoft.com/en-us/rest/api/attestation/attestation/attest->
> tdx-vm?view=rest-attestation-2025-06-01&tabs=HTTP#inittimedata> > > [3] > https://github.com/confidential-containers/confidential-containers/ <https://github.com/confidential-containers/confidential-containers/> > issues/171#issue-1985098907 <https://github.com/confidential- <https://github.com/confidential-> > containers/confidential-containers/issues/171#issue-1985098907> > > [4] > https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef- <https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef-> > ab08-4813f4e0ff92@intel.com/ <http://ab08-4813f4e0ff92@intel.com/> <https://lore.kernel.org/qemu- <https://lore.kernel.org/qemu-> > devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/ <http://31d6dbc1-f453-4cef-ab08-4813f4e0ff92@intel.com/>> > > > On 1/20/26 1:58 AM, Markus Hentsch wrote: > >> Dear Anton, > >> > >> during the last PTG (project team gathering) there was some > >> discussion about future extensions to the confidential computing > >> support in Nova, not limited to just SEV-SNP [1]. As a result, there > >> is currently ongoing work on extending the architecture to prepare > >> for supporting multiple vendor's technologies [2][3], for example > >> Intel TDX and ARM CCA, in addition to AMD SEV. > >> > >> Maybe you could help with reviewing the patchsets to ensure that the > >> architecture changes will work for TDX and/or join in there at some > >> point and contribute to the TDX-specific side of things directly. I > >> think that either would be very valuable. > Great to see that TDX is already planned for. Glad to join in on reviews > until TDX specifics are needed. > > >> > >> > >> [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687> > <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 <https://etherpad.opendev.org/p/nova-2026.1-ptg#L687>> > >> > >> [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev- <https://blueprints.launchpad.net/nova/+spec/generalize-sev-> > code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code <https://blueprints.launchpad.net/nova/+spec/generalize-sev-code>> > >> > >> [3] https://review.opendev.org/q/topic:%22bp/generalize-sev- <https://review.opendev.org/q/topic:%22bp/generalize-sev-> > code%22 <https://review.opendev.org/q/topic:%22bp/generalize-sev- <https://review.opendev.org/q/topic:%22bp/generalize-sev-> > code%22> > >> > >> > >> Kind regards, > >> > >> Markus > >> > >> > >>> Hi, > >>> > >>> I work with confidential computing and has previously > contributed to > >>> Proxmox [1] to enable support for Intel TDX. I am looking to do the > >>> same for Openstack Nova. > >>> > >>> I have proposed a blueprint [2] and am drafting a spec with target > >>> for 2026.2 release. > >>> > >>> From what I gather, support for AMD SEV and SEV-ES is already > >>> implemented in Nova, while SEV-SNP support is ongoing. TDX shares > >>> some commonalities with SEV-SNP, and I believe that the work on > both > >>> can be conducted in tandem. I also have experience with SEV-SNP and > >>> am happy to contribute if needed. > >>> > >>> Early feedback or any concerns and guidance are very welcome! > >>> > >>> [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1> > <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 <https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1>> [2] > >>> https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-> > <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- <https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt->> > >>> support > >>> > >>> Best Regards, Anton > >> > > >
-- Markus Hentsch DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 00 markus.hentsch@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann
participants (4)
-
Anton Iacobaeus
-
Markus Hentsch
-
Rene Ribaud
-
Takashi Kajinami