feat: Improve CoCo pattern docs - vendor parity, accuracy, and completeness

- Add AMD SEV-SNP support section (equal coverage with Intel TDX)
- Broaden NVIDIA GPU support from H100-only to H100/H200/B100/B200
- Clarify Azure VM families are configurable (not just Standard_DCas_v5)
- Add Intel TDX and AMD SEV vendor documentation links
- Add Technology Preview designation for GPU support
- Note GPU topology supports both Intel TDX and AMD SEV-SNP
- Fix bare metal storage references: HPP not LVMS
- Add 5 new troubleshooting entries:
  * Vault secrets timing out due to MCO reboots
  * ArgoCD apps in per-clusterGroup namespaces
  * CoCo pods starting before initdata annotations ready
  * SGX registration reset needed for TDX cluster rebuilds
  * TEE firmware misconfiguration detection
- Clarify "CoCo pods" terminology throughout troubleshooting
- Add MCO reboot notes to bare metal deployment sections
- Update wordlist: blackwell, epyc, genoa, hpp, milan

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: butler54

.wordlist.txt

@@ -91,6 +91,7 @@ bh
 bitnami
 bj
 bjp
+blackwell
 bls
 bluegreen
 bluegreenpause
@@ -297,6 +298,7 @@ env
 envi
 envs
 ep
+epyc
 erp
 eso
 eso's
@@ -347,6 +349,7 @@ gcp
 gcqna
 genai
 genaiexamples
+genoa
 genrsa
 gf
 gh
@@ -406,6 +409,7 @@ hostingcluster
 hostname
 howto
 hpc
+hpp
 htpasswd
 httpbin
 httpd
@@ -617,6 +621,7 @@ microcontrollers
 microservice
 microservices
 middleware
+milan
 militaries
 millicore
 mins

content/patterns/coco-pattern/_index.adoc

@@ -174,26 +174,45 @@ Intel Trusted Domain Extensions (TDX) is a hardware-based TEE technology that is
 
 The pattern's Intel DCAP chart deploys PCCS as a centralized caching service and QGS as a DaemonSet on TDX nodes. Quote generation happens within the TEE, with PCCS providing attestation collateral to Trustee for verification.
 
-== NVIDIA confidential GPU support
+== AMD SEV-SNP support
 
-NVIDIA H100 GPUs with confidential computing firmware enable GPU-accelerated workloads to run inside TEEs with hardware-enforced memory encryption and attestation. The pattern's `baremetal-gpu` topology provides full support for NVIDIA confidential GPUs on bare metal.
+AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) is a hardware-based TEE technology that provides VM isolation through memory encryption and integrity protection. SEV-SNP extends AMD's SEV technology with secure nested paging to protect against additional attack vectors. The pattern provides full AMD SEV-SNP support on bare metal deployments.
+
+**Key features:**
+
+- **Automatic hardware detection**: Node Feature Discovery (NFD) detects SEV-SNP-capable processors and labels nodes with `amd.feature.node.kubernetes.io/snp=true`
+- **Certificate chain-based attestation**: AMD SEV-SNP uses a certificate chain model for attestation verification, eliminating the need for a collateral caching service like Intel's PCCS
+- **Transparent runtime selection**: The `kata-cc` RuntimeClass automatically uses the SEV-SNP handler (`kata-snp`) on labeled nodes
+- **MachineConfig automation**: Kernel parameters for SEV-SNP enablement and vsock modules are applied automatically
+
+**Deployment requirements:**
+
+- AMD EPYC processors with SEV-SNP support (3rd Gen Milan or newer)
+- BIOS/firmware with SEV-SNP enabled
+- No external attestation service required (certificate chain-based model)
+
+AMD SEV-SNP's certificate chain approach simplifies the attestation infrastructure compared to Intel TDX, as the full certificate chain is embedded in the attestation evidence sent to Trustee for verification.
+
+== NVIDIA confidential GPU support (**Technology Preview**)
+
+NVIDIA confidential GPUs with confidential computing firmware enable GPU-accelerated workloads to run inside TEEs with hardware-enforced memory encryption and attestation. The pattern's `baremetal-gpu` topology provides support for NVIDIA confidential GPUs (H100, H200, B100, B200) on bare metal with either Intel TDX or AMD SEV-SNP as the host TEE platform.
 
 **Key features:**
 
 - **GPU passthrough via VFIO**: GPUs are passed through to Kata confidential VMs using IOMMU and VFIO, providing native GPU performance
 - **Confidential Computing Manager**: NVIDIA CC Manager enforces confidential mode at the GPU firmware level
 - **GPU attestation**: The GPU's attestation evidence is included in the TEE's attestation report to Trustee
 - **Kata device plugin**: The NVIDIA Kata sandbox device plugin exposes GPUs as schedulable resources (`nvidia.com/pgpu`)
+- **Multi-platform support**: Works with both Intel TDX and AMD SEV-SNP host TEE platforms
 
 **Deployment requirements:**
 
-- NVIDIA H100 GPUs with confidential computing firmware
-- IOMMU-capable system (kernel parameters applied via MachineConfig)
+- NVIDIA GPUs with confidential computing firmware (H100, H200, B100, B200)
+- Intel TDX or AMD SEV-SNP enabled bare metal host
+- IOMMU-capable system (kernel parameters applied via MachineConfig: `intel_iommu=on` or `amd_iommu=on`)
 - NVIDIA GPU Operator v26.3.0+
 
-The pattern includes a sample CUDA workload (`gpu-vectoradd`) that demonstrates GPU-accelerated computation within a confidential container, verifying both GPU functionality and attestation integration.
-
-**Note**: AMD SEV-SNP is also supported on bare metal as an alternative TEE technology. SEV-SNP uses AMD EPYC processors with encrypted memory and secure nested paging. However, additional enhancements and testing are planned for future releases, so Intel TDX and NVIDIA confidential GPUs are currently the primary focus for bare metal deployments.
+The pattern includes a sample CUDA workload (`gpu-vectoradd`) that demonstrates GPU-accelerated computation within a confidential container, verifying both GPU functionality and attestation integration. Testing has been performed with Intel TDX + H100; AMD SEV-SNP + GPU configurations are expected to work but have not been fully validated.
 
 == References
 
@@ -213,9 +232,16 @@ The pattern includes a sample CUDA workload (`gpu-vectoradd`) that demonstrates
 **Intel TDX:**
 
 - https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html[Intel TDX overview]
+- https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/03/hardware_selection/[Intel TDX hardware selection guide]
+- https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/04/hardware_setup/#install-intel-tdx-enabled-bios[Intel TDX BIOS setup guide]
 - https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.12/html/deploying_confidential_containers/deploying-confidential-containers-on-bare-metal[Deploying confidential containers on bare metal]
 - https://api.portal.trustedservices.intel.com[Intel Provisioning Certificate Service]
 
+**AMD SEV-SNP:**
+
+- https://www.amd.com/en/developer/sev.html[AMD SEV developer page]
+- https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.12/html/deploying_confidential_containers/deploying-confidential-containers-on-bare-metal[Deploying confidential containers on bare metal]
+
 **NVIDIA Confidential Computing:**
 
 - https://docs.nvidia.com/confidential-computing/[NVIDIA Confidential Computing documentation]

content/patterns/coco-pattern/coco-pattern-azure-requirements.adoc

@@ -33,10 +33,11 @@ This can be done by using `openshift-install create install-config` first and ad
 ----
 
 On a cloud provider the virtual machines for the kata containers use "peer pods" which are running directly on the cloud provider's hypervisor (see the diagram below).
-This means that access is required to the "confidential computing" virtual machine class. On Azure the `Standard_DCas_v5` class of virtual machines are used.
-These virtual machines are *NOT* available in all regions. Check https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/[Azure products by region] to confirm availability in your target region.
+This means that access is required to Azure https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-options[confidential VM families]. Azure offers multiple confidential computing VM families including `Standard_DCas_v5` (AMD SEV-SNP), `Standard_DCes_v5` (Intel TDX), `Standard_ECas_v5` (AMD SEV-SNP, memory-optimized), and others. **This pattern defaults to `Standard_DCas_v5`** but can be configured to use other confidential VM families by modifying the VM size parameters in `values-global.yaml`.
 
-Users will also need to request quota increases for the `Standard_DC2as_v5` (and optionally `Standard_DC4as_v5`, `Standard_DC8as_v5`, `Standard_DC16as_v5`) virtual machine families in their target region. By default, Azure subscriptions may have zero quota for confidential computing VM sizes.
+These confidential VMs are *NOT* available in all regions. Check https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/[Azure products by region] to confirm availability of your chosen VM family in your target region.
+
+Users will also need to request quota increases for their chosen confidential VM family (e.g., `Standard_DC2as_v5`, `Standard_DC4as_v5`, `Standard_DC8as_v5`, `Standard_DC16as_v5` for the DCas_v5 family) in their target region. By default, Azure subscriptions may have zero quota for confidential computing VM sizes.
 
 image::coco-pattern/peer_pods.png[Schematic diagram of peer pods vs standard kata containers]
 

content/patterns/coco-pattern/coco-pattern-getting-started.adoc

@@ -32,7 +32,7 @@ include::modules/comm-attributes.adoc[]
 
 1. Install OpenShift 4.19.28+ on bare metal with Intel TDX or AMD SEV-SNP hardware
 
-2. Ensure BIOS/firmware is configured to enable TDX or SEV-SNP. Consult your hardware vendor's documentation for TEE enablement procedures.
+2. Ensure BIOS/firmware is configured to enable TDX or SEV-SNP. For Intel TDX, consult the https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/04/hardware_setup/#install-intel-tdx-enabled-bios[Intel TDX BIOS setup guide]. For AMD SEV-SNP, consult the https://www.amd.com/en/developer/sev.html[AMD SEV developer documentation] and your hardware vendor's TEE enablement procedures.
 
 3. For Intel TDX: Obtain an Intel PCS API key from https://api.portal.trustedservices.intel.com[Intel Trusted Services]
 
@@ -87,11 +87,13 @@ The bare metal topology uses the `baremetal` clusterGroup for Intel TDX or AMD S
 5. `./pattern.sh make install`
 
 6. Wait for the cluster to reboot nodes. The pattern applies MachineConfig updates for:
-   - TDX/SEV-SNP kernel parameters (e.g., `kvm_intel.tdx=1` for Intel)
+   - TDX/SEV-SNP kernel parameters (e.g., `kvm_intel.tdx=1` for Intel TDX, `kvm_amd.sev=1` for AMD SEV-SNP)
    - `nohibernate` kernel argument
    - vsock-loopback kernel module configuration
    +
    Monitor node reboot progress: `oc get nodes` or `oc get mcp`
+   +
+   **Note**: MCO-driven reboots during initial deployment may cause Vault secret loading to time out. If secrets fail to load after nodes finish rebooting (`oc get mcp` shows `UPDATED=True`), manually re-trigger secret loading by running `./pattern.sh make upgrade`.
 
 [NOTE]
 ====
@@ -105,16 +107,16 @@ The pattern automatically detects and configures your TEE hardware:
 - **Node Feature Discovery (NFD)** labels nodes based on detected capabilities:
   - Intel TDX: `intel.feature.node.kubernetes.io/tdx=true`
   - AMD SEV-SNP: `amd.feature.node.kubernetes.io/snp=true`
-- **LVMS** discovers available block devices for persistent storage
+- **HostPath Provisioner (HPP)** provides persistent storage for bare metal deployments
 - **RuntimeClass**: The `kata-cc` RuntimeClass is created automatically, using `kata-tdx` or `kata-snp` handler based on detected hardware
 - Both `kata-tdx` and `kata-snp` RuntimeClasses are deployed; only the one matching your hardware will have schedulable nodes
 - **Intel DCAP components** (PCCS and QGS) deploy unconditionally but DaemonSets only schedule on Intel TDX nodes via NFD label selectors
 
 **Optional PCCS node pinning:** For Intel TDX deployments, you can pin the PCCS service to a specific node by running `bash scripts/get-pccs-node.sh` and setting `baremetal.pccs.nodeSelector` in the baremetal chart values.
 
-=== Bare metal GPU deployment
+=== Bare metal GPU deployment (**Technology Preview**)
 
-The `baremetal-gpu` topology extends the bare metal deployment with NVIDIA H100 confidential GPU support.
+The `baremetal-gpu` topology extends the bare metal deployment with NVIDIA confidential GPU support (H100, H200, B100, B200). This topology works with both Intel TDX and AMD SEV-SNP as the host TEE platform.
 
 1. Set `main.clusterGroupName: baremetal-gpu` in `values-global.yaml`
 
@@ -129,6 +131,8 @@ The `baremetal-gpu` topology extends the bare metal deployment with NVIDIA H100
    - AMD: `amd_iommu=on`
    +
    All nodes will reboot to apply these kernel parameters.
+   +
+   **Note**: MCO-driven reboots may cause Vault secret loading to time out. If needed, re-run `./pattern.sh make upgrade` after nodes finish rebooting.
 
 6. Approve the GPU Operator install plan when it appears. The pattern uses `installPlanApproval: Manual` to ensure version control. Check for pending install plans:
    +

content/patterns/coco-pattern/coco-pattern-tested-environments.adoc

@@ -14,7 +14,7 @@ include::modules/comm-attributes.adoc[]
 
 == Current version (5.*)
 
-Version 5 introduces Kyverno-based `cc_init_data` injection, bare metal support (Intel TDX, AMD SEV-SNP), and NVIDIA H100 confidential GPU support.
+Version 5 introduces Kyverno-based `cc_init_data` injection, bare metal support (Intel TDX, AMD SEV-SNP), and **Technology Preview** NVIDIA confidential GPU support (H100, H200, B100, B200).
 
 === Supported components
 - OpenShift Sandboxed Containers Operator 1.12
@@ -31,7 +31,7 @@ Version 5 introduces Kyverno-based `cc_init_data` injection, bare metal support
 === Azure single cluster
 Tested on Azure with the `simple` clusterGroup using self-managed OpenShift 4.19.28+ provisioned via `openshift-install`. In this topology all components — Trustee, Vault, ACM, sandboxed containers operator, Kyverno, and sample workloads — are deployed on a single cluster.
 
-Worker nodes use `Standard_D8s_v5` or larger. Peer-pod VMs for confidential containers use `Standard_DC2as_v5` from the Azure confidential computing VM family. Azure DNS is required for the cluster's hosted zone.
+Worker nodes use `Standard_D8s_v5` or larger. Peer-pod VMs for confidential containers default to `Standard_DC2as_v5` from the Azure confidential computing VM family, but other Azure https://learn.microsoft.com/en-us/azure/confidential-computing/virtual-machine-options[confidential VM families] can be configured in `values-global.yaml`. Azure DNS is required for the cluster's hosted zone.
 
 **Important**: Azure confidential VM availability varies by region. Before deploying, verify that your target region supports `Standard_DCas_v5` VMs and that your subscription has sufficient quota. See the link:../coco-pattern-azure-requirements/[Azure requirements] page for regional availability details.
 
@@ -48,7 +48,7 @@ Tested on Single Node OpenShift (SNO) with Intel TDX hardware using the `baremet
 
 **Hardware configuration:**
 - Intel Xeon Sapphire Rapids processors (4th Gen) with TDX enabled in BIOS
-- LVMS for storage (auto-discovers available block devices)
+- HPP (HostPath Provisioner) for storage
 - NFD detects TDX capability and labels the node with `intel.feature.node.kubernetes.io/tdx=true`
 
 **Deployed components:**
@@ -63,27 +63,25 @@ Tested on Single Node OpenShift (SNO) with AMD SEV-SNP hardware using the `barem
 
 **Hardware configuration:**
 - AMD EPYC Genoa processors with SEV-SNP enabled in BIOS
-- LVMS for storage (auto-discovers available block devices)
+- HPP (HostPath Provisioner) for storage
 - NFD detects SEV-SNP capability and labels the node with `amd.feature.node.kubernetes.io/snp=true`
 
 **Deployed components:**
 - Trustee, Vault, Kyverno, sandboxed containers operator, NFD
 - Sample workloads use `runtimeClassName: kata-cc` with the `kata-snp` handler
 - No PCCS required (AMD uses certificate chain-based attestation)
 
-**Note**: Additional enhancements for AMD SEV-SNP are planned for future releases.
-
-=== Bare metal GPU single cluster (Intel TDX + NVIDIA H100)
-Tested on Single Node OpenShift (SNO) with Intel TDX and NVIDIA H100 confidential GPUs using the `baremetal-gpu` clusterGroup.
+=== Bare metal GPU single cluster (**Technology Preview**)
+Tested on Single Node OpenShift (SNO) with Intel TDX and NVIDIA confidential GPUs using the `baremetal-gpu` clusterGroup. This topology supports both Intel TDX and AMD SEV-SNP as the host TEE platform.
 
 **Hardware configuration:**
-- Intel Xeon Sapphire Rapids processors with TDX enabled in BIOS
-- NVIDIA H100 GPUs with confidential computing firmware
+- Intel Xeon Sapphire Rapids processors with TDX enabled in BIOS (tested) or AMD EPYC Milan/Genoa processors with SEV-SNP (expected to work)
+- NVIDIA confidential GPUs with confidential computing firmware (tested with H100; H200, B100, B200 supported)
 - IOMMU enabled for GPU passthrough
-- LVMS for storage
+- HPP (HostPath Provisioner) for storage
 
 **Deployed components:**
-- All components from bare metal Intel TDX configuration
+- All components from bare metal Intel TDX or AMD SEV-SNP configuration
 - NVIDIA GPU Operator with CC Manager, VFIO manager, and Kata device plugin
 - GPU workload (`gpu-vectoradd`) uses `runtimeClassName: kata-cc-nvidia-gpu`
 - GPU attestation integrated with Trustee KBS
@@ -99,7 +97,7 @@ All pattern versions prior to v4 used Technology Preview (pre-GA) releases of Tr
 | 1.1 (GA)
 | 1.12
 | 4.19.28+
-| Kyverno-based cc_init_data injection. Bare metal support (Intel TDX, AMD SEV-SNP). NVIDIA H100 confidential GPU support.
+| Kyverno-based cc_init_data injection. Bare metal support (Intel TDX, AMD SEV-SNP). NVIDIA confidential GPU support (Technology Preview: H100, H200, B100, B200).
 
 | 4.*
 | 1.0 (GA)