do-not-merge: main, with no cache

Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>

.cspell.yaml

@@ -1,37 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json
-version: "0.2"
-language: en,en-GB
-
-dictionaryDefinitions:
-  - name: kata-terms
-    path: ./tests/spellcheck/kata-dictionary.txt
-    addWords: true
-
-dictionaries:
-  - en-GB
-  - en_US
-  - bash
-  - git
-  - golang
-  - k8s
-  - python
-  - rust
-  - companies
-  - mnemonics
-  - peopleNames
-  - softwareTerms
-  - networking-terms
-  - kata-terms
-
-ignoreRegExpList:
-  - /@[a-z\d](?:[a-z\d]|-(?=[a-z\d])){0,38}/gi  # Ignores github handles
-  # Ignore code blocks
-  - /^\s*`{3,}[\s\S]*?^\s*`{3,}/gm
-  - /`[^`\n]+`/g
-
-ignorePaths:
-  - "**/vendor/**"  # vendor files aren't owned by us
-  - "**/src/runtime/virtcontainers/pkg/cloud-hypervisor/client/**"  # Generated files
-  - "**/requirements.txt"
-
-useGitignore: true

.editorconfig

@@ -1,7 +0,0 @@
-root = true
-
-[*]
-charset = utf-8
-end_of_line = lf
-insert_final_newline = true
-trim_trailing_whitespace = true

.editorconfig-checker.json

@@ -1,30 +0,0 @@
-{
-  "Verbose": false,
-  "Debug": false,
-  "IgnoreDefaults": false,
-  "SpacesAfterTabs": false,
-  "NoColor": false,
-  "Exclude": [
-    "src/runtime/vendor",
-    "src/tools/log-parser/vendor",
-    "tests/metrics/cmd/checkmetrics/vendor",
-    "tests/vendor",
-    "src/runtime/virtcontainers/pkg/cloud-hypervisor/client",
-    "\\.img$",
-    "\\.dtb$",
-    "\\.drawio$",
-    "\\.svg$",
-    "\\.patch$"
-  ],
-  "AllowedContentTypes": [],
-  "PassedFiles": [],
-  "Disable": {
-    "EndOfLine": false,
-    "Indentation": false,
-    "IndentSize": false,
-    "InsertFinalNewline": false,
-    "TrimTrailingWhitespace": false,
-    "MaxLineLength": false,
-    "Charset": false
-  }
-}

.github/actionlint.yaml

@@ -28,9 +28,3 @@ self-hosted-runner:
     - s390x-large
     - tdx
     - ubuntu-24.04-arm
-
-paths:
-  .github/workflows/**/*.{yml,yaml}:
-    ignore:
-      # We use if: false to "temporarily" skip jobs with issues
-      - 'constant expression "false" in condition'

.github/cargo-deny-composite-action/cargo-deny-skeleton.yaml.in

@@ -17,7 +17,7 @@ runs:
       uses: actions-rs/toolchain@v1
       with:
         profile: minimal
-        toolchain: nightly
+        toolchain: nightly 
         override: true
 
     - name: Cache

.github/dependabot.yml

@@ -15,8 +15,6 @@ updates:
       - "/src/tools/trace-forwarder"
     schedule:
       interval: "daily"
-    cooldown:
-      default-days: 7
     ignore:
     # rust-vmm repos might cause incompatibilities on patch versions, so
     # lets handle them manually for now.
@@ -37,9 +35,9 @@ updates:
     # create groups for common dependencies, so they can all go in a single PR
     # We can extend this as we see more frequent groups
     groups:
-      aws-libcrypto:
+      bit-vec:
         patterns:
-          - aws-lc-*
+          - bit-vec
       bumpalo:
         patterns:
           - bumpalo
@@ -67,9 +65,6 @@ updates:
       rustix:
         patterns:
           - rustix
-      rustls-webpki:
-        patterns:
-          - rustls-webpki
       slab:
         patterns:
           - slab
@@ -90,12 +85,8 @@ updates:
       - "src/tools/csi-kata-directvolume"
     schedule:
       interval: "daily"
-    cooldown:
-      default-days: 7
 
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule:
       interval: "monthly"
-    cooldown:
-      default-days: 7

.github/workflows/actionlint.yaml

@@ -13,13 +13,18 @@ concurrency:
 jobs:
   run-actionlint:
     name: run-actionlint
+    env:
+      GH_TOKEN: ${{ github.token }}
     runs-on: ubuntu-24.04
     steps:
       - name: Checkout the code
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd  # v6.0.2
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: 0
           persist-credentials: false
 
+      - name: Install actionlint gh extension
+        run: gh extension install https://github.com/cschleiden/gh-actionlint
+
       - name: Run actionlint
-        uses: raven-actions/actionlint@e01d1ea33dd6a5ed517d95b4c0c357560ac6f518  # v2.1.1
+        run:  gh actionlint

.github/workflows/basic-ci-amd64.yaml

@@ -47,23 +47,6 @@ jobs:
         env:
           TARGET_BRANCH: ${{ inputs.target-branch }}
 
-      - name: Install yq
-        run: |
-          ./ci/install_yq.sh
-        env:
-          INSTALL_IN_GOPATH: false
-
-      - name: Read properties from versions.yaml
-        run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
-
       - name: Install dependencies
         run: bash tests/integration/cri-containerd/gha-run.sh install-dependencies
         env:
@@ -364,7 +347,7 @@ jobs:
           path: kata-tools-artifacts
 
       - name: Install kata & kata-tools
-        run: |
+        run: | 
           bash tests/functional/kata-agent-apis/gha-run.sh install-kata kata-artifacts
           bash tests/functional/kata-agent-apis/gha-run.sh install-kata-tools kata-tools-artifacts
 

.github/workflows/basic-ci-s390x.yaml

@@ -47,25 +47,8 @@ jobs:
         env:
           TARGET_BRANCH: ${{ inputs.target-branch }}
 
-      - name: Install yq
-        run: |
-          ./ci/install_yq.sh
-        env:
-          INSTALL_IN_GOPATH: false
-
-      - name: Read properties from versions.yaml
-        run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
-
       - name: Install dependencies
-        run: bash tests/integration/cri-containerd/gha-run.sh install-dependencies
+        run: bash tests/integration/cri-containerd/gha-run.sh
         env:
           GH_TOKEN: ${{ github.token }}
 

.github/workflows/build-checks-preview-riscv64.yaml

@@ -82,17 +82,11 @@ jobs:
           ./ci/install_yq.sh
         env:
           INSTALL_IN_GOPATH: false
-      - name: Read properties from versions.yaml
+      - name: Install golang
         if: contains(matrix.component.needs, 'golang')
         run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        if: contains(matrix.component.needs, 'golang')
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
+          ./tests/install_go.sh -f -p
+          echo "/usr/local/go/bin" >> "$GITHUB_PATH"
       - name: Setup rust
         if: contains(matrix.component.needs, 'rust')
         run: |

.github/workflows/build-checks.yaml

@@ -74,7 +74,7 @@ jobs:
               - rust
               - protobuf-compiler
         instance:
-          - ${{ inputs.instance }}
+          - ${{ inputs.instance }} 
 
     steps:
       - name: Adjust a permission for repo
@@ -94,19 +94,11 @@ jobs:
           ./ci/install_yq.sh
         env:
           INSTALL_IN_GOPATH: false
-      - name: Read properties from versions.yaml
+      - name: Install golang
         if: contains(matrix.component.needs, 'golang')
         run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        if: contains(matrix.component.needs, 'golang')
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
-          # Setup-go doesn't work properly with ppc64le: https://github.com/actions/setup-go/issues/648
-          architecture: ${{ contains(inputs.instance, 'ppc64le') && 'ppc64le' || '' }}
+          ./tests/install_go.sh -f -p
+          echo "/usr/local/go/bin" >> "$GITHUB_PATH"
       - name: Setup rust
         if: contains(matrix.component.needs, 'rust')
         run: |

.github/workflows/build-kata-static-tarball-amd64.yaml

@@ -47,9 +47,10 @@ jobs:
           - coco-guest-components
           - firecracker
           - kernel
-          - kernel-debug
+          - kernel-confidential
           - kernel-dragonball-experimental
           - kernel-nvidia-gpu
+          - kernel-nvidia-gpu-confidential
           - nydus
           - ovmf
           - ovmf-sev
@@ -169,6 +170,8 @@ jobs:
           - rootfs-image-nvidia-gpu-confidential
           - rootfs-initrd
           - rootfs-initrd-confidential
+          - rootfs-initrd-nvidia-gpu
+          - rootfs-initrd-nvidia-gpu-confidential
     steps:
       - name: Login to Kata Containers quay.io
         if: ${{ inputs.push-to-registry == 'yes' }}
@@ -235,6 +238,7 @@ jobs:
           - busybox
           - coco-guest-components
           - kernel-nvidia-gpu-modules
+          - kernel-nvidia-gpu-confidential-modules
           - pause-image
     steps:
       - uses: geekyeggo/delete-artifact@f275313e70c08f6120db482d7a6b98377786765b # v5.1.0
@@ -348,16 +352,6 @@ jobs:
           ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts versions.yaml
         env:
           RELEASE: ${{ inputs.stage == 'release' && 'yes' || 'no' }}
-      - name: Check kata tarball size (GitHub release asset limit)
-        run: |
-          # https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
-          GITHUB_ASSET_MAX_BYTES=2147483648
-          tarball_size=$(stat -c "%s" kata-static.tar.zst)
-          if [[ "${tarball_size}" -ge "${GITHUB_ASSET_MAX_BYTES}" ]]; then
-            echo "::error::tarball size (${tarball_size} bytes) >= GitHub release asset limit (${GITHUB_ASSET_MAX_BYTES} bytes)"
-            exit 1
-          fi
-          echo "tarball size: ${tarball_size} bytes"
       - name: store-artifacts
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:
@@ -376,6 +370,7 @@ jobs:
       matrix:
         asset:
           - agent-ctl
+          - csi-kata-directvolume
           - genpolicy
           - kata-ctl
           - kata-manager
@@ -458,16 +453,6 @@ jobs:
           ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-tools-artifacts versions.yaml kata-tools-static.tar.zst
         env:
           RELEASE: ${{ inputs.stage == 'release' && 'yes' || 'no' }}
-      - name: Check kata-tools tarball size (GitHub release asset limit)
-        run: |
-          # https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
-          GITHUB_ASSET_MAX_BYTES=2147483648
-          tarball_size=$(stat -c "%s" kata-tools-static.tar.zst)
-          if [[ "${tarball_size}" -ge "${GITHUB_ASSET_MAX_BYTES}" ]]; then
-            echo "::error::tarball size (${tarball_size} bytes) >= GitHub release asset limit (${GITHUB_ASSET_MAX_BYTES} bytes)"
-            exit 1
-          fi
-          echo "tarball size: ${tarball_size} bytes"
       - name: store-artifacts
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:

.github/workflows/build-kata-static-tarball-arm64.yaml

@@ -45,7 +45,6 @@ jobs:
           - cloud-hypervisor
           - firecracker
           - kernel
-          - kernel-debug
           - kernel-dragonball-experimental
           - kernel-nvidia-gpu
           - kernel-cca-confidential
@@ -153,6 +152,7 @@ jobs:
           - rootfs-image
           - rootfs-image-nvidia-gpu
           - rootfs-initrd
+          - rootfs-initrd-nvidia-gpu
     steps:
       - name: Login to Kata Containers quay.io
         if: ${{ inputs.push-to-registry == 'yes' }}
@@ -327,16 +327,6 @@ jobs:
           ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts versions.yaml
         env:
           RELEASE: ${{ inputs.stage == 'release' && 'yes' || 'no' }}
-      - name: Check kata tarball size (GitHub release asset limit)
-        run: |
-          # https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
-          GITHUB_ASSET_MAX_BYTES=2147483648
-          tarball_size=$(stat -c "%s" kata-static.tar.zst)
-          if [[ "${tarball_size}" -ge "${GITHUB_ASSET_MAX_BYTES}" ]]; then
-            echo "::error::tarball size (${tarball_size} bytes) >= GitHub release asset limit (${GITHUB_ASSET_MAX_BYTES} bytes)"
-            exit 1
-          fi
-          echo "tarball size: ${tarball_size} bytes"
       - name: store-artifacts
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:

.github/workflows/build-kata-static-tarball-ppc64le.yaml

@@ -262,16 +262,6 @@ jobs:
           ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts versions.yaml
         env:
           RELEASE: ${{ inputs.stage == 'release' && 'yes' || 'no' }}
-      - name: Check kata tarball size (GitHub release asset limit)
-        run: |
-          # https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
-          GITHUB_ASSET_MAX_BYTES=2147483648
-          tarball_size=$(stat -c "%s" kata-static.tar.zst)
-          if [[ "${tarball_size}" -ge "${GITHUB_ASSET_MAX_BYTES}" ]]; then
-            echo "::error::tarball size (${tarball_size} bytes) >= GitHub release asset limit (${GITHUB_ASSET_MAX_BYTES} bytes)"
-            exit 1
-          fi
-          echo "tarball size: ${tarball_size} bytes"
       - name: store-artifacts
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:

.github/workflows/build-kata-static-tarball-s390x.yaml

@@ -44,6 +44,7 @@ jobs:
           - agent
           - coco-guest-components
           - kernel
+          - kernel-confidential
           - pause-image
           - qemu
           - virtiofsd
@@ -350,16 +351,6 @@ jobs:
           ./tools/packaging/kata-deploy/local-build/kata-deploy-merge-builds.sh kata-artifacts versions.yaml
         env:
           RELEASE: ${{ inputs.stage == 'release' && 'yes' || 'no' }}
-      - name: Check kata tarball size (GitHub release asset limit)
-        run: |
-          # https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
-          GITHUB_ASSET_MAX_BYTES=2147483648
-          tarball_size=$(stat -c "%s" kata-static.tar.zst)
-          if [[ "${tarball_size}" -ge "${GITHUB_ASSET_MAX_BYTES}" ]]; then
-            echo "::error::tarball size (${tarball_size} bytes) >= GitHub release asset limit (${GITHUB_ASSET_MAX_BYTES} bytes)"
-            exit 1
-          fi
-          echo "tarball size: ${tarball_size} bytes"
       - name: store-artifacts
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:

.github/workflows/ci-devel.yaml

@@ -17,7 +17,6 @@ jobs:
       pr-number: "dev"
       tag: ${{ github.sha }}-dev
       target-branch: ${{ github.ref_name }}
-      extensive-matrix-autogenerated-policy: "yes"
 
     secrets:
       AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}

.github/workflows/ci-nightly.yaml

@@ -22,7 +22,6 @@ jobs:
       pr-number: "nightly"
       tag: ${{ github.sha }}-nightly
       target-branch: ${{ github.ref_name }}
-      extensive-matrix-autogenerated-policy: "yes"
     secrets:
       AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}
       AZ_APPID: ${{ secrets.AZ_APPID }}

.github/workflows/ci.yaml

@@ -19,10 +19,6 @@ on:
         required: false
         type: string
         default: no
-      extensive-matrix-autogenerated-policy:
-        required: false
-        type: string
-        default: no
     secrets:
       AUTHENTICATED_IMAGE_PASSWORD:
         required: true
@@ -216,6 +212,61 @@ jobs:
           platforms: linux/amd64, linux/s390x
           file: tests/integration/kubernetes/runtimeclass_workloads/confidential/unencrypted/Dockerfile
 
+  publish-csi-driver-amd64:
+    name: publish-csi-driver-amd64
+    needs: build-kata-static-tarball-amd64
+    permissions:
+      contents: read
+      packages: write
+    runs-on: ubuntu-22.04
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        with:
+          ref: ${{ inputs.commit-hash }}
+          fetch-depth: 0
+          persist-credentials: false
+
+      - name: Rebase atop of the latest target branch
+        run: |
+          ./tests/git-helper.sh "rebase-atop-of-the-latest-target-branch"
+        env:
+          TARGET_BRANCH: ${{ inputs.target-branch }}
+
+      - name: get-kata-tools-tarball
+        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        with:
+          name: kata-tools-static-tarball-amd64-${{ inputs.tag }}
+          path: kata-tools-artifacts
+
+      - name: Install kata-tools
+        run: bash tests/integration/kubernetes/gha-run.sh install-kata-tools kata-tools-artifacts
+
+      - name: Copy binary into Docker context
+        run: |
+          # Copy to the location where the Dockerfile expects the binary.
+          mkdir -p src/tools/csi-kata-directvolume/bin/
+          cp /opt/kata/bin/csi-kata-directvolume src/tools/csi-kata-directvolume/bin/directvolplugin
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0
+
+      - name: Login to Kata Containers ghcr.io
+        uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Docker build and push
+        uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0
+        with:
+          tags: ghcr.io/kata-containers/csi-kata-directvolume:${{ inputs.pr-number }}
+          push: true
+          context: src/tools/csi-kata-directvolume/
+          platforms: linux/amd64
+          file: src/tools/csi-kata-directvolume/Dockerfile
+
   run-kata-monitor-tests:
     if: ${{ inputs.skip-test != 'yes' }}
     needs: build-kata-static-tarball-amd64
@@ -246,21 +297,6 @@ jobs:
       AZ_TENANT_ID: ${{ secrets.AZ_TENANT_ID }}
       AZ_SUBSCRIPTION_ID: ${{ secrets.AZ_SUBSCRIPTION_ID }}
 
-  run-k8s-tests-on-free-runner:
-    if: ${{ inputs.skip-test != 'yes' }}
-    needs: publish-kata-deploy-payload-amd64
-    permissions:
-      contents: read
-    uses: ./.github/workflows/run-k8s-tests-on-free-runner.yaml
-    with:
-      tarball-suffix: -${{ inputs.tag }}
-      registry: ghcr.io
-      repo: ${{ github.repository_owner }}/kata-deploy-ci
-      tag: ${{ inputs.tag }}-amd64
-      commit-hash: ${{ inputs.commit-hash }}
-      pr-number: ${{ inputs.pr-number }}
-      target-branch: ${{ inputs.target-branch }}
-
   run-k8s-tests-on-arm64:
     if: ${{ inputs.skip-test != 'yes' }}
     needs: publish-kata-deploy-payload-arm64
@@ -294,6 +330,7 @@ jobs:
     needs:
      - publish-kata-deploy-payload-amd64
      - build-and-publish-tee-confidential-unencrypted-image
+     - publish-csi-driver-amd64
     uses: ./.github/workflows/run-kata-coco-tests.yaml
     permissions:
       contents: read
@@ -306,7 +343,6 @@ jobs:
       commit-hash: ${{ inputs.commit-hash }}
       pr-number: ${{ inputs.pr-number }}
       target-branch: ${{ inputs.target-branch }}
-      extensive-matrix-autogenerated-policy: ${{ inputs.extensive-matrix-autogenerated-policy }}
     secrets:
       AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}
       AZ_APPID: ${{ secrets.AZ_APPID }}

.github/workflows/codeql.yml

@@ -72,7 +72,7 @@ jobs:
 
     # Initializes the CodeQL tools for scanning.
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@4bdb89f48054571735e3792627da6195c57459e2 # v3.31.10
+      uses: github/codeql-action/init@v3
       with:
         languages: ${{ matrix.language }}
         build-mode: ${{ matrix.build-mode }}
@@ -95,6 +95,6 @@ jobs:
         make -C src/runtime
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@4bdb89f48054571735e3792627da6195c57459e2 # v3.31.10
+      uses: github/codeql-action/analyze@v3
       with:
         category: "/language:${{matrix.language}}"

.github/workflows/darwin-tests.yaml

@@ -31,22 +31,10 @@ jobs:
       with:
         persist-credentials: false
 
-    - name: Install yq
+    - name: Install golang
       run: |
-        ./ci/install_yq.sh
-      env:
-        INSTALL_IN_GOPATH: false
-
-    - name: Read properties from versions.yaml
-      run: |
-        go_version="$(yq '.languages.golang.version' versions.yaml)"
-        [ -n "$go_version" ]
-        echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-    - name: Setup Golang version ${{ env.GO_VERSION }}
-      uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-      with:
-        go-version: ${{ env.GO_VERSION }}
+        ./tests/install_go.sh -f -p
+        echo "/usr/local/go/bin" >> "${GITHUB_PATH}"
 
     - name: Install Rust
       run: ./tests/install_rust.sh

.github/workflows/docs-url-alive-check.yaml

@@ -24,22 +24,10 @@ jobs:
         fetch-depth: 0
         persist-credentials: false
 
-    - name: Install yq
+    - name: Install golang
       run: |
-        ./ci/install_yq.sh
-      env:
-        INSTALL_IN_GOPATH: false
-
-    - name: Read properties from versions.yaml
-      run: |
-        go_version="$(yq '.languages.golang.version' versions.yaml)"
-        [ -n "$go_version" ]
-        echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-    - name: Setup Golang version ${{ env.GO_VERSION }}
-      uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-      with:
-        go-version: ${{ env.GO_VERSION }}
+        ./tests/install_go.sh -f -p
+        echo "/usr/local/go/bin" >> "${GITHUB_PATH}"
 
     - name: Docs URL Alive Check
       run: |

.github/workflows/docs.yaml

@@ -4,50 +4,29 @@ on:
     branches:
       - main
 permissions: {}
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
-
 jobs:
-  build:
-    runs-on: ubuntu-24.04
-    name: Build docs
+  deploy-docs:
+    name: deploy-docs
     permissions:
       contents: read
       pages: write
       id-token: write
-    steps:
-      - uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0
-      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
-        with:
-          persist-credentials: false
-      - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
-        with:
-          python-version: 3.x
-
-      - run: pip install -r docs/requirements.txt
-      - run: python3 -m mkdocs build --config-file ./mkdocs.yaml --site-dir site/
-        id: build
-
-      - uses: actions/upload-pages-artifact@7b1f4a764d45c48632c6b24a0339c27f5614fb0b # v4.0.0
-        id: deployment
-        with:
-          path: site/
-          name: github-pages
-
-  deploy:
-    needs: build
-    runs-on: ubuntu-24.04
-    name: Deploy docs
-    permissions:
-      pages: write
-      id-token: write
     environment:
       name: github-pages
       url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
     steps:
-      - name: Deploy to GitHub Pages
-        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4.0.5
-        id: deployment
+      - uses: actions/configure-pages@v5
+      - uses: actions/checkout@v5
         with:
-          artifact_name: github-pages
+          persist-credentials: false
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - run: pip install zensical
+      - run: zensical build --clean
+      - uses: actions/upload-pages-artifact@v4
+        with:
+          path: site
+      - uses: actions/deploy-pages@v4
+        id: deployment

.github/workflows/editorconfig-checker.yaml

@@ -1,29 +0,0 @@
-name: EditorConfig checker
-
-on:
-  pull_request:
-
-permissions: {}
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  editorconfig-checker:
-    name: editorconfig-checker
-    runs-on: ubuntu-24.04
-    steps:
-      - name: Checkout the code
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-        with:
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Set up editorconfig-checker
-        uses: editorconfig-checker/action-editorconfig-checker@4b6cd6190d435e7e084fb35e36a096e98506f7b9 # v2.1.0
-        with:
-          version: v3.6.1
-
-      - name: Run editorconfig-checker
-        run: editorconfig-checker

.github/workflows/govulncheck.yaml

@@ -27,22 +27,10 @@ jobs:
           fetch-depth: 0
           persist-credentials: false
 
-      - name: Install yq
+      - name: Install golang
         run: |
-          ./ci/install_yq.sh
-        env:
-          INSTALL_IN_GOPATH: false
-
-      - name: Read properties from versions.yaml
-        run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
+          ./tests/install_go.sh -f -p
+          echo "/usr/local/go/bin" >> "${GITHUB_PATH}"
 
       - name: Install govulncheck
         run: |

.github/workflows/osv-scanner.yaml

@@ -19,25 +19,23 @@ permissions: {}
 
 jobs:
   scan-scheduled:
-    name: Scan of whole repo
     permissions:
       actions: read # # Required to upload SARIF file to CodeQL
       contents: read  # Read commit contents
       security-events: write  # Require writing security events to upload SARIF file to security tab
     if: ${{ github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' }}
-    uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml@8ae4be80636b94886b3c271caad730985ce0611c" # v2.3.3
+    uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml@b00f71e051ddddc6e46a193c31c8c0bf283bf9e6" # v2.1.0
     with:
       scan-args: |-
         -r
         ./
   scan-pr:
-    name: Scan of just PR code
     permissions:
       actions: read # Required to upload SARIF file to CodeQL
       contents: read  # Read commit contents
       security-events: write  # Require writing security events to upload SARIF file to security tab
     if: ${{ github.event_name == 'pull_request' }}
-    uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml@8ae4be80636b94886b3c271caad730985ce0611c" # v2.3.3
+    uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml@b00f71e051ddddc6e46a193c31c8c0bf283bf9e6" # v2.1.0
     with:
       # Example of specifying custom arguments
       scan-args: |-

.github/workflows/push-oras-tarball-cache.yaml

@@ -1,43 +0,0 @@
-# Push gperf and busybox tarballs to the ORAS cache (ghcr.io) so that
-# download-with-oras-cache.sh can pull them instead of hitting upstream.
-# Runs when versions.yaml changes on main (e.g. after a PR merge) or manually.
-name: CI | Push ORAS tarball cache
-on:
-  push:
-    branches:
-      - main
-    paths:
-      - 'versions.yaml'
-  workflow_dispatch:
-
-permissions: {}
-
-jobs:
-  push-oras-cache:
-    name: push-oras-cache
-    runs-on: ubuntu-22.04
-    permissions:
-      contents: read
-      packages: write
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-        with:
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Install yq
-        run: ./ci/install_yq.sh
-
-      - name: Install ORAS
-        uses: oras-project/setup-oras@22ce207df3b08e061f537244349aac6ae1d214f6 # v1.2.4
-        with:
-          version: "1.2.0"
-
-      - name: Populate ORAS tarball cache
-        run: ./tools/packaging/scripts/populate-oras-tarball-cache.sh all
-        env:
-          ARTEFACT_REGISTRY: ghcr.io
-          ARTEFACT_REPOSITORY: kata-containers
-          ARTEFACT_REGISTRY_USERNAME: ${{ github.actor }}
-          ARTEFACT_REGISTRY_PASSWORD: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/run-cri-containerd-tests.yaml

@@ -35,6 +35,8 @@ on:
 jobs:
   run-cri-containerd:
     name: run-cri-containerd-${{ inputs.arch }} (${{ inputs.containerd_version }}, ${{ inputs.vmm }})
+    strategy:
+      fail-fast: false
     runs-on: ${{ inputs.runner }}
     env:
       CONTAINERD_VERSION: ${{ inputs.containerd_version }}
@@ -53,25 +55,6 @@ jobs:
         env:
           TARGET_BRANCH: ${{ inputs.target-branch }}
 
-      - name: Install yq
-        run: |
-          ./ci/install_yq.sh
-        env:
-          INSTALL_IN_GOPATH: false
-
-      - name: Read properties from versions.yaml
-        run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
-          # Setup-go doesn't work properly with ppc64le: https://github.com/actions/setup-go/issues/648
-          architecture: ${{ inputs.arch == 'ppc64le' && 'ppc64le' || '' }}
-
       - name: Install dependencies
         timeout-minutes: 15
         run: bash tests/integration/cri-containerd/gha-run.sh install-dependencies

.github/workflows/run-k8s-tests-on-aks.yaml

@@ -42,6 +42,17 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
+        host_os:
+          - ubuntu
+        vmm:
+          - clh
+          - dragonball
+          - qemu
+          - qemu-runtime-rs
+          - cloud-hypervisor
+        instance-type:
+          - small
+          - normal
         include:
           - host_os: cbl-mariner
             vmm: clh
@@ -69,7 +80,6 @@ jobs:
       KUBERNETES: "vanilla"
       K8S_TEST_HOST_TYPE: ${{ matrix.instance-type }}
       GENPOLICY_PULL_METHOD: ${{ matrix.genpolicy-pull-method }}
-      RUNS_ON_AKS: "true"
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:

.github/workflows/run-k8s-tests-on-free-runner.yaml

@@ -1,127 +0,0 @@
-# Run Kubernetes integration tests on free GitHub runners  with a locally
-# deployed cluster (kubeadm).
-name: CI | Run kubernetes tests on free runner
-on:
-  workflow_call:
-    inputs:
-      tarball-suffix:
-        required: false
-        type: string
-      registry:
-        required: true
-        type: string
-      repo:
-        required: true
-        type: string
-      tag:
-        required: true
-        type: string
-      pr-number:
-        required: true
-        type: string
-      commit-hash:
-        required: false
-        type: string
-      target-branch:
-        required: false
-        type: string
-        default: ""
-
-permissions: {}
-
-jobs:
-  run-k8s-tests:
-    name: run-k8s-tests
-    strategy:
-      fail-fast: false
-      matrix:
-        environment: [
-          { vmm: clh, containerd_version: lts },
-          { vmm: clh, containerd_version: active },
-          { vmm: dragonball, containerd_version: lts },
-          { vmm: dragonball, containerd_version: active },
-          { vmm: qemu, containerd_version: lts },
-          { vmm: qemu, containerd_version: active },
-          { vmm: qemu-runtime-rs, containerd_version: lts },
-          { vmm: qemu-runtime-rs, containerd_version: active },
-          { vmm: cloud-hypervisor, containerd_version: lts },
-          { vmm: cloud-hypervisor, containerd_version: active },
-        ]
-    runs-on: ubuntu-24.04
-    permissions:
-      contents: read
-    env:
-      DOCKER_REGISTRY: ${{ inputs.registry }}
-      DOCKER_REPO: ${{ inputs.repo }}
-      DOCKER_TAG: ${{ inputs.tag }}
-      GH_PR_NUMBER: ${{ inputs.pr-number }}
-      KATA_HOST_OS: ubuntu
-      KATA_HYPERVISOR: ${{ matrix.environment.vmm }}
-      KUBERNETES: vanilla
-      K8S_TEST_HOST_TYPE: baremetal-no-attestation
-      CONTAINER_ENGINE: containerd
-      CONTAINER_ENGINE_VERSION: ${{ matrix.environment.containerd_version }}
-      GH_TOKEN: ${{ github.token }}
-    steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-        with:
-          ref: ${{ inputs.commit-hash }}
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Rebase atop of the latest target branch
-        run: |
-          ./tests/git-helper.sh "rebase-atop-of-the-latest-target-branch"
-        env:
-          TARGET_BRANCH: ${{ inputs.target-branch }}
-
-      - name: get-kata-tools-tarball
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
-        with:
-          name: kata-tools-static-tarball-amd64${{ inputs.tarball-suffix }}
-          path: kata-tools-artifacts
-
-      - name: Install kata-tools
-        run: bash tests/integration/kubernetes/gha-run.sh install-kata-tools kata-tools-artifacts
-
-      - name: Remove unnecessary directories to free up space
-        run: |
-          sudo rm -rf /usr/local/.ghcup
-          sudo rm -rf /opt/hostedtoolcache/CodeQL
-          sudo rm -rf /usr/local/lib/android
-          sudo rm -rf /usr/share/dotnet
-          sudo rm -rf /opt/ghc
-          sudo rm -rf /usr/local/share/boost
-          sudo rm -rf /usr/lib/jvm
-          sudo rm -rf /usr/share/swift
-          sudo rm -rf /usr/local/share/powershell
-          sudo rm -rf /usr/local/julia*
-          sudo rm -rf /opt/az
-          sudo rm -rf /usr/local/share/chromium
-          sudo rm -rf /opt/microsoft
-          sudo rm -rf /opt/google
-          sudo rm -rf /usr/lib/firefox
-
-      - name: Deploy k8s (kubeadm)
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-k8s
-
-      - name: Install `bats`
-        run: bash tests/integration/kubernetes/gha-run.sh install-bats
-
-      - name: Deploy Kata
-        timeout-minutes: 20
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-kata
-
-      - name: Run tests
-        timeout-minutes: 60
-        run: bash tests/integration/kubernetes/gha-run.sh run-tests
-
-      - name: Report tests
-        if: always()
-        run: bash tests/integration/kubernetes/gha-run.sh report-tests
-
-      - name: Delete kata-deploy
-        if: always()
-        timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh cleanup
-

.github/workflows/run-k8s-tests-on-nvidia-gpu.yaml

@@ -49,8 +49,6 @@ jobs:
       KATA_HYPERVISOR: ${{ matrix.environment.vmm }}
       KUBERNETES: kubeadm
       KBS: ${{ matrix.environment.name == 'nvidia-gpu-snp' && 'true' || 'false' }}
-      SNAPSHOTTER: ${{ matrix.environment.name == 'nvidia-gpu-snp' && 'nydus' || '' }}
-      USE_EXPERIMENTAL_SNAPSHOTTER_SETUP: ${{ matrix.environment.name == 'nvidia-gpu-snp' && 'true' || 'false' }}
       K8S_TEST_HOST_TYPE: baremetal
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
@@ -100,7 +98,7 @@ jobs:
         run: bash tests/integration/kubernetes/gha-run.sh install-bats
 
       - name: Run tests ${{ matrix.environment.vmm }}
-        timeout-minutes: 60
+        timeout-minutes: 30
         run: bash tests/integration/kubernetes/gha-run.sh run-nv-tests
         env:
           NGC_API_KEY: ${{ secrets.NGC_API_KEY }}

.github/workflows/run-k8s-tests-on-ppc64le.yaml

@@ -57,24 +57,10 @@ jobs:
         env:
           TARGET_BRANCH: ${{ inputs.target-branch }}
 
-      - name: Install yq
+      - name: Install golang
         run: |
-          ./ci/install_yq.sh
-        env:
-          INSTALL_IN_GOPATH: false
-
-      - name: Read properties from versions.yaml
-        run: |
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
-          # Setup-go doesn't work properly with ppc64le: https://github.com/actions/setup-go/issues/648
-          architecture: 'ppc64le'
+          ./tests/install_go.sh -f -p
+          echo "/usr/local/go/bin" >> "$GITHUB_PATH"
 
       - name: Prepare the runner for k8s test suite
         run: bash "${HOME}/scripts/k8s_cluster_prepare.sh"

.github/workflows/run-kata-coco-tests.yaml

@@ -24,10 +24,6 @@ on:
         required: false
         type: string
         default: ""
-      extensive-matrix-autogenerated-policy:
-        required: false
-        type: string
-        default: no
     secrets:
       AUTHENTICATED_IMAGE_PASSWORD:
         required: true
@@ -110,6 +106,10 @@ jobs:
         timeout-minutes: 10
         run: bash tests/integration/kubernetes/gha-run.sh install-kbs-client
 
+      - name: Deploy CSI driver
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh deploy-csi-driver
+
       - name: Run tests
         timeout-minutes: 100
         run: bash tests/integration/kubernetes/gha-run.sh run-tests
@@ -130,42 +130,52 @@ jobs:
           [[ "${KATA_HYPERVISOR}" == "qemu-tdx" ]] && echo "ITA_KEY=${GH_ITA_KEY}" >> "${GITHUB_ENV}"
           bash tests/integration/kubernetes/gha-run.sh delete-coco-kbs
 
+      - name: Delete CSI driver
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh delete-csi-driver
+
   # Generate jobs for testing CoCo on non-TEE environments
   run-k8s-tests-coco-nontee:
     name: run-k8s-tests-coco-nontee
     strategy:
       fail-fast: false
       matrix:
-        environment: [
-          { vmm: qemu-coco-dev, snapshotter: nydus, pull_type: guest-pull },
-          { vmm: qemu-coco-dev-runtime-rs, snapshotter: nydus, pull_type: guest-pull },
-          { vmm: qemu-coco-dev, snapshotter: "", pull_type: experimental-force-guest-pull },
-        ]
-    runs-on: ubuntu-24.04
+        vmm:
+          - qemu-coco-dev
+          - qemu-coco-dev-runtime-rs
+        snapshotter:
+          - nydus
+        pull-type:
+          - guest-pull
+        include:
+          - pull-type: experimental-force-guest-pull
+            vmm: qemu-coco-dev
+            snapshotter: ""
+    runs-on: ubuntu-22.04
     permissions:
-      contents: read
+      id-token: write # Used for OIDC access to log into Azure
     environment: ci
     env:
       DOCKER_REGISTRY: ${{ inputs.registry }}
       DOCKER_REPO: ${{ inputs.repo }}
       DOCKER_TAG: ${{ inputs.tag }}
       GH_PR_NUMBER: ${{ inputs.pr-number }}
-      KATA_HYPERVISOR: ${{ matrix.environment.vmm }}
+      KATA_HYPERVISOR: ${{ matrix.vmm }}
       # Some tests rely on that variable to run (or not)
       KBS: "true"
       # Set the KBS ingress handler (empty string disables handling)
-      KBS_INGRESS: "nodeport"
+      KBS_INGRESS: "aks"
       KUBERNETES: "vanilla"
-      PULL_TYPE: ${{ matrix.environment.pull_type }}
+      PULL_TYPE: ${{ matrix.pull-type }}
       AUTHENTICATED_IMAGE_USER: ${{ vars.AUTHENTICATED_IMAGE_USER }}
       AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}
-      SNAPSHOTTER: ${{ matrix.environment.snapshotter }}
-      EXPERIMENTAL_FORCE_GUEST_PULL: ${{ matrix.environment.pull_type == 'experimental-force-guest-pull' && matrix.environment.vmm || '' }}
-      AUTO_GENERATE_POLICY: "yes"
+      SNAPSHOTTER: ${{ matrix.snapshotter }}
+      EXPERIMENTAL_FORCE_GUEST_PULL: ${{ matrix.pull-type == 'experimental-force-guest-pull' && matrix.vmm || '' }}
+      # Caution: current ingress controller used to expose the KBS service
+      # requires much vCPUs, lefting only a few for the tests. Depending on the
+      # host type chose it will result on the creation of a cluster with
+      # insufficient resources.
       K8S_TEST_HOST_TYPE: "all"
-      CONTAINER_ENGINE: "containerd"
-      CONTAINER_ENGINE_VERSION: "active"
-      GH_TOKEN: ${{ github.token }}
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
@@ -188,36 +198,39 @@ jobs:
       - name: Install kata-tools
         run: bash tests/integration/kubernetes/gha-run.sh install-kata-tools kata-tools-artifacts
 
-      - name: Remove unnecessary directories to free up space
-        run: |
-          sudo rm -rf /usr/local/.ghcup
-          sudo rm -rf /opt/hostedtoolcache/CodeQL
-          sudo rm -rf /usr/local/lib/android
-          sudo rm -rf /usr/share/dotnet
-          sudo rm -rf /opt/ghc
-          sudo rm -rf /usr/local/share/boost
-          sudo rm -rf /usr/lib/jvm
-          sudo rm -rf /usr/share/swift
-          sudo rm -rf /usr/local/share/powershell
-          sudo rm -rf /usr/local/julia*
-          sudo rm -rf /opt/az
-          sudo rm -rf /usr/local/share/chromium
-          sudo rm -rf /opt/microsoft
-          sudo rm -rf /opt/google
-          sudo rm -rf /usr/lib/firefox
+      - name: Log into the Azure account
+        uses: azure/login@a457da9ea143d694b1b9c7c869ebb04ebe844ef5 # v2.3.0
+        with:
+          client-id: ${{ secrets.AZ_APPID }}
+          tenant-id: ${{ secrets.AZ_TENANT_ID }}
+          subscription-id: ${{ secrets.AZ_SUBSCRIPTION_ID }}
 
-      - name: Deploy kubernetes
-        timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-k8s
+      - name: Create AKS cluster
+        uses: nick-fields/retry@ce71cc2ab81d554ebbe88c79ab5975992d79ba08 # v3.0.2
+        with:
+          timeout_minutes: 15
+          max_attempts: 20
+          retry_on: error
+          retry_wait_seconds: 10
+          command: bash tests/integration/kubernetes/gha-run.sh create-cluster
 
       - name: Install `bats`
         run: bash tests/integration/kubernetes/gha-run.sh install-bats
 
+      - name: Install `kubectl`
+        uses: azure/setup-kubectl@776406bce94f63e41d621b960d78ee25c8b76ede # v4.0.1
+        with:
+          version: 'latest'
+
+      - name: Download credentials for the Kubernetes CLI to use them
+        run: bash tests/integration/kubernetes/gha-run.sh get-cluster-credentials
+
       - name: Deploy Kata
         timeout-minutes: 20
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-kata
+        run: bash tests/integration/kubernetes/gha-run.sh deploy-kata-aks
         env:
-          USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: ${{ matrix.environment.snapshotter == 'nydus' }}
+          USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: ${{ env.SNAPSHOTTER == 'nydus' }}
+          AUTO_GENERATE_POLICY: ${{ env.PULL_TYPE == 'experimental-force-guest-pull' && 'no' || 'yes' }}
 
       - name: Deploy CoCo KBS
         timeout-minutes: 10
@@ -227,126 +240,9 @@ jobs:
         timeout-minutes: 10
         run: bash tests/integration/kubernetes/gha-run.sh install-kbs-client
 
-      - name: Run tests
-        timeout-minutes: 80
-        run: bash tests/integration/kubernetes/gha-run.sh run-tests
-
-      - name: Report tests
-        if: always()
-        run: bash tests/integration/kubernetes/gha-run.sh report-tests
-
-      - name: Delete kata-deploy
-        if: always()
-        timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh cleanup
-
-      - name: Delete CoCo KBS
-        if: always()
-        timeout-minutes: 10
-        run: bash tests/integration/kubernetes/gha-run.sh delete-coco-kbs
-
-  # Extensive matrix: autogenerated policy tests (nydus + experimental-force-guest-pull) on k0s, k3s, rke2, microk8s with qemu-coco-dev / qemu-coco-dev-runtime-rs
-  run-k8s-tests-coco-nontee-extensive-matrix:
-    if: ${{ inputs.extensive-matrix-autogenerated-policy == 'yes' }}
-    name: run-k8s-tests-coco-nontee-extensive-matrix
-    strategy:
-      fail-fast: false
-      matrix:
-        environment: [
-          { k8s: k0s, vmm: qemu-coco-dev, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: k0s, vmm: qemu-coco-dev, snapshotter: "", pull_type: experimental-force-guest-pull },
-          { k8s: k0s, vmm: qemu-coco-dev-runtime-rs, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: k3s, vmm: qemu-coco-dev, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: k3s, vmm: qemu-coco-dev, snapshotter: "", pull_type: experimental-force-guest-pull },
-          { k8s: k3s, vmm: qemu-coco-dev-runtime-rs, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: rke2, vmm: qemu-coco-dev, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: rke2, vmm: qemu-coco-dev, snapshotter: "", pull_type: experimental-force-guest-pull },
-          { k8s: rke2, vmm: qemu-coco-dev-runtime-rs, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: microk8s, vmm: qemu-coco-dev, snapshotter: nydus, pull_type: guest-pull },
-          { k8s: microk8s, vmm: qemu-coco-dev, snapshotter: "", pull_type: experimental-force-guest-pull },
-          { k8s: microk8s, vmm: qemu-coco-dev-runtime-rs, snapshotter: nydus, pull_type: guest-pull },
-        ]
-    runs-on: ubuntu-24.04
-    permissions:
-      contents: read
-    environment: ci
-    env:
-      DOCKER_REGISTRY: ${{ inputs.registry }}
-      DOCKER_REPO: ${{ inputs.repo }}
-      DOCKER_TAG: ${{ inputs.tag }}
-      GH_PR_NUMBER: ${{ inputs.pr-number }}
-      KATA_HYPERVISOR: ${{ matrix.environment.vmm }}
-      KBS: "true"
-      KBS_INGRESS: "nodeport"
-      KUBERNETES: ${{ matrix.environment.k8s }}
-      SNAPSHOTTER: ${{ matrix.environment.snapshotter }}
-      PULL_TYPE: ${{ matrix.environment.pull_type }}
-      EXPERIMENTAL_FORCE_GUEST_PULL: ${{ matrix.environment.pull_type == 'experimental-force-guest-pull' && matrix.environment.vmm || '' }}
-      AUTHENTICATED_IMAGE_USER: ${{ vars.AUTHENTICATED_IMAGE_USER }}
-      AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}
-      AUTO_GENERATE_POLICY: "yes"
-      K8S_TEST_HOST_TYPE: "all"
-      GH_TOKEN: ${{ github.token }}
-    steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-        with:
-          ref: ${{ inputs.commit-hash }}
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Rebase atop of the latest target branch
-        run: |
-          ./tests/git-helper.sh "rebase-atop-of-the-latest-target-branch"
-        env:
-          TARGET_BRANCH: ${{ inputs.target-branch }}
-
-      - name: get-kata-tools-tarball
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
-        with:
-          name: kata-tools-static-tarball-amd64${{ inputs.tarball-suffix }}
-          path: kata-tools-artifacts
-
-      - name: Install kata-tools
-        run: bash tests/integration/kubernetes/gha-run.sh install-kata-tools kata-tools-artifacts
-
-      - name: Remove unnecessary directories to free up space
-        run: |
-          sudo rm -rf /usr/local/.ghcup
-          sudo rm -rf /opt/hostedtoolcache/CodeQL
-          sudo rm -rf /usr/local/lib/android
-          sudo rm -rf /usr/share/dotnet
-          sudo rm -rf /opt/ghc
-          sudo rm -rf /usr/local/share/boost
-          sudo rm -rf /usr/lib/jvm
-          sudo rm -rf /usr/share/swift
-          sudo rm -rf /usr/local/share/powershell
-          sudo rm -rf /usr/local/julia*
-          sudo rm -rf /opt/az
-          sudo rm -rf /usr/local/share/chromium
-          sudo rm -rf /opt/microsoft
-          sudo rm -rf /opt/google
-          sudo rm -rf /usr/lib/firefox
-
-      - name: Deploy ${{ matrix.environment.k8s }}
-        timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-k8s
-
-      - name: Install `bats`
-        run: bash tests/integration/kubernetes/gha-run.sh install-bats
-
-      - name: Deploy Kata
-        timeout-minutes: 20
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-kata
-        env:
-          USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: ${{ matrix.environment.snapshotter == 'nydus' }}
-
-      - name: Deploy CoCo KBS
-        timeout-minutes: 10
-        run: bash tests/integration/kubernetes/gha-run.sh deploy-coco-kbs
-
-      - name: Install `kbs-client`
-        timeout-minutes: 10
-        run: bash tests/integration/kubernetes/gha-run.sh install-kbs-client
+      - name: Deploy CSI driver
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh deploy-csi-driver
 
       - name: Run tests
         timeout-minutes: 80
@@ -356,15 +252,18 @@ jobs:
         if: always()
         run: bash tests/integration/kubernetes/gha-run.sh report-tests
 
-      - name: Delete kata-deploy
+      - name: Refresh OIDC token in case access token expired
+        if: always()
+        uses: azure/login@a457da9ea143d694b1b9c7c869ebb04ebe844ef5 # v2.3.0
+        with:
+          client-id: ${{ secrets.AZ_APPID }}
+          tenant-id: ${{ secrets.AZ_TENANT_ID }}
+          subscription-id: ${{ secrets.AZ_SUBSCRIPTION_ID }}
+
+      - name: Delete AKS cluster
         if: always()
         timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh cleanup
-
-      - name: Delete CoCo KBS
-        if: always()
-        timeout-minutes: 10
-        run: bash tests/integration/kubernetes/gha-run.sh delete-coco-kbs
+        run: bash tests/integration/kubernetes/gha-run.sh delete-cluster
 
   # Generate jobs for testing CoCo on non-TEE environments with erofs-snapshotter
   run-k8s-tests-coco-nontee-with-erofs-snapshotter:
@@ -392,7 +291,7 @@ jobs:
       KBS_INGRESS: ""
       KUBERNETES: "vanilla"
       CONTAINER_ENGINE: "containerd"
-      CONTAINER_ENGINE_VERSION: "active"
+      CONTAINER_ENGINE_VERSION: "v2.2"
       PULL_TYPE: ${{ matrix.pull-type }}
       SNAPSHOTTER: ${{ matrix.snapshotter }}
       USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: "true"
@@ -400,7 +299,6 @@ jobs:
       # We are skipping the auto generated policy tests for now,
       # but those should be enabled as soon as we work on that.
       AUTO_GENERATE_POLICY: "no"
-      GH_TOKEN: ${{ github.token }}
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
@@ -444,6 +342,8 @@ jobs:
       - name: Deploy kubernetes
         timeout-minutes: 15
         run: bash tests/integration/kubernetes/gha-run.sh deploy-k8s
+        env:
+          GH_TOKEN: ${{ github.token }}
 
       - name: Install `bats`
         run: bash tests/integration/kubernetes/gha-run.sh install-bats
@@ -452,6 +352,10 @@ jobs:
         timeout-minutes: 20
         run: bash tests/integration/kubernetes/gha-run.sh deploy-kata
 
+      - name: Deploy CSI driver
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh deploy-csi-driver
+
       - name: Run tests
         timeout-minutes: 80
         run: bash tests/integration/kubernetes/gha-run.sh run-tests
@@ -459,8 +363,3 @@ jobs:
       - name: Report tests
         if: always()
         run: bash tests/integration/kubernetes/gha-run.sh report-tests
-
-      - name: Delete kata-deploy
-        if: always()
-        timeout-minutes: 15
-        run: bash tests/integration/kubernetes/gha-run.sh cleanup

.github/workflows/scorecard.yaml

@@ -55,6 +55,6 @@ jobs:
       # Upload the results to GitHub's code scanning dashboard (optional).
       # Commenting out will disable upload of results to your repo's Code Scanning dashboard
       - name: "Upload to code-scanning"
-        uses: github/codeql-action/upload-sarif@4bdb89f48054571735e3792627da6195c57459e2 # v3.31.10
+        uses: github/codeql-action/upload-sarif@v3
         with:
           sarif_file: results.sarif

.github/workflows/spellcheck.yaml

@@ -1,30 +0,0 @@
-name: Spelling check
-
-on: ["pull_request"]
-
-permissions: {}
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  check-spelling:
-    name: check-spelling
-    runs-on: ubuntu-24.04
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
-        with:
-          fetch-depth: 0
-          persist-credentials: false
-
-      - name: Check Spelling
-        uses: streetsidesoftware/cspell-action@9cd41bb518a24fefdafd9880cbab8f0ceba04d28  # 8.3.0
-        with:
-          files: |
-            **/*.md
-            **/*.rst
-            **/*.txt
-          incremental_files_only: true
-          config: ".cspell.yaml"

.github/workflows/static-checks.yaml

@@ -126,19 +126,14 @@ jobs:
           ./ci/install_yq.sh
         env:
           INSTALL_IN_GOPATH: false
-      - name: Read properties from versions.yaml
+      - name: Install golang
         run: |
           cd "${GOPATH}/src/github.com/${GITHUB_REPOSITORY}"
-          go_version="$(yq '.languages.golang.version' versions.yaml)"
-          [ -n "$go_version" ]
-          echo "GO_VERSION=${go_version}" >> "$GITHUB_ENV"
-      - name: Setup Golang version ${{ env.GO_VERSION }}
-        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
-        with:
-          go-version: ${{ env.GO_VERSION }}
+          ./tests/install_go.sh -f -p
+          echo "/usr/local/go/bin" >> "$GITHUB_PATH"
       - name: Install system dependencies
         run: |
-          sudo apt-get update && sudo apt-get -y install moreutils
+          sudo apt-get update && sudo apt-get -y install moreutils hunspell hunspell-en-gb hunspell-en-us pandoc
       - name: Install open-policy-agent
         run: |
           cd "${GOPATH}/src/github.com/${GITHUB_REPOSITORY}"

.gitignore

@@ -20,6 +20,3 @@ tools/packaging/static-build/agent/install_libseccomp.sh
 .direnv
 **/.DS_Store
 site/
-opt/
-tools/packaging/kernel/configs/**/.config
-root_hash.txt

Cargo.toml

@@ -6,12 +6,6 @@ rust-version = "1.88"
 
 [workspace]
 members = [
-  # kata-agent
-  "src/agent",
-  "src/agent/rustjail",
-  "src/agent/policy",
-  "src/agent/vsock-exporter",
-
   # Dragonball
   "src/dragonball",
   "src/dragonball/dbs_acpi",
@@ -28,9 +22,6 @@ members = [
   "src/dragonball/dbs_utils",
   "src/dragonball/dbs_virtio_devices",
 
-  # genpolicy
-  "src/tools/genpolicy",
-
   # runtime-rs
   "src/runtime-rs",
   "src/runtime-rs/crates/agent",
@@ -47,6 +38,7 @@ resolver = "2"
 
 # TODO: Add all excluded crates to root workspace
 exclude = [
+  "src/agent",
   "src/tools",
   "src/libs",
 
@@ -61,19 +53,19 @@ exclude = [
 
 [workspace.dependencies]
 # Rust-VMM crates
-event-manager = "0.4.0"
-kvm-bindings = "0.14.0"
-kvm-ioctls = "0.24.0"
-linux-loader = "0.13.0"
+event-manager = "0.2.1"
+kvm-bindings = "0.6.0"
+kvm-ioctls = "=0.12.1"
+linux-loader = "0.8.0"
 seccompiler = "0.5.0"
-vfio-bindings = "0.6.1"
-vfio-ioctls = "0.5.0"
-virtio-bindings = "0.2.0"
-virtio-queue = "0.17.0"
-vm-fdt = "0.3.0"
-vm-memory = "=0.17.1"
-vm-superio = "0.8.0"
-vmm-sys-util = "0.15.0"
+vfio-bindings = "0.3.0"
+vfio-ioctls = "0.1.0"
+virtio-bindings = "0.1.0"
+virtio-queue = "0.7.0"
+vm-fdt = "0.2.0"
+vm-memory = "0.10.0"
+vm-superio = "0.5.0"
+vmm-sys-util = "0.11.0"
 
 # Local dependencies from Dragonball Sandbox crates
 dragonball = { path = "src/dragonball" }
@@ -109,74 +101,40 @@ wasm_container = { path = "src/runtime-rs/crates/runtimes/wasm_container" }
 kata-sys-util = { path = "src/libs/kata-sys-util" }
 kata-types = { path = "src/libs/kata-types", features = ["safe-path"] }
 logging = { path = "src/libs/logging" }
-mem-agent = { path = "src/libs/mem-agent" }
 protocols = { path = "src/libs/protocols", features = ["async"] }
 runtime-spec = { path = "src/libs/runtime-spec" }
 safe-path = { path = "src/libs/safe-path" }
 shim-interface = { path = "src/libs/shim-interface" }
 test-utils = { path = "src/libs/test-utils" }
 
-# Local dependencies from `src/agent`
-kata-agent-policy = { path = "src/agent/policy" }
-rustjail = { path = "src/agent/rustjail" }
-vsock-exporter = { path = "src/agent/vsock-exporter" }
-
 # Outside dependencies
 actix-rt = "2.7.0"
 anyhow = "1.0"
-async-recursion = "0.3.2"
 async-trait = "0.1.48"
-capctl = "0.2.0"
-cfg-if = "1.0.0"
-cgroups = { package = "cgroups-rs", git = "https://github.com/kata-containers/cgroups-rs", rev = "v0.3.5" }
-clap = { version = "4.5.40", features = ["derive"] }
-const_format = "0.2.30"
 containerd-shim = { version = "0.10.0", features = ["async"] }
 containerd-shim-protos = { version = "0.10.0", features = ["async"] }
-derivative = "2.2.0"
-futures = "0.3.30"
 go-flag = "0.1.0"
 hyper = "0.14.20"
 hyperlocal = "0.8.0"
-ipnetwork = "0.17.0"
 lazy_static = "1.4"
-libc = "0.2.94"
+libc = "0.2"
 log = "0.4.14"
-netlink-packet-core = "0.7.0"
-netlink-packet-route = "0.19.0"
-netlink-sys = { version = "0.7.0", features = ["tokio_socket"] }
 netns-rs = "0.1.0"
 # Note: nix needs to stay sync'd with libs versions
 nix = "0.26.4"
 oci-spec = { version = "0.8.1", features = ["runtime"] }
-opentelemetry = { version = "0.17.0", features = ["rt-tokio"] }
-procfs = "0.12.0"
-prometheus = { version = "0.14.0", features = ["process"] }
 protobuf = "3.7.2"
 rand = "0.8.4"
-regex = "1.10.5"
-rstest = "0.18.0"
-rtnetlink = "0.14.0"
-scan_fmt = "0.2.6"
-scopeguard = "1.0.0"
 serde = { version = "1.0.145", features = ["derive"] }
 serde_json = "1.0.91"
-serial_test = "0.10.0"
 sha2 = "0.10.9"
 slog = "2.5.2"
 slog-scope = "4.4.0"
-slog-stdlog = "4.0.0"
-slog-term = "2.9.0"
 strum = { version = "0.24.0", features = ["derive"] }
-strum_macros = "0.26.2"
 tempfile = "3.19.1"
-thiserror = "1.0.26"
+thiserror = "1.0"
 tokio = "1.46.1"
-tokio-vsock = "0.3.4"
-toml = "0.5.8"
 tracing = "0.1.41"
 tracing-opentelemetry = "0.18.0"
-tracing-subscriber = "0.3.20"
 ttrpc = "0.8.4"
 url = "2.5.4"
-which = "4.3.0"

Makefile

@@ -47,13 +47,10 @@ docs-url-alive-check:
 	bash ci/docs-url-alive-check.sh
 
 build-and-publish-kata-debug:
-	bash tools/packaging/kata-debug/kata-debug-build-and-upload-payload.sh ${KATA_DEBUG_REGISTRY} ${KATA_DEBUG_TAG}
+	bash tools/packaging/kata-debug/kata-debug-build-and-upload-payload.sh ${KATA_DEBUG_REGISTRY} ${KATA_DEBUG_TAG} 
 
-docs-build:
-	docker build -t kata-docs:latest -f ./docs/Dockerfile ./docs
-
-docs-serve: docs-build
-	docker run --rm -p 8000:8000 -v ${PWD}:/docs:ro kata-docs:latest serve --config-file /docs/mkdocs.yaml -a 0.0.0.0:8000
+docs-serve:
+	docker run --rm -p 8000:8000 -v ./docs:/docs:ro -v ${PWD}/zensical.toml:/zensical.toml:ro zensical/zensical serve --config-file /zensical.toml -a 0.0.0.0:8000 
 
 .PHONY: \
 	all \
@@ -62,5 +59,4 @@ docs-serve: docs-build
 	default \
 	static-checks \
 	docs-url-alive-check \
-	docs-build \
 	docs-serve

README.md

@@ -74,7 +74,7 @@ See the [official documentation](docs) including:
 - [Developer guide](docs/Developer-Guide.md)
 - [Design documents](docs/design)
   - [Architecture overview](docs/design/architecture)
-  - [Architecture 4.0 overview](docs/design/architecture_4.0/)
+  - [Architecture 3.0 overview](docs/design/architecture_3.0/)
 
 ## Configuration
 

VERSION

@@ -1 +1 @@
-3.28.0
+3.26.0

ci/README.md

@@ -378,7 +378,7 @@ that is used in the test" section.  From there you can see exactly what you'll
 have to use when deploying kata-deploy in your local cluster.
 
 > [!NOTE]
-> TODO: @wainersm TO FINISH THIS PART BASED ON HIS PR TO RUN A LOCAL CI
+> TODO: WAINER TO FINISH THIS PART BASED ON HIS PR TO RUN A LOCAL CI
 
 ## Adding new runners
 

ci/install_yq.sh

@@ -73,12 +73,12 @@ function install_yq() {
 		goarch=arm64
 		;;
 	"arm64")
-		# If we're on an apple silicon machine, just assign amd64.
-		# The version of yq we use doesn't have a darwin arm build,
+		# If we're on an apple silicon machine, just assign amd64. 
+		# The version of yq we use doesn't have a darwin arm build, 
 		# but Rosetta can come to the rescue here.
 		if [[ ${goos} == "Darwin" ]]; then
 			goarch=amd64
-		else
+		else 
 			goarch=arm64
 		fi
 		;;

ci/openshift-ci/README.md

@@ -98,7 +98,7 @@ Let's say the OCP pipeline passed running with
 but failed running with
 ``quay.io/kata-containers/kata-deploy-ci:kata-containers-9f512c016e75599a4a921bd84ea47559fe610057-amd64``
 and you'd like to know which PR caused the regression. You can either run with
-all the 60 tags between or you can utilize the [`bisecter`](https://github.com/ldoktor/bisecter)
+all the 60 tags between or you can utilize the [bisecter](https://github.com/ldoktor/bisecter)
 to optimize the number of steps in between.
 
 Before running the bisection you need a reproducer script. Sample one called

docs/.nav.yml

@@ -1,18 +0,0 @@
-# https://lukasgeiter.github.io/mkdocs-awesome-nav/
-nav:
-  - Home: index.md
-  - Getting Started:
-    - prerequisites.md
-    - installation.md
-    - Configuration:
-        - helm-configuration.md
-        - runtime-configuration.md
-  - Platform Support:
-    - hypervisors.md
-  - Guides:
-    - Use Cases:
-      - NVIDIA GPU Passthrough: use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md
-      - NVIDIA vGPU: use-cases/NVIDIA-GPU-passthrough-and-Kata.md
-      - Intel Discrete GPU: use-cases/Intel-Discrete-GPU-passthrough-and-Kata.md
-  - Misc:
-    - Architecture: design/architecture/

docs/Blog-Post-Submission-Guide.md

@@ -83,4 +83,4 @@ files to the repository and create a pull request when you are ready.
 
 If you have an idea for a blog post and would like to get feedback from the
 community about it or have any questions about the process, please reach out
-on one of the community's [communication channels](https://katacontainers.io/community/).
+on one of the community's [communication channels](https://katacontainers.io/community/).

docs/Developer-Guide.md

@@ -289,14 +289,14 @@ provided by your distribution.
 
 As a prerequisite, you need to install Docker. Otherwise, you will not be
 able to run the `rootfs.sh` script with `USE_DOCKER=true` as expected in
-the following example. Specifying the `OS_VERSION` is required when using `distro="ubuntu"`.
+the following example.
 
 ```bash
 $ export distro="ubuntu" # example
 $ export ROOTFS_DIR="$(realpath kata-containers/tools/osbuilder/rootfs-builder/rootfs)"
 $ sudo rm -rf "${ROOTFS_DIR}"
 $ pushd kata-containers/tools/osbuilder/rootfs-builder
-$ script -fec 'sudo -E USE_DOCKER=true OS_VERSION=noble ./rootfs.sh "${distro}"'
+$ script -fec 'sudo -E USE_DOCKER=true ./rootfs.sh "${distro}"'
 $ popd
 ```
 
@@ -522,18 +522,10 @@ $ sudo kata-runtime check
 If your system is *not* able to run Kata Containers, the previous command will error out and explain why.
 
 # Run Kata Containers with Containerd
-
 Refer to the [How to use Kata Containers and Containerd](how-to/containerd-kata.md) how-to guide.
 
 # Run Kata Containers with Kubernetes
-
-- Containerd
-
-Refer to the [How to use Kata Containers and Containerd with Kubernetes](how-to/how-to-use-k8s-with-containerd-and-kata.md) how-to guide.
-
-- CRI-O
-
-Refer to the [How to use Kata Containers and CRI-O with Kubernetes](how-to/how-to-use-k8s-with-crio-and-kata.md) how-to guide.
+Refer to the [Run Kata Containers with Kubernetes](how-to/run-kata-with-k8s.md) how-to guide.
 
 # Troubleshoot Kata Containers
 
@@ -738,7 +730,7 @@ sudo sed -i -e 's/^kernel_params = "\(.*\)"/kernel_params = "\1 agent.debug_cons
 
 ##### Connecting to the debug console
 
-Next, connect to the debug console. The VSOCK paths vary slightly between each
+Next, connect to the debug console. The VSOCKS paths vary slightly between each
 VMM solution.
 
 In case of cloud-hypervisor, connect to the `vsock` as shown:

docs/Dockerfile

@@ -1,11 +0,0 @@
-# Copyright 2026 Kata Contributors
-#
-# SPDX-License-Identifier: Apache-2.0
-#
-FROM python:3.12-slim
-
-WORKDIR /
-COPY ./requirements.txt requirements.txt
-RUN pip install --no-cache-dir -r requirements.txt
-
-ENTRYPOINT ["python3", "-m", "mkdocs"]

docs/Documentation-Requirements.md

@@ -188,14 +188,15 @@ and compare them with standard tools (e.g. `diff(1)`).
 # Spelling
 
 Since this project uses a number of terms not found in conventional
-dictionaries, we have a [kata-dictionary](../tests/spellcheck/kata-dictionary.txt)
-that contains some project specific terms we use.
+dictionaries, we have a
+[spell checking tool](https://github.com/kata-containers/kata-containers/tree/main/tests/cmd/check-spelling)
+that checks both dictionary words and the additional terms we use.
 
-You can run the `cspell` checking tool on your document before raising a PR to ensure it
+Run the spell checking tool on your document before raising a PR to ensure it
 is free of mistakes.
 
 If your document introduces new terms, you need to update the custom
-dictionary to incorporate the new words.
+dictionary used by the spell checking tool to incorporate the new words.
 
 # Names
 

docs/Limitations.md

@@ -187,10 +187,9 @@ different compared to `runc` containers:
 into the guest and exposes it directly to the container.
 
 **Mounting guest devices**: When the source path of a hostPath volume is
-under `/dev` (or `/dev` itself), and the path corresponds to a
-non-regular file (i.e., a device, directory, or any other special file)
-or is not accessible by the Kata shim, the Kata agent bind mounts the
-source path directly from the *guest* filesystem into the container.
+under `/dev`, and the path either corresponds to a host device or is not
+accessible by the Kata shim, the Kata agent bind mounts the source path
+directly from the *guest* filesystem into the container.
 
 [runtime-config]: /src/runtime/README.md#configuration
 [k8s-hostpath]: https://kubernetes.io/docs/concepts/storage/volumes/#hostpath
@@ -207,7 +206,7 @@ For security reasons, the following mounts are disallowed:
 | `proc \|\| sysfs` | `*`       | not a directory (e.g. symlink)   | CVE-2019-19921 |
 
 For bind mounts under /proc, these destinations are allowed:
-
+	
  * `/proc/cpuinfo`
  * `/proc/diskstats`
  * `/proc/meminfo`
@@ -227,35 +226,6 @@ Importantly, the default behavior to pass the host devices to a
 privileged container is not supported in Kata Containers and needs to be
 disabled, see [Privileged Kata Containers](how-to/privileged.md).
 
-## Guest pulled container images
-
-When using features like **nydus guest-pull**, set user/group IDs explicitly in the pod spec.
-If the ID values are omitted:
-
-- Your workload might be executed with unexpected user/group ID values, because image layers
-  may be unavailable to containerd, so image config (including user/group) is not applied.
-- If using policy or genpolicy, the generated policy may detect these unexpected values and
-  reject the creation of workload containers.
-
-Set `securityContext` explicitly. Use **pod-level** `spec.securityContext` (for Pods) or
-`spec.template.spec.securityContext` (for controllers like Deployments) and/or **container-level**
-`spec.containers[].securityContext`. Include at least:
-- `runAsUser` — primary user ID
-- `runAsGroup` — primary group ID
-- `fsGroup` — volume group ownership (often reflected as a supplemental group)
-- `supplementalGroups` — list of additional group IDs (if needed)
-
-Example:
-
- ```yaml
- # Explicit user/group/supplementary groups to support nydus guest-pull
- securityContext:
-   runAsUser: 0
-   runAsGroup: 0
-   fsGroup: 0
-   supplementalGroups: [1, 2, 3, 4, 6, 10, 11, 20, 26, 27]
- ```
-
 # Appendices
 
 ## The constraints challenge

docs/Release-Process.md

@@ -1,69 +1,59 @@
 # How to do a Kata Containers Release
-
 This document lists the tasks required to create a Kata Release.
 
 ## Requirements
 
 - GitHub permissions to run workflows.
 
-## Release Model
+## Versioning
 
-Kata Containers follows a rolling release model with monthly snapshots.
-New features, bug fixes, and improvements are continuously integrated into
-`main`. Each month, a snapshot is tagged as a new `MINOR` release.
+The Kata Containers project uses [semantic versioning](http://semver.org/) for all releases.
+Semantic versions are comprised of three fields in the form:
 
-### Versioning
+```
+MAJOR.MINOR.PATCH
+```
 
-Releases use the `MAJOR.MINOR.PATCH` scheme. Monthly snapshots increment
-`MINOR`; `PATCH` is typically `0`. Major releases are rare (years apart) and
-signal significant architectural changes that may require updates to container
-managers (Containerd, CRI-O) or other infrastructure. Breaking changes in
-`MINOR` releases are avoided where possible, but may occasionally occur as
-features are deprecated or removed.
+When `MINOR` increases, the new release adds **new features** but *without changing the existing behavior*.
 
-### No Stable Branches
+When `MAJOR` increases, the new release adds **new features, bug fixes, or
+both** and which **changes the behavior from the previous release** (incompatible with previous releases).
 
-The Kata Containers project does not maintain stable branches (see
-[#9064](https://github.com/kata-containers/kata-containers/issues/9064)).
-Bug fixes land on `main` and ship in the next monthly snapshot rather than
-being backported. Downstream projects that need extended support or compliance
-certifications should select a monthly snapshot as their stable base and manage
-their own validation and patch backporting from there.
+A major release will also likely require a change of the container manager version used,
+-for example Containerd or CRI-O. Please refer to the release notes for further details.
+
+**Important** : the Kata Containers project doesn't have stable branches (see
+[this issue](https://github.com/kata-containers/kata-containers/issues/9064) for details).
+Bug fixes are released as part of `MINOR` or `MAJOR` releases only. `PATCH` is always `0`.
 
 ## Release Process
 
-### Lock the `main` branch and announce release process
-
-In order to prevent any PRs getting merged during the release process, and
-slowing the release process down, by impacting the payload caches, we have
-recently trialed setting the `main` branch to read-only.
-Once the `kata-containers/kata-containers` repository is ready for a new
-release, lock the main branch until the release action has completed.
-Notify the #kata-dev Slack channel about the ongoing release process.
-Ideally, CI usage by others should be reduced to a minimum during the
-ongoing release process.
-
-> [!NOTE]
-> Admin permission is needed to lock/unlock the `main` branch.
-
 ### Bump the `VERSION` and `Chart.yaml` file
 
-Create a PR to set the release in the [`VERSION`](./../VERSION) file and to
-update the `version` and `appVersion` fields in the
-[`Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-deploy/Chart.yaml)
-file. Temporarily unlock the main branch to merge the PR.
+When the `kata-containers/kata-containers` repository is ready for a new release,
+first create a PR to set the release in the [`VERSION`](./../VERSION) file and update the
+`version` and `appVersion` in the
+[`Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-deploy/Chart.yaml) file and
+have it merged.
+
+### Lock the `main` branch
+
+In order to prevent any PRs getting merged during the release process, and slowing the release
+process down, by impacting the payload caches, we have recently trailed setting the `main`
+branch to read only whilst the release action runs.
+
+> [!NOTE]
+> Admin permission is needed to complete this task.
 
 ### Wait for the `VERSION` bump PR payload publish to complete
 
-To reduce the chance of need to re-run the release workflow, check the [CI |
-Publish Kata Containers
-payload](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml)
+To reduce the chance of need to re-run the release workflow, check the
+[CI | Publish Kata Containers payload](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml)
 once the `VERSION` PR bump has merged to check that the assets build correctly
 and are cached, so that the release process can just download these artifacts
-rather than needing to build them all, which takes time and can reveal errors in
-infra.
+rather than needing to build them all, which takes time and can reveal errors in infra.
 
-### Trigger the `Release Kata Containers` GitHub Action
+### Check GitHub Actions
 
 We make use of [GitHub actions](https://github.com/features/actions) in the
 [release](https://github.com/kata-containers/kata-containers/actions/workflows/release.yaml)
@@ -73,10 +63,11 @@ release artifacts.
 > [!NOTE]
 > Write permissions to trigger the action.
 
-The action is manually triggered and is responsible for generating a new release
-(including a new tag), pushing those to the `kata-containers/kata-containers`
-repository. The new release is initially created as a draft. It is promoted to
-an official release when the whole workflow has completed successfully.
+The action is manually triggered and is responsible for generating a new
+release (including a new tag), pushing those to the
+`kata-containers/kata-containers` repository. The new release is initially
+created as a draft. It is promoted to an official release when the whole
+workflow has completed successfully.
 
 Check the [actions status
 page](https://github.com/kata-containers/kata-containers/actions) to verify all
@@ -84,13 +75,12 @@ steps in the actions workflow have completed successfully. On success, a static
 tarball containing Kata release artifacts will be uploaded to the [Release
 page](https://github.com/kata-containers/kata-containers/releases).
 
-If the workflow fails because of some external environmental causes, e.g.
-network timeout, simply re-run the failed jobs until they eventually succeed.
+If the workflow fails because of some external environmental causes, e.g. network
+timeout, simply re-run the failed jobs until they eventually succeed.
 
-If for some reason you need to cancel the workflow or re-run it entirely, go
-first to the [Release
-page](https://github.com/kata-containers/kata-containers/releases) and delete
-the draft release from the previous run.
+If for some reason you need to cancel the workflow or re-run it entirely, go first
+to the [Release page](https://github.com/kata-containers/kata-containers/releases) and
+delete the draft release from the previous run.
 
 ### Unlock the `main` branch
 
@@ -100,8 +90,9 @@ an admin to do it.
 ### Improve the release notes
 
 Release notes are auto-generated by the GitHub CLI tool used as part of our
-release workflow.  However, some manual tweaking may still be necessary in order
-to highlight the most important features and bug fixes in a specific release.
+release workflow.  However, some manual tweaking may still be necessary in
+order to highlight the most important features and bug fixes in a specific
+release.
 
 With this in mind, please, poke @channel on #kata-dev and people who worked on
 the release will be able to contribute to that.

docs/code-pr-advice.md

@@ -231,6 +231,12 @@ Run the
 [markdown checker](https://github.com/kata-containers/kata-containers/tree/main/tests/cmd/check-markdown)
 on your documentation changes.
 
+### Spell check
+
+Run the
+[spell checker](https://github.com/kata-containers/kata-containers/tree/main/tests/cmd/check-spelling)
+on your documentation changes.
+
 ## Finally
 
 You may wish to read the documentation that the

docs/design/agent-systemd-cgroup.md

@@ -4,7 +4,7 @@ As we know, we can interact with cgroups in two ways, **`cgroupfs`** and **`syst
 
 ## usage
 
-For systemd, kata agent configures cgroups according to the following `linux.cgroupsPath` format standard provided by `runc` (`[slice]:[prefix]:[name]`). If you don't provide a valid `linux.cgroupsPath`, kata agent will treat it as `"system.slice:kata_agent:<container-id>"`.
+For systemd, kata agent configures cgroups according to the following `linux.cgroupsPath` format standard provided by `runc` (`[slice]:[prefix]:[name]`). If you don't provide a valid `linux.cgroupsPath`, kata agent will treat it as `"system.slice:kata_agent:<container-id>"`. 
 
 > Here slice is a systemd slice under which the container is placed. If empty, it defaults to system.slice, except when cgroup v2 is used and rootless container is created, in which case it defaults to user.slice.
 >
@@ -65,7 +65,7 @@ The kata agent will translate the parameters in the `linux.resources` of `config
 
 ## Systemd Interface
 
-`session.rs` and `system.rs` in `src/agent/rustjail/src/cgroups/systemd/interface` are automatically generated by `zbus-xmlgen`, which is is an accompanying tool provided by `zbus` to generate Rust code from `D-Bus XML interface descriptions`. The specific commands to generate these two files are as follows:
+`session.rs` and `system.rs` in `src/agent/rustjail/src/cgroups/systemd/interface` are automatically generated by `zbus-xmlgen`, which is is an accompanying tool provided by `zbus` to generate Rust code from `D-Bus XML interface descriptions`. The specific commands to generate these two files are as follows: 
 
 ```shell
 // system.rs

docs/design/arch-images/kata-oci-exec.txt

@@ -10,7 +10,7 @@ participant proxy
 #Docker Exec
 Docker->kata-runtime: exec
 kata-runtime->virtcontainers: EnterContainer()
-virtcontainers->agent: exec
+virtcontainers->agent: exec 
 agent->virtcontainers: Process started in the container
 virtcontainers->shim: start shim
 shim->agent: ReadStdout()

docs/design/architecture/README.md

@@ -322,7 +322,7 @@ The runtime is responsible for starting the [hypervisor](#hypervisor)
 and it's VM, and communicating with the [agent](#agent) using a
 [ttRPC based protocol](#agent-communications-protocol) over a VSOCK
 socket that provides a communications link between the VM and the
-host.
+host. 
 
 This protocol allows the runtime to send container management commands
 to the agent. The protocol is also used to carry the standard I/O

docs/design/architecture/kubernetes.md

@@ -32,4 +32,4 @@ runtime. Refer to the following guides on how to set up Kata
 Containers with Kubernetes:
 
 - [How to use Kata Containers and containerd](../../how-to/containerd-kata.md)
-- [Run Kata Containers with Kubernetes](../../how-to/how-to-use-k8s-with-crio-and-kata.md)
+- [Run Kata Containers with Kubernetes](../../how-to/run-kata-with-k8s.md)

docs/design/architecture/networking.md

@@ -4,15 +4,15 @@ Containers typically live in their own, possibly shared, networking namespace.
 At some point in a container lifecycle, container engines will set up that namespace
 to add the container to a network which is isolated from the host network.
 
-In order to setup the network for a container, container engines call into a
+In order to setup the network for a container, container engines call into a 
 networking plugin. The network plugin will usually create a virtual
-ethernet (`veth`) pair adding one end of the `veth` pair into the container
-networking namespace, while the other end of the `veth` pair is added to the
+ethernet (`veth`) pair adding one end of the `veth` pair into the container 
+networking namespace, while the other end of the `veth` pair is added to the 
 host networking namespace.
 
 This is a very namespace-centric approach as many hypervisors or VM
 Managers (VMMs) such as `virt-manager` cannot handle `veth`
-interfaces. Typically, [`TAP`](https://www.kernel.org/doc/Documentation/networking/tuntap.txt)
+interfaces. Typically, [`TAP`](https://www.kernel.org/doc/Documentation/networking/tuntap.txt) 
 interfaces are created for VM connectivity.
 
 To overcome incompatibility between typical container engines expectations
@@ -22,15 +22,15 @@ interfaces with `TAP` ones using [Traffic Control](https://man7.org/linux/man-pa
 ![Kata Containers networking](../arch-images/network.png)
 
 With a TC filter rules in place, a redirection is created between the container network
- and the virtual machine. As an example, the network plugin may place a device,
-`eth0`, in the container's network namespace, which is one end of a VETH device.
+ and the virtual machine. As an example, the network plugin may place a device, 
+`eth0`, in the container's network namespace, which is one end of a VETH device. 
 Kata Containers will create a tap device for the VM, `tap0_kata`,
 and setup a TC redirection filter to redirect traffic from `eth0`'s ingress to `tap0_kata`'s egress,
 and a second TC filter to redirect traffic from `tap0_kata`'s ingress to `eth0`'s egress.
 
-Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata.
-With this method, Kata created a MACVTAP device to connect directly to the `eth0` device.
-TC-filter is the default because it allows for simpler configuration, better CNI plugin
+Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata. 
+With this method, Kata created a MACVTAP device to connect directly to the `eth0` device. 
+TC-filter is the default because it allows for simpler configuration, better CNI plugin 
 compatibility, and performance on par with MACVTAP.
 
 Kata Containers has deprecated support for bridge due to lacking performance relative to TC-filter and MACVTAP.

docs/design/architecture_3.0/README.md

@@ -0,0 +1,168 @@
+# Kata 3.0 Architecture
+## Overview
+In cloud-native scenarios, there is an increased demand for container startup speed, resource consumption, stability, and security, areas where the present Kata Containers runtime is challenged relative to other runtimes. To achieve this, we propose a solid, field-tested and secure Rust version of the kata-runtime.
+
+Also, we provide the following designs:
+
+- Turn key solution with builtin `Dragonball` Sandbox
+- Async I/O to reduce resource consumption
+- Extensible framework for multiple services, runtimes and hypervisors
+- Lifecycle management for sandbox and container associated resources
+
+### Rationale for choosing Rust
+
+We chose Rust because it is designed as a system language with a focus on efficiency.
+In contrast to Go, Rust makes a variety of design trade-offs in order to obtain
+good execution performance, with innovative techniques that, in contrast to C or
+C++, provide reasonable protection against common memory errors (buffer
+overflow, invalid pointers, range errors), error checking (ensuring errors are
+dealt with), thread safety, ownership of resources, and more.
+
+These benefits were verified in our project when the Kata Containers guest agent
+was rewritten in Rust. We notably saw a significant reduction in memory usage
+with the Rust-based implementation.
+
+
+## Design
+### Architecture
+![architecture](./images/architecture.png)
+### Built-in VMM
+#### Current Kata 2.x architecture
+![not_builtin_vmm](./images/not_built_in_vmm.png)
+As shown in the figure, runtime and VMM are separate processes. The runtime process forks the VMM process and interacts through the inter-process RPC. Typically, process interaction consumes more resources than peers within the process, and it will result in relatively low efficiency. At the same time, the cost of resource operation and maintenance should be considered. For example, when performing resource recovery under abnormal conditions, the exception of any process must be detected by others and activate the appropriate resource recovery process. If there are additional processes, the recovery becomes even more difficult.
+#### How To Support Built-in VMM
+We provide `Dragonball` Sandbox to enable built-in VMM by integrating VMM's function into the Rust library. We could perform VMM-related functionalities by using the library. Because runtime and VMM  are in the same process, there is a benefit in terms of message processing speed and API synchronization. It can also guarantee the consistency of the runtime and the VMM life cycle, reducing resource recovery and exception handling maintenance, as shown in the figure:
+![builtin_vmm](./images/built_in_vmm.png)
+### Async Support
+#### Why Need Async
+**Async is already in stable Rust and allows us to write async code**
+
+- Async provides significantly reduced CPU and memory overhead, especially for workloads with a large amount of IO-bound tasks
+- Async is zero-cost in Rust, which means that you only pay for what you use. Specifically, you can use async without heap allocations and dynamic dispatch, which greatly improves efficiency
+- For more (see [Why Async?](https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html) and [The State of Asynchronous Rust](https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html)).
+
+**There may be several problems if implementing kata-runtime with Sync Rust**
+
+- Too many threads with a new TTRPC connection
+   - TTRPC threads: reaper thread(1) + listener thread(1) + client handler(2)
+- Add 3 I/O threads with a new container
+- In Sync mode, implementing a timeout mechanism is challenging. For example, in TTRPC API interaction, the timeout mechanism is difficult to align with Golang
+#### How To Support Async
+The kata-runtime is controlled by TOKIO_RUNTIME_WORKER_THREADS to run the OS thread, which is 2 threads by default. For TTRPC and container-related threads run in the `tokio` thread in a unified manner, and related dependencies need to be switched to Async, such as Timer, File, Netlink, etc. With the help of Async, we can easily support no-block I/O and timer. Currently, we only utilize Async for kata-runtime. The built-in VMM keeps the OS thread because it can ensure that the threads are controllable.
+
+**For N `tokio` worker threads and M containers**
+
+- Sync runtime(both OS thread and `tokio` task are OS thread but without `tokio` worker thread)  OS thread number:  4 + 12*M
+- Async runtime(only OS thread is OS thread) OS thread number: 2 + N
+```shell
+├─ main(OS thread)
+├─ async-logger(OS thread)
+└─ tokio worker(N * OS thread)
+  ├─ agent log forwarder(1 * tokio task)
+  ├─ health check thread(1 * tokio task)
+  ├─ TTRPC reaper thread(M * tokio task)
+  ├─ TTRPC listener thread(M * tokio task)
+  ├─ TTRPC client handler thread(7 * M * tokio task)
+  ├─ container stdin io thread(M * tokio task)
+  ├─ container stdout io thread(M * tokio task)
+  └─ container stderr io thread(M * tokio task)
+```
+### Extensible Framework
+The Kata 3.x runtime is designed with the extension of service, runtime, and hypervisor, combined with configuration to meet the needs of different scenarios. At present, the service provides a register mechanism to support multiple services. Services could interact with runtime through messages. In addition, the runtime handler handles messages from services. To meet the needs of a binary that supports multiple runtimes and hypervisors, the startup must obtain the runtime handler type and hypervisor type through configuration.
+
+![framework](./images/framework.png)
+### Resource Manager
+In our case, there will be a variety of resources, and every resource has several subtypes. Especially for `Virt-Container`, every subtype of resource has different operations. And there may be dependencies, such as the share-fs rootfs and the share-fs volume will use share-fs resources to share files to the VM. Currently, network and share-fs are regarded as sandbox resources, while rootfs, volume, and cgroup are regarded as container resources. Also, we abstract a common interface for each resource and use subclass operations to evaluate the differences between different subtypes.
+![resource manager](./images/resourceManager.png)
+
+## Roadmap
+
+- Stage 1 (June): provide basic features (current delivered)
+- Stage 2 (September): support common features
+- Stage 3: support full features
+
+| **Class**                  | **Sub-Class**       | **Development Stage** | **Status** |
+| -------------------------- | ------------------- | --------------------- |------------|
+| Service                    | task service        | Stage 1               |  ✅        |
+|                            | extend service      | Stage 3               |  🚫        |
+|                            | image service       | Stage 3               |  🚫        |
+| Runtime handler            | `Virt-Container`    | Stage 1               |  ✅        |
+| Endpoint                   | VETH Endpoint       | Stage 1               |  ✅        |
+|                            | Physical Endpoint   | Stage 2               |  ✅        |
+|                            | Tap Endpoint        | Stage 2               |  ✅        |
+|                            | `Tuntap` Endpoint   | Stage 2               |  ✅        |
+|                            | `IPVlan` Endpoint   | Stage 2               |  ✅        |
+|                            | `MacVlan` Endpoint  | Stage 2               |  ✅        |
+|                            | MACVTAP Endpoint    | Stage 3               |  🚫        |
+|                            | `VhostUserEndpoint` | Stage 3               |  🚫        |
+| Network Interworking Model | Tc filter           | Stage 1               |  ✅        |
+|                            | `MacVtap`           | Stage 3               |  🚧        |
+| Storage                    | Virtio-fs           | Stage 1               |  ✅        |
+|                            | `nydus`             | Stage 2               |  🚧        |
+|                            | `device mapper`     | Stage 2               |  🚫        |
+| `Cgroup V2`                |                     | Stage 2               |  🚧        |
+| Hypervisor                 | `Dragonball`        | Stage 1               |  🚧        |
+|                            | QEMU                | Stage 2               |  🚫        |
+|                            | Cloud Hypervisor    | Stage 3               |  🚫        |
+|                            | Firecracker         | Stage 3               |  🚫        |
+
+## FAQ
+
+- Are the "service", "message dispatcher" and "runtime handler" all part of the single Kata 3.x runtime binary?
+
+  Yes. They are components in Kata 3.x runtime. And they will be packed into one binary.
+  1. Service is an interface, which is responsible for handling multiple services like task service, image service and etc. 
+  2. Message dispatcher, it is used to match multiple requests from the service module. 
+  3. Runtime handler is used to deal with the operation for sandbox and container. 
+- What is the name of the Kata 3.x runtime binary?
+  
+  Apparently we can't use `containerd-shim-v2-kata` because it's already used. We are facing the hardest issue of "naming" again. Any suggestions are welcomed.
+  Internally we use `containerd-shim-v2-rund`.
+
+- Is the Kata 3.x design compatible with the containerd shimv2 architecture? 
+  
+  Yes. It is designed to follow the functionality of go version kata.  And it implements the `containerd shim v2` interface/protocol.
+
+- How will users migrate to the Kata 3.x architecture?
+  
+  The migration plan will be provided before the Kata 3.x is merging into the main branch.
+
+- Is `Dragonball` limited to its own built-in VMM? Can the `Dragonball` system be configured to work using an external `Dragonball` VMM/hypervisor?
+
+  The `Dragonball` could work as an external hypervisor. However, stability and performance is challenging in this case. Built in VMM could optimise the container overhead, and it's easy to maintain stability.
+
+  `runD` is the `containerd-shim-v2` counterpart of `runC` and can run a pod/containers. `Dragonball` is a `microvm`/VMM that is designed to run container workloads. Instead of `microvm`/VMM, we sometimes refer to it as secure sandbox.
+
+- QEMU, Cloud Hypervisor and Firecracker support are planned, but how that would work. Are they working in separate process?
+ 
+  Yes. They are unable to work as built in VMM.
+
+- What is `upcall`?
+  
+    The `upcall` is used to hotplug CPU/memory/MMIO devices, and it solves two issues.
+    1. avoid dependency on PCI/ACPI
+    2. avoid dependency on `udevd` within guest and get deterministic results for hotplug operations. So `upcall` is an alternative to ACPI based CPU/memory/device hotplug. And we may cooperate with the community to add support for ACPI based CPU/memory/device hotplug if needed.
+   
+    `Dbs-upcall` is a `vsock-based` direct communication tool between VMM and guests. The server side of the `upcall` is a driver in guest kernel (kernel patches are needed for this feature) and it'll start to serve the requests once the kernel has started. And the client side is in VMM , it'll be a thread that communicates with VSOCK through `uds`. We have accomplished device hotplug / hot-unplug directly through `upcall` in order to avoid virtualization of ACPI  to minimize virtual machine's overhead. And there could be many other usage through this direct communication channel. It's already open source.
+   https://github.com/openanolis/dragonball-sandbox/tree/main/crates/dbs-upcall 
+
+- The URL below says the kernel patches work with 4.19, but do they also work with 5.15+ ?
+  
+  Forward compatibility should be achievable, we have ported it to 5.10 based kernel.
+
+- Are these patches platform-specific or would they work for any architecture that supports VSOCK?
+  
+  It's almost platform independent, but some message related to CPU hotplug are platform dependent.
+
+- Could the kernel driver be replaced with a userland daemon in the guest using loopback VSOCK?
+  
+  We need to create device nodes for hot-added CPU/memory/devices, so it's not easy for userspace daemon to do these tasks.
+
+- The fact that `upcall` allows communication between the VMM and the guest suggests that this architecture might be incompatible with https://github.com/confidential-containers where the VMM should have no knowledge of what happens inside the VM.
+  
+  1. `TDX` doesn't support CPU/memory hotplug yet.
+  2. For ACPI based device hotplug, it depends on ACPI `DSDT` table, and the guest kernel will execute `ASL` code to handle during handling those hotplug event. And it should be easier to audit VSOCK based communication than ACPI `ASL` methods.
+
+- What is the security boundary for the monolithic / "Built-in VMM" case?
+  
+  It has the security boundary of virtualization. More details will be provided in next stage.

docs/design/architecture_4.0/README.md

@@ -1,433 +0,0 @@
-# Kata Containers 4.0 Architecture (Rust Runtime)
-
-## Overview
-
-Kata Containers 4.0 represents a significant architectural evolution, moving beyond the limitations of legacy multi-process container runtimes. Driven by a modern Rust-based stack, this release transitions to an asynchronous, unified architecture that drastically reduces resource consumption and latency.
-
-By consolidating the entire runtime into a single, high-performance binary, Kata 4.0 eliminates the overhead of cross-process communication and streamlines the container lifecycle. The result is a secure, production-tested runtime capable of handling high-density workloads with efficiency. With built-in support for diverse container abstractions and optimized hypervisor integration, Kata 4.0 delivers the agility and robustness required by modern, cloud-native infrastructure.
-
----
-
-## 1. Architecture Overview
-
-The Kata Containers Rust Runtime is designed to minimize resource overhead and startup latency. It achieves this by shifting from traditional process-based management to a more integrated, Rust-native control flow.
-
-```mermaid
-graph TD
-    containerd["containerd"] --> shimv2["containerd-shim-kata-v2 (shimv2)"]
-
-    subgraph BuiltIn["Built-in VMM (Integrated Mode)"]
-        direction TD
-        subgraph shimv2_bi["shimv2 process (Single Process)"]
-            runtime_bi["shimv2 runtime"]
-            subgraph dragonball["Dragonball VMM (library)"]
-                helpers_bi["virtiofs / nydus\n(BuiltIn)"]
-            end
-            runtime_bi -->|"direct function calls"| dragonball
-        end
-        subgraph guestvm_bi["Guest VM"]
-            agent_bi["kata-agent"]
-        end
-        shimv2_bi -->|"hybrid-vsock"| guestvm_bi
-    end
-
-    subgraph OptionalVMM["Optional VMM (External Mode)"]
-        direction TD
-        shimv2_ext["shimv2 process"]
-        imagesrvd_ext["virtiofsd / nydusd\n(Independent Process)"]
-        ext_vmm["External VMM process\n(QEMU / Cloud-Hypervisor / Firecracker)"]
-        subgraph guestvm_ext["Guest VM"]
-            agent_ext["kata-agent"]
-        end
-        shimv2_ext -->|"fork + IPC/RPC"| ext_vmm
-        shimv2_ext -->|"manages"| imagesrvd_ext
-        ext_vmm -->|"vsock / hybrid-vsock"| guestvm_ext
-    end
-
-    shimv2 --> BuiltIn
-    shimv2 --> OptionalVMM
-
-    classDef process fill:#d0e8ff,stroke:#336,stroke-width:1px
-    classDef vm fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef agent fill:#fff3cd,stroke:#856404,stroke-width:1px
-    class shimv2,runtime_bi,shimv2_ext,helpers_bi,imagesrvd_ext,ext_vmm process
-    class guestvm_bi,guestvm_ext vm
-    class agent_bi,agent_ext agent
-```
-
-The runtime employs a **flexible VMM strategy**, supporting both `built-in` and `optional` VMMs. This allows users to choose between a tightly integrated VMM (e.g., Dragonball) for peak performance, or external options (e.g., QEMU, Cloud-Hypervisor, Firecracker) for enhanced compatibility and modularity.
-
-### A. Built-in VMM (Integrated Mode)
-
-The built-in VMM mode is the default and recommended configuration for users, as it offers superior performance and resource efficiency.
-
-In this mode, the VMM (`Dragonball`) is **deeply integrated** into the `shimv2`'s lifecycle. This eliminates the overhead of IPC, enabling lower-latency message processing and tight API synchronization. Moreover, it ensures the runtime and VMM share a unified lifecycle, simplifying exception handling and resource cleanup.
-
-*   **Integrated Management**: The `shimv2` directly controls the VMM and its critical helper services (`virtiofsd` or `nydusd`).
-*   **Performance**: By eliminating external process overhead and complex inter-process communication (IPC), this mode achieves faster container startup and higher resource density.
-*   **Core Technology**: Primarily utilizes **Dragonball**, the native Rust-based VMM optimized and dedicated for cloud-native scenarios.
-
-> **Note**: The built-in VMM mode is the default and recommended configuration for users, as it offers superior performance and resource efficiency.
-
-### B. Optional VMM (External Mode)
-
-The optional VMM mode is available for users with specific requirements that necessitate external hypervisor support.
-
-In this mode, the runtime and the VMM operate as separate, decoupled processes. The runtime forks the VMM process and interacts with it via inter-process RPC. And the `containerd-shim-kata-v2`(short of `shimv2`) manages the VMM as an **external process**.
-
-*   **Decoupled Lifecycle**: The `shimv2` communicates with the VMM (e.g., QEMU, Cloud-Hypervisor, or Firecracker) via vsock/hybrid vsock.
-*   **Flexibility**: Ideal for environments that require specific hypervisor hardware emulation or legacy compatibility.
-
-> **Note**:  This approach (Optional VMM) introduces overhead due to context switching and cross-process communication. Furthermore, managing resources across process boundaries—especially during abnormal conditions—introduces significant complexity in error detection and recovery.
-
----
-
-## Core Architectural Principles
-
-*   **Safety via Rust**: Leveraging Rust's ownership and type systems to eliminate memory-related vulnerabilities (buffer overflows, dangling pointers) by design.
-*   **Performance via Async**: Utilizing Tokio to handle high-concurrency I/O, reducing the OS thread footprint by an order of magnitude.
-*   **Built-in VMM**: A modular, library-based approach to virtualization, enabling tighter integration with the runtime.
-*   **Pluggable Framework**: A clean abstraction layer allowing seamless swapping of hypervisors, network interfaces, and storage backends.
-
----
-
-## Design Deep Dive
-
-### Built-in VMM Integration (Dragonball)
-
-The legacy Kata 2.x architecture relied on inter-process communication (IPC) between the runtime and the VMM. This introduced context-switching latency and complex error-recovery requirements across process boundaries. In contrast, the built-in VMM approach embeds the VMM directly within the runtime's process space. This eliminates IPC overhead, allowing for direct function calls and shared memory access, resulting in significantly reduced startup times and improved performance.
-
-```mermaid
-graph LR
-    subgraph HostProcess["Host Process:containerd-shim-kata-v2 (shimv2)"]
-        shimv2["shimv2 runtime"]
-    end
-
-    imagesrvd["virtiofsd / nydusd\n(Independent Process)"]
-
-    subgraph ExtVMMProc["External VMM Process (e.g., QEMU)"]
-        vmm["VMM\n(QEMU / Cloud-Hypervisor\n/ Firecracker)"]
-    end
-
-    subgraph GuestVM["Guest VM"]
-        agent["kata-agent"]
-    end
-
-    shimv2 -->|"fork + IPC / RPC"| vmm
-    shimv2 -->|"manages"| imagesrvd
-    vmm -->|"vsock / hybrid-vsock"| GuestVM
-
-    classDef proc fill:#d0e8ff,stroke:#336,stroke-width:1px
-    classDef vm fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef ag fill:#fff3cd,stroke:#856404,stroke-width:1px
-    class shimv2,imagesrvd,vmm proc
-    class agent ag
-```
-
-```mermaid
-graph LR
-    subgraph SingleProcess["Single Process: containerd-shim-kata-v2 (shimv2)"]
-        shimv2["shimv2 runtime"]
-        subgraph dragonball["Dragonball VMM (library)"]
-            helpers["virtiofs / nydus\n(BuiltIn)"]
-        end
-        shimv2 -->|"direct function calls"| dragonball
-    end
-
-    subgraph GuestVM["Guest VM"]
-        agent["kata-agent"]
-    end
-
-    dragonball -->|"hybrid-vsock"| GuestVM
-
-    classDef proc fill:#d0e8ff,stroke:#336,stroke-width:1px
-    classDef vm fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef ag fill:#fff3cd,stroke:#856404,stroke-width:1px
-    class shimv2,helpers proc
-    class agent ag
-```
-
-By integrating Dragonball directly as a library, we eliminate the need for heavy IPC.
-
-*   **API Synchronization**: Direct function calls replace RPCs, reducing latency.
-*   **Unified Lifecycle**: The runtime and VMM share a single process lifecycle, significantly simplifying resource cleanup and fault isolation.
-
-### Layered Architecture
-
-The Kata 4.0 runtime utilizes a highly modular, layered architecture designed to decouple high-level service requests from low-level infrastructure execution. This design facilitates extensibility, allowing the system to support diverse container types and dragonball within a single, unified Rust binary and also support other hypervisors  as optional VMMs.
-
-```mermaid
-graph TD
-    subgraph L1["Layer 1 — Service & Orchestration Layer"]
-        TaskSvc["Task Service"]
-        ImageSvc["Image Service"]
-        OtherSvc["Other Services"]
-        Dispatcher["Message Dispatcher"]
-        TaskSvc --> Dispatcher
-        ImageSvc --> Dispatcher
-        OtherSvc --> Dispatcher
-    end
-
-    subgraph L2["Layer 2 — Management & Handler Layer"]
-        subgraph RuntimeHandler["Runtime Handler"]
-            SandboxMgr["Sandbox Manager"]
-            ContainerMgr["Container Manager"]
-        end
-        subgraph ContainerAbstractions["Container Abstractions"]
-            LinuxContainer["LinuxContainer"]
-            VirtContainer["VirtContainer"]
-            WasmContainer["WasmContainer"]
-        end
-    end
-
-    subgraph L3["Layer 3 — Infrastructure Abstraction Layer"]
-        subgraph HypervisorIface["Hypervisor Interface"]
-            Qemu["Qemu"]
-            CloudHV["Cloud Hypervisor"]
-            Firecracker["Firecracker"]
-            Dragonball["Dragonball"]
-        end
-        subgraph ResourceMgr["Resource Manager"]
-            Sharedfs["Sharedfs"]
-            Network["Network"]
-            Rootfs["Rootfs"]
-            Volume["Volume"]
-            Cgroup["Cgroup"]
-        end
-    end
-
-    subgraph L4["Layer 4 — Built-in Dragonball VMM Layer"]
-        BuiltinDB["Builtin Dragonball"]
-    end
-
-    Dispatcher --> RuntimeHandler
-    RuntimeHandler --> ContainerAbstractions
-    ContainerAbstractions --> HypervisorIface
-    ContainerAbstractions --> ResourceMgr
-    Dragonball --> BuiltinDB
-
-    classDef svc fill:#cce5ff,stroke:#004085,stroke-width:1px
-    classDef handler fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef infra fill:#fff3cd,stroke:#856404,stroke-width:1px
-    classDef builtin fill:#f8d7da,stroke:#721c24,stroke-width:1px
-    class TaskSvc,ImageSvc,OtherSvc,Dispatcher svc
-    class SandboxMgr,ContainerMgr,LinuxContainer,VirtContainer,WasmContainer handler
-    class Qemu,CloudHV,Firecracker,Dragonball,Sharedfs,Network,Rootfs,Volume,Cgroup infra
-    class BuiltinDB builtin
-```
-
-#### Service & Orchestration Layer
-
-*   **Service Layer**: The entry point for the runtime, providing specialized interfaces for external callers (e.g., `containerd`). It includes:
-    *   **Task Service**: Manages the lifecycle of containerized processes.
-    *   **Image Service**: Handles container image operations.
-    *   **Other Services**: An extensible framework allowing for custom modules.
-
-*   **Message Dispatcher**: Acts as a centralized traffic controller. It parses requests from the Service layer and routes them to the appropriate **Runtime Handler**, ensuring efficient message multiplexing.
-
-#### Management & Handler Layer
-
-*   **Runtime Handler**: The core processing engine. It abstracts the underlying workload, enabling the runtime to handle various container types through:
-    *   **Sandbox Manager**: Orchestrates the lifecycle of the entire Pod (Sandbox).
-    *   **Container Manager**: Manages individual containers within a Sandbox.
-
-*   **Container Abstractions**: The framework is agnostic to the container implementation, with explicit support paths for:
-    *   **LinuxContainer** (Standard/OCI)
-    *   **VirtContainer** (Virtualization-based)
-    *   **WasmContainer** (WebAssembly-based)
-
-#### Infrastructure Abstraction Layer
-
-This layer provides standardized interfaces for hardware and resource management, regardless of the underlying backend.
-
-*   **Hypervisor Interface**: A pluggable architecture supporting multiple virtualization backends, including **Qemu**, **Cloud Hypervisor**, **Firecracker**, and **Dragonball**.
-
-*   **Resource Manager**: A unified interface for managing critical infrastructure components:
-    *   **Sharedfs, Network, Rootfs, Volume, and cgroup management**.
-
-#### Built-in Dragonball VMM Layer
-
-Representing the core of the high-performance runtime, the `Builtin Dragonball` block demonstrates deep integration between the runtime and the hypervisor.
-
-#### Key Architectural Advantages
-
-*   **Uniformity**: By consolidating these layers into a single binary, the runtime ensures a consistent state across all sub-modules, preventing the "split-brain" scenarios common in multi-process runtimes.
-*   **Modularity**: The clear separation between the **Message Dispatcher** and the **Runtime Handler** allows developers to introduce new container types (e.g., WASM) or hypervisors without modifying existing core logic.
-*   **Efficiency**: The direct integration of `Dragonball` as a library allows for "Zero-Copy" resource management and direct API access, which drastically improves performance compared to traditional RPC-based hypervisor interaction.
-
-### Extensible Framework
-
-The Kata Rust runtime features a modular design that supports diverse services, runtimes, and hypervisors. We utilize a registration mechanism to decouple service logic from the core runtime. At startup, the runtime resolves the required runtime handler and hypervisor types based on configuration.
-
-```mermaid
-graph LR
-    API["API"]
-
-    subgraph Services["Configurable Services"]
-        TaskSvc["Task Service"]
-        ImageSvc["Image Service"]
-        OtherSvc["Other Service"]
-    end
-
-    Msg(["Message Dispatcher"])
-
-    subgraph Handlers["Configurable Runtime Handlers"]
-        WasmC["WasmContainer"]
-        VirtC["VirtContainer"]
-        LinuxC["LinuxContainer"]
-    end
-
-    subgraph HVs["Configurable Hypervisors"]
-        DB["Dragonball"]
-        QEMU["QEMU"]
-        CH["Cloud Hypervisor"]
-        FC["Firecracker"]
-    end
-
-    API --> Services
-    Services --> Msg
-    Msg --> Handlers
-    Handlers --> HVs
-
-    classDef api fill:#d0e8ff,stroke:#336,stroke-width:1px
-    classDef svc fill:#e2d9f3,stroke:#6610f2,stroke-width:1px
-    classDef msg fill:#fff3cd,stroke:#856404,stroke-width:1px
-    classDef handler fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef hv fill:#f8d7da,stroke:#721c24,stroke-width:1px
-    class API api
-    class TaskSvc,ImageSvc,OtherSvc svc
-    class Msg msg
-    class WasmC,VirtC,LinuxC handler
-    class DB,QEMU,CH,FC hv
-```
-
-### Modular Resource Manager
-
-Managing diverse resources—from Virtio-fs volumes to Cgroup V2—is handled by an abstracted resource manager. Each resource type implements a common trait, enabling uniform lifecycle hooks and deterministic dependency resolution.
-
-```mermaid
-graph LR
-    RM["Resource Manager"]
-
-    subgraph SandboxRes["Sandbox Resources"]
-        Network["Network Entity"]
-        SharedFs["Shared FS"]
-    end
-
-    subgraph ContainerRes["Container Resources"]
-        Rootfs["Rootfs"]
-        Cgroup["Cgroup"]
-        Volume["Volume"]
-    end
-
-    RM --> Network
-    RM --> SharedFs
-    RM --> Rootfs
-    RM --> Cgroup
-    RM --> Volume
-
-    Network --> Endpoint["endpoint\n(veth / physical)"]
-    Network --> NetModel["model\n(tcfilter / route)"]
-    SharedFs --> InlineVirtioFs["inline virtiofs"]
-    SharedFs --> StandaloneVirtioFs["standalone virtiofs"]
-
-    Rootfs --> RootfsTypes["block / virtiofs / nydus"]
-    Cgroup --> CgroupVers["v1 / v2"]
-    Volume --> VolumeTypes["sharefs / shm / local\nephemeral / direct / block"]
-
-    classDef rm fill:#e2d9f3,stroke:#6610f2,stroke-width:2px
-    classDef sandbox fill:#d0e8ff,stroke:#336,stroke-width:1px
-    classDef container fill:#d4edda,stroke:#155724,stroke-width:1px
-    classDef impl fill:#fff3cd,stroke:#856404,stroke-width:1px
-    class RM rm
-    class Network,SharedFs sandbox
-    class Rootfs,Cgroup,Volume container
-    class Endpoint,NetModel,InlineVirtioFs,StandaloneVirtioFs,RootfsTypes,CgroupVers,VolumeTypes impl
-```
-
-### Asynchronous I/O Model
-
-Synchronous runtimes are often limited by "thread bloat," where each container or connection spawns multiple OS threads.
-
-#### Why Async Rust?
-
-**The Rust async ecosystem is stable and highly efficient, providing several key benefits:**
-
-- Reduced Overhead: Significantly lower CPU and memory consumption, particularly for I/O-bound workloads.
-- Zero-Cost Abstractions: Rust's async model allows developers to "pay only for what they use," avoiding heap allocations and dynamic dispatch where possible.
-- For further reading, see [Why Async?](https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html) and [The State of Asynchronous Rust](https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html).
-
-**Limitations of Synchronous Rust in kata-runtime:**
-
-- Thread Proliferation: Every TTRPC connection creates multiple threads (Reaper, Listener, Handler), and each container adds 3 additional I/O threads, leading to high thread count and memory pressure.
-- Timeout Complexity: Implementing reliable, cross-platform timeout mechanisms in synchronous code is difficult, especially when aligning with Golang-based components.
-
-#### Implementation
-
-The kata-runtime utilizes Tokio to manage asynchronous tasks. By offloading TTRPC and container-related I/O to a unified Tokio executor and switching dependencies (Timer, File, Netlink) to their asynchronous counterparts, we achieve non-blocking I/O. The built-in VMM remains on a dedicated OS thread to ensure control and real-time performance.
-
-**Comparison of OS Thread usage (for N tokio worker threads and M containers)**
-
-- Sync Runtime: OS thread count scales as 4 + 12*M.
-- Async Runtime: OS thread count scales as 2 + N.
-
-```shell
-├─ main(OS thread)
-├─ async-logger(OS thread)
-└─ tokio worker(N * OS thread)
-  ├─ agent log forwarder(1 * tokio task)
-  ├─ health check thread(1 * tokio task)
-  ├─ TTRPC reaper thread(M * tokio task)
-  ├─ TTRPC listener thread(M * tokio task)
-  ├─ TTRPC client handler thread(7 * M * tokio task)
-  ├─ container stdin io thread(M * tokio task)
-  ├─ container stdout io thread(M * tokio task)
-  └─ container stderr io thread(M * tokio task)
-```
-
-The Async Advantage:
-We move away from thread-per-task to a Tokio-driven task model.
-
-*   **Scalability**: The OS thread count is reduced from 4 + 12*M (Sync) to 2 + N (Async), where N is the worker thread count.
-*   **Efficiency**: Non-blocking I/O allows a single thread to handle multiplexed container operations, significantly lowering memory consumption for high-density pod deployments.
-
----
-
-## 2. Getting Started
-To configure your preferred VMM strategy, locate the `[hypervisor]` block in your runtime configuration file:
-
-- Install Kata Containers with the Rust Runtime and Dragonball as the built-in VMM by following the [containerd-kata](../../how-to/containerd-kata.md).
-- Run a kata with builtin VMM Dragonball
-
-```shell
-$ sudo ctr run  --runtime io.containerd.kata.v2 -d docker.io/library/ubuntu:latest hello
-```
-
-As the VMM and its image service have been builtin, you should only see a single containerd-shim-kata-v2 process.
-
----
-
-## FAQ
-
-* **Q1**: Is the architecture compatible with containerd?
-
-Yes. It implements the containerd-shim-v2 interface, ensuring drop-in compatibility with standard cloud-native tooling.
-
-* **Q2**: What is the security boundary for the "Built-in VMM" model?
-
-The security boundary remains established by the hypervisor (hardware virtualization). The shift to a monolithic process model does not compromise isolation; rather, it improves the integrity of the control plane by reducing the attack surface typically associated with complex IPC mechanisms.
-
-* **Q3**: What is the migration path?
-
-Migration is managed via configuration policies. The containerd shim configuration will allow users to toggle between the legacy runtime and the runtime-rs (internally `RunD`) binary, facilitating canary deployments and gradual migration.
-
-* **Q4**: Why upcall instead of ACPI?
-
-Standard ACPI-based hotplugging requires heavy guest-side kernel emulation and udevd interaction. Dbs-upcall utilizes a vsock-based direct channel to trigger hotplug events, providing:
-
-Deterministic execution: Bypassing complex guest-side ACPI state machines.
-Lower overhead: Minimizing guest kernel footprint.
-
-* **Q5**: How upcall works?
-
-The `Dbs-upcall` architecture consists of a server-side driver in the guest kernel and a client-side thread within the VMM. Once the guest kernel initializes, it establishes a communication channel via vsock (using uds). This allows the VMM to directly request device hot-add/hot-remove operations. We have already open-sourced this implementation: [dbs-upcall](https://github.com/openanolis/dragonball-sandbox/tree/main/crates/dbs-upcall).

docs/design/direct-blk-device-assignment.md

@@ -1,62 +1,62 @@
 # Motivation
-Today, there exist a few gaps between Container Storage Interface (CSI) and virtual machine (VM) based runtimes such as Kata Containers
+Today, there exist a few gaps between Container Storage Interface (CSI) and virtual machine (VM) based runtimes such as Kata Containers 
 that prevent them from working together smoothly.
 
 First, it’s cumbersome to use a persistent volume (PV) with Kata Containers. Today, for a PV with Filesystem volume mode, Virtio-fs
-is the only way to surface it inside a Kata Container guest VM. But often mounting the filesystem (FS) within the guest operating system (OS) is
+is the only way to surface it inside a Kata Container guest VM. But often mounting the filesystem (FS) within the guest operating system (OS) is 
 desired due to performance benefits, availability of native FS features and security benefits over the Virtio-fs mechanism.
 
-Second, it’s difficult if not impossible to resize a PV online with Kata Containers. While a PV can be expanded on the host OS,
-the updated metadata needs to be propagated to the guest OS in order for the application container to use the expanded volume.
+Second, it’s difficult if not impossible to resize a PV online with Kata Containers. While a PV can be expanded on the host OS, 
+the updated metadata needs to be propagated to the guest OS in order for the application container to use the expanded volume. 
 Currently, there is not a way to propagate the PV metadata from the host OS to the guest OS without restarting the Pod sandbox.
 
 # Proposed Solution
 
-Because of the OS boundary, these features cannot be implemented in the CSI node driver plugin running on the host OS
-as is normally done in the runc container. Instead, they can be done by the Kata Containers agent inside the guest OS,
-but it requires the CSI driver to pass the relevant information to the Kata Containers runtime.
-An ideal long term solution would be to have the `kubelet` coordinating the communication between the CSI driver and
-the container runtime, as described in [KEP-2857](https://github.com/kubernetes/enhancements/pull/2893/files).
+Because of the OS boundary, these features cannot be implemented in the CSI node driver plugin running on the host OS 
+as is normally done in the runc container. Instead, they can be done by the Kata Containers agent inside the guest OS, 
+but it requires the CSI driver to pass the relevant information to the Kata Containers runtime. 
+An ideal long term solution would be to have the `kubelet` coordinating the communication between the CSI driver and 
+the container runtime, as described in [KEP-2857](https://github.com/kubernetes/enhancements/pull/2893/files). 
 However, as the KEP is still under review, we would like to propose a short/medium term solution to unblock our use case.
 
-The proposed solution is built on top of a previous [proposal](https://github.com/egernst/kata-containers/blob/da-proposal/docs/design/direct-assign-volume.md)
+The proposed solution is built on top of a previous [proposal](https://github.com/egernst/kata-containers/blob/da-proposal/docs/design/direct-assign-volume.md) 
 described by Eric Ernst. The previous proposal has two gaps:
 
-1. Writing a `csiPlugin.json` file to the volume root path introduced a security risk. A malicious user can gain unauthorized
-access to a block device by writing their own `csiPlugin.json` to the above location through an ephemeral CSI plugin.
+1. Writing a `csiPlugin.json` file to the volume root path introduced a security risk. A malicious user can gain unauthorized 
+access to a block device by writing their own `csiPlugin.json` to the above location through an ephemeral CSI plugin.  
 
-2. The proposal didn't describe how to establish a mapping between a volume and a kata sandbox, which is needed for
+2. The proposal didn't describe how to establish a mapping between a volume and a kata sandbox, which is needed for 
 implementing CSI volume resize and volume stat collection APIs.
 
 This document particularly focuses on how to address these two gaps.
 
 ## Assumptions and Limitations
-1. The proposal assumes that a block device volume will only be used by one Pod on a node at a time, which we believe
-is the most common pattern in Kata Containers use cases. It’s also unsafe to have the same block device attached to more than
-one Kata pod. In the context of Kubernetes, the `PersistentVolumeClaim` (PVC) needs to have the `accessMode` as `ReadWriteOncePod`.
-2. More advanced Kubernetes volume features such as, `fsGroup`, `fsGroupChangePolicy`, and `subPath` are not supported.
+1. The proposal assumes that a block device volume will only be used by one Pod on a node at a time, which we believe 
+is the most common pattern in Kata Containers use cases. It’s also unsafe to have the same block device attached to more than 
+one Kata pod. In the context of Kubernetes, the `PersistentVolumeClaim` (PVC) needs to have the `accessMode` as `ReadWriteOncePod`. 
+2. More advanced Kubernetes volume features such as, `fsGroup`, `fsGroupChangePolicy`, and `subPath` are not supported. 
 
 ## End User Interface
 
 1. The user specifies a PV as a direct-assigned volume. How a PV is specified as a direct-assigned volume is left for each CSI implementation to decide.
 There are a few options for reference:
-   1. A storage class parameter specifies whether it's a direct-assigned volume. This avoids any lookups of PVC
-   or Pod information from the CSI plugin (as external provisioner takes care of these). However, all PVs in the storage class with the parameter set
+   1. A storage class parameter specifies whether it's a direct-assigned volume. This avoids any lookups of PVC 
+   or Pod information from the CSI plugin (as external provisioner takes care of these). However, all PVs in the storage class with the parameter set 
    will have host mounts skipped.
    2. Use a PVC annotation. This approach requires the CSI plugins have `--extra-create-metadata` [set](https://kubernetes-csi.github.io/docs/external-provisioner.html#persistentvolumeclaim-and-persistentvolume-parameters)
-   to be able to perform a lookup of the PVC annotations from the API server. Pro: API server lookup of annotations only required during creation of PV.
+   to be able to perform a lookup of the PVC annotations from the API server. Pro: API server lookup of annotations only required during creation of PV. 
    Con: The CSI plugin will always skip host mounting of the PV.
    3. The CSI plugin can also lookup pod `runtimeclass` during `NodePublish`. This approach can be found in the [ALIBABA CSI plugin](https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/blob/master/pkg/disk/nodeserver.go#L248).
-2. The CSI node driver delegates the direct assigned volume to the Kata Containers runtime. The CSI node driver APIs need to
+2. The CSI node driver delegates the direct assigned volume to the Kata Containers runtime. The CSI node driver APIs need to 
    be modified to pass the volume mount information and collect volume information to/from the Kata Containers runtime by invoking `kata-runtime` command line commands.
-   * **`NodePublishVolume`** -- It invokes `kata-runtime direct-volume add --volume-path [volumePath] --mount-info [mountInfo]`
+   * **NodePublishVolume** -- It invokes `kata-runtime direct-volume add --volume-path [volumePath] --mount-info [mountInfo]` 
    to propagate the volume mount information to the Kata Containers runtime for it to carry out the filesystem mount operation.
    The `volumePath` is the [target_path](https://github.com/container-storage-interface/spec/blob/master/csi.proto#L1364) in the CSI `NodePublishVolumeRequest`.
-   The `mountInfo` is a serialized JSON string.
-   * **`NodeGetVolumeStats`** -- It invokes `kata-runtime direct-volume stats --volume-path [volumePath]` to retrieve the filesystem stats of direct-assigned volume.
-   * **`NodeExpandVolume`** -- It invokes `kata-runtime direct-volume resize --volume-path [volumePath] --size [size]` to send a resize request to the Kata Containers runtime to
+   The `mountInfo` is a serialized JSON string. 
+   * **NodeGetVolumeStats** -- It invokes `kata-runtime direct-volume stats --volume-path [volumePath]` to retrieve the filesystem stats of direct-assigned volume.
+   * **NodeExpandVolume** -- It invokes `kata-runtime direct-volume resize --volume-path [volumePath] --size [size]` to send a resize request to the Kata Containers runtime to
    resize the direct-assigned volume.
-   * **`NodeStageVolume/NodeUnStageVolume`** -- It invokes `kata-runtime direct-volume remove --volume-path [volumePath]` to remove the persisted metadata of a direct-assigned volume.
+   * **NodeStageVolume/NodeUnStageVolume** -- It invokes `kata-runtime direct-volume remove --volume-path [volumePath]` to remove the persisted metadata of a direct-assigned volume.
 
 The `mountInfo` object is defined as follows:
 ```Golang
@@ -78,17 +78,17 @@ Notes: given that the `mountInfo` is persisted to the disk by the Kata runtime,
 ## Implementation Details
 
 ### Kata runtime
-Instead of the CSI node driver writing the mount info into a `csiPlugin.json` file under the volume root,
-as described in the original proposal, here we propose that the CSI node driver passes the mount information to
-the Kata Containers runtime through a new `kata-runtime` commandline command. The `kata-runtime` then writes the mount
+Instead of the CSI node driver writing the mount info into a `csiPlugin.json` file under the volume root, 
+as described in the original proposal, here we propose that the CSI node driver passes the mount information to 
+the Kata Containers runtime through a new `kata-runtime` commandline command. The `kata-runtime` then writes the mount 
 information to a `mountInfo.json` file in a predefined location (`/run/kata-containers/shared/direct-volumes/[volume_path]/`).
 
-When the Kata Containers runtime starts a container, it verifies whether a volume mount is a direct-assigned volume by checking
-whether there is a `mountInfo` file under the computed Kata `direct-volumes` directory. If it is, the runtime parses the `mountInfo` file,
+When the Kata Containers runtime starts a container, it verifies whether a volume mount is a direct-assigned volume by checking 
+whether there is a `mountInfo` file under the computed Kata `direct-volumes` directory. If it is, the runtime parses the `mountInfo` file, 
 updates the mount spec with the data in `mountInfo`. The updated mount spec is then passed to the Kata agent in the guest VM together
-with other mounts. The Kata Containers runtime also creates a file named by the sandbox id under the `direct-volumes/[volume_path]/`
-directory. The reason for adding a sandbox id file is to establish a mapping between the volume and the sandbox using it.
-Later, when the Kata Containers runtime handles the `get-stats` and `resize` commands, it uses the sandbox id to identify
+with other mounts. The Kata Containers runtime also creates a file named by the sandbox id under the `direct-volumes/[volume_path]/` 
+directory. The reason for adding a sandbox id file is to establish a mapping between the volume and the sandbox using it. 
+Later, when the Kata Containers runtime handles the `get-stats` and `resize` commands, it uses the sandbox id to identify 
 the endpoint of the corresponding `containerd-shim-kata-v2`.
 
 ### containerd-shim-kata-v2 changes
@@ -101,12 +101,12 @@ $ curl --unix-socket "$shim_socket_path" -I -X GET 'http://localhost/direct-volu
 $ curl --unix-socket "$shim_socket_path" -I -X POST 'http://localhost/direct-volume/resize' -d '{ "volumePath"": [volumePath], "Size": "123123" }'
 ```
 
-The shim then forwards the corresponding request to the `kata-agent` to carry out the operations inside the guest VM. For `resize` operation,
-the Kata runtime also needs to notify the hypervisor to resize the block device (e.g. call `block_resize` in QEMU).
+The shim then forwards the corresponding request to the `kata-agent` to carry out the operations inside the guest VM. For `resize` operation, 
+the Kata runtime also needs to notify the hypervisor to resize the block device (e.g. call `block_resize` in QEMU). 
 
 ### Kata agent changes
 
-The mount spec of a direct-assigned volume is passed to `kata-agent` through the existing `Storage` GRPC object.
+The mount spec of a direct-assigned volume is passed to `kata-agent` through the existing `Storage` GRPC object. 
 Two new APIs and three new GRPC objects are added to GRPC protocol between the shim and agent for resizing and getting volume stats:
 ```protobuf
 
@@ -226,7 +226,7 @@ Let’s assume that changes have been made in the `aws-ebs-csi-driver` node driv
 1. In the node CSI driver, the `NodePublishVolume` API invokes: `kata-runtime direct-volume add --volume-path "/kubelet/a/b/c/d/sdf" --mount-info "{\"Device\": \"/dev/sdf\", \"fstype\": \"ext4\"}"`.
 2. The `Kata-runtime` writes the mount-info JSON to a file called `mountInfo.json` under `/run/kata-containers/shared/direct-volumes/kubelet/a/b/c/d/sdf`.
 
-**Node `unstage` volume**
+**Node unstage volume**
 1. In the node CSI driver, the `NodeUnstageVolume` API invokes: `kata-runtime direct-volume remove --volume-path "/kubelet/a/b/c/d/sdf"`.
 2. Kata-runtime deletes the directory `/run/kata-containers/shared/direct-volumes/kubelet/a/b/c/d/sdf`.
 

docs/design/hooks-handling.md

@@ -59,5 +59,5 @@ The table below summarized when and where those different hooks will be executed
 
 + `Hook Path` specifies where hook's path be resolved.
 + `Exec Place` specifies in which namespace those hooks can be executed.
-  + For `CreateContainer` Hooks, OCI requires to run them inside the container namespace while the hook executable path is in the host runtime, which is a non-starter for VM-based containers. So we design to keep them running in the *host vmm namespace.*
-+ `Exec Time` specifies at which time point those hooks can be executed.
+  + For `CreateContainer` Hooks, OCI requires to run them inside the container namespace while the hook executable path is in the host runtime, which is a non-starter for VM-based containers. So we design to keep them running in the *host vmm namespace.* 
++ `Exec Time` specifies at which time point those hooks can be executed.

docs/design/host-cgroups.md

@@ -118,7 +118,7 @@ all vCPU and I/O related threads) will be created in the `/kata_<PodSandboxID>`
 
 ### Why create a kata-cgroup under the parent cgroup?
 
-And why not directly adding the per sandbox shim directly to the pod cgroup (e.g.
+And why not directly adding the per sandbox shim directly to the pod cgroup (e.g. 
 `/kubepods` in the Kubernetes context)?
 
 The Kata Containers shim implementation creates a per-sandbox cgroup
@@ -219,13 +219,13 @@ the `/kubepods` cgroup hierarchy, and a `/<PodSandboxID>` under the `/kata_overh
 
 On a typical cgroup v1 hierarchy mounted under `/sys/fs/cgroup/`, for a pod which sandbox
 ID is `12345678`, create with `sandbox_cgroup_only` disabled, the 2 memory subsystems
-for the sandbox cgroup and the overhead cgroup would respectively live under
+for the sandbox cgroup and the overhead cgroup would respectively live under 
 `/sys/fs/cgroup/memory/kubepods/kata_12345678` and `/sys/fs/cgroup/memory/kata_overhead/12345678`.
 
 Unlike when `sandbox_cgroup_only` is enabled, the Kata Containers shim will move itself
 to the overhead cgroup first, and then move the vCPU threads to the sandbox cgroup as
 they're created. All Kata processes and threads will run under the overhead cgroup except for
-the vCPU threads.
+the vCPU threads. 
 
 With `sandbox_cgroup_only` disabled, Kata Containers assumes the pod cgroup is only sized
 to accommodate for the actual container workloads processes. For Kata, this maps
@@ -247,7 +247,7 @@ cgroup size and constraints accordingly.
 
 # Supported cgroups
 
-Kata Containers currently supports cgroups `v1` and `v2`.
+Kata Containers currently supports cgroups `v1` and `v2`. 
 
 In the following sections each cgroup is described briefly.
 

docs/design/kata-2-0-metrics.md

@@ -119,17 +119,17 @@ The metrics service also doesn't hold any metrics in memory.
 *Metrics size*: response size of one Prometheus scrape request.
 
 It's easy to estimate the size of one metrics fetch request issued by Prometheus.
-The formula to calculate the expected size when no gzip compression is in place is:
+The formula to calculate the expected size when no gzip compression is in place is:  
 9 + (144 - 9) * `number of kata sandboxes`
 
-Prometheus supports `gzip compression`. When enabled, the response size of each request will be smaller:
+Prometheus supports `gzip compression`. When enabled, the response size of each request will be smaller:  
 2 + (10 - 2) * `number of kata sandboxes`
 
-**Example**
-We have 10 sandboxes running on a node. The expected size of one metrics fetch request issued by Prometheus against the kata-monitor agent running on that node will be:
+**Example**  
+We have 10 sandboxes running on a node. The expected size of one metrics fetch request issued by Prometheus against the kata-monitor agent running on that node will be:  
 9 + (144 - 9) * 10 = **1.35M**
 
-If `gzip compression` is enabled:
+If `gzip compression` is enabled:  
 2 + (10 - 2) * 10 = **82K**
 
 #### Metrics delay ####

docs/design/kata-api-design.md

@@ -43,7 +43,7 @@ To fulfill the [Kata design requirements](kata-design-requirements.md), and base
 |`sandbox.AddInterface(inf)`| Add new NIC to the sandbox.|
 |`sandbox.RemoveInterface(inf)`| Remove a NIC from the sandbox.|
 |`sandbox.ListInterfaces()`| List all NICs and their configurations in the sandbox, return a `pbTypes.Interface` list.|
-|`sandbox.UpdateRoutes(routes)`| Update the sandbox route table (e.g. for port mapping support), return a `pbTypes.Route` list.|
+|`sandbox.UpdateRoutes(routes)`| Update the sandbox route table (e.g. for portmapping support), return a `pbTypes.Route` list.|
 |`sandbox.ListRoutes()`| List the sandbox route table, return a `pbTypes.Route` list.|
 
 ### Sandbox Relay API

docs/design/kata-design-requirements.md

@@ -71,7 +71,7 @@ The Kata Containers runtime **MUST** support scalable I/O through the SRIOV tech
 ### Virtualization overhead reduction
 A compelling aspect of containers is their minimal overhead compared to bare metal applications.
 A container runtime should keep the overhead to a minimum in order to provide the expected user
-experience.
+experience. 
 The Kata Containers runtime implementation **SHOULD** be optimized for:
 
 * Minimal workload boot and shutdown times

docs/design/kata-guest-image-management-design.md

@@ -5,7 +5,7 @@ To safeguard the integrity of container images and prevent tampering from the ho
 ## Introduction to remote snapshot
 Containerd 1.7 introduced `remote snapshotter` feature which is the foundation for pulling images in the guest for Confidential Containers.
 
-While it's beyond the scope of this document to fully explain how the container rootfs is created to the point it can be executed,  a fundamental grasp of the snapshot concept is essential. Putting it in a simple way, containerd fetches the image layers from an OCI registry into its local content storage. However, they cannot be mounted as is (e.g. the layer can be tar+gzip compressed) as well as they should be immutable so the content can be shared among containers. Thus containerd leverages snapshots of those layers to build the container's rootfs.
+While it's beyond the scope of this document to fully explain how the container rootfs is created to the point it can be executed,  a fundamental grasp of the snapshot concept is essential. Putting it in a simple way, containerd fetches the image layers from an OCI registry into its local content storage. However, they cannot be mounted as is (e.g. the layer can be tar+gzip compressed) as well as they should be immutable so the content can be shared among containers. Thus containerd leverages snapshots of those layers to build the container's rootfs. 
 
 The role of `remote snapshotter` is to reuse snapshots that are stored in a remotely shared place, thus enabling containerd to prepare the container’s rootfs in a manner similar to that of a local `snapshotter`. The key behavior that makes this the building block of Kata's guest image management for Confidential Containers is that containerd will not pull the image layers from registry, instead it assumes that `remote snapshotter` and/or an external entity will perform that operation on his behalf.
 
@@ -48,7 +48,7 @@ Pull the container image directly from the guest VM using `nydus snapshotter` ba
 
 #### Architecture
 
-The following diagram provides an overview of the architecture for pulling image in the guest with key components.
+The following diagram provides an overview of the architecture for pulling image in the guest with key components. 
 ```mermaid
 flowchart LR
     Kubelet[kubelet]--> |1\. Pull image request & metadata|Containerd
@@ -129,7 +129,7 @@ Next the `handleImageGuestPullBlockVolume()` is called to build the Storage obje
 Below is an example of storage information packaged in the message sent to the kata-agent:
 
 ```json
-"driver": "image_guest_pull",
+"driver": "image_guest_pull", 
     "driver_options": [
         "image_guest_pull"{
             "metadata":{
@@ -145,15 +145,15 @@ Below is an example of storage information packaged in the message sent to the k
                 "io.kubernetes.cri.sandbox-uid": "de7c6a0c-79c0-44dc-a099-69bb39f180af",
             }
         }
-    ],
-    "source": "quay.io/kata-containers/confidential-containers:unsigned",
-    "fstype": "overlay",
-    "options": [],
+    ], 
+    "source": "quay.io/kata-containers/confidential-containers:unsigned", 
+    "fstype": "overlay", 
+    "options": [], 
     "mount_point": "/run/kata-containers/cb0b47276ea66ee9f44cc53afa94d7980b57a52c3f306f68cb034e58d9fbd3c6/rootfs",
 ```
 Next, the kata-agent's RPC module will handle the create container request which, among other things, involves adding storages to the sandbox. The storage module contains implementations of `StorageHandler` interface for various storage types, being the `ImagePullHandler` in charge of handling the storage object for the container image (the storage manager instantiates the handler based on the value of the "driver").
 
-`ImagePullHandler` delegates the image pulling operation to the `confidential_data_hub.pull_image()` that is going to create the image's bundle directory on the guest filesystem and, in turn, the `ImagePullService` of Confidential Data Hub to fetch, uncompress and mount the image's rootfs.
+`ImagePullHandler` delegates the image pulling operation to the `confidential_data_hub.pull_image()` that is going to create the image's bundle directory on the guest filesystem and, in turn, the `ImagePullService` of Confidential Data Hub to fetch, uncompress and mount the image's rootfs. 
 
 > **Notes:**
 > In this flow, `confidential_data_hub.pull_image()` parses the image metadata, looking for either the `io.kubernetes.cri.container-type: sandbox` or `io.kubernetes.cri-o.ContainerType: sandbox` (CRI-IO case) annotation, then it never calls the `pull_image()` RPC of Confidential Data Hub because the pause image is expected to already be inside the guest's filesystem, so instead `confidential_data_hub.unpack_pause_image()` is called.

docs/design/kata-nydus-design.md

@@ -8,7 +8,7 @@ The following benchmarking result shows the performance improvement compared wit
 
 ## Proposal - Bring `lazyload` ability to Kata Containers
 
-`Nydusd` is a fuse/`virtiofs` daemon which is provided by `nydus` project and it supports `PassthroughFS` and [`rafs`](https://github.com/dragonflyoss/image-service/blob/master/docs/nydus-design.md) (Registry Acceleration File System) natively, so in Kata Containers, we can use `nydusd` in place of `virtiofsd` and mount `nydus` image to guest in the meanwhile.
+`Nydusd` is a fuse/`virtiofs` daemon which is provided by `nydus` project and it supports `PassthroughFS` and [RAFS](https://github.com/dragonflyoss/image-service/blob/master/docs/nydus-design.md) (Registry Acceleration File System) natively, so in Kata Containers, we can use `nydusd` in place of `virtiofsd` and mount `nydus` image to guest in the meanwhile.
 
 The process of creating/starting Kata Containers with `virtiofsd`,
 

docs/design/vcpu-handling-runtime-rs.md

@@ -1,6 +1,6 @@
 # Virtual machine vCPU sizing in Kata Containers 3.0
 
-> Preview:
+> Preview: 
 > [Kubernetes(since 1.23)][1] and [Containerd(since 1.6.0-beta4)][2] will help calculate `Sandbox Size` info and pass it to Kata Containers through annotations.
 > In order to adapt to this beneficial change and be compatible with the past, we have implemented the new vCPUs handling way in `runtime-rs`, which is slightly different from the original `runtime-go`'s design.
 
@@ -20,7 +20,7 @@ Our understanding and priority of these resources are as follows, which will aff
   * `default_vcpus`: default number of vCPUs when starting a VM.
   * `default_maxvcpus`: maximum number of vCPUs.
 * From `Annotation`:
-  * `InitialSize`: we call the size of the resource passed from the annotations as `InitialSize`. Kubernetes will calculate the sandbox size according to the Pod's statement, which is the `InitialSize` here. This size should be the size we want to prioritize.
+  * `InitialSize`: we call the size of the resource passed from the annotations as `InitialSize`. Kubernetes will calculate the sandbox size according to the Pod's statement, which is the `InitialSize` here. This size should be the size we want to prioritize. 
 * From `Container Spec`:
   * The amount of CPU resources that the Container wants to use will be declared through the spec. Including the aforementioned annotations, we mainly consider `cpu quota` and `cpuset` when calculating the number of vCPUs.
   * `cpu quota`: `cpu quota` is the most common way to declare the amount of CPU resources. The number of vCPUs introduced by `cpu quota` declared in a container's spec is: `vCPUs = ceiling( quota / period )`.

docs/design/vcpu-threads-pinning.md

@@ -1,9 +1,9 @@
-# Design Doc for Kata Containers VCPUs Pinning Feature
+# Design Doc for Kata Containers' VCPUs Pinning Feature
 
 ## Background
-By now, vCPU threads of Kata Containers are scheduled randomly to CPUs. And each pod would request a specific set of CPUs which we call it CPU set (just the CPU set meaning in Linux cgroups).
+By now, vCPU threads of Kata Containers are scheduled randomly to CPUs. And each pod would request a specific set of CPUs which we call it CPU set (just the CPU set meaning in Linux cgroups).    
 
-If the number of vCPU threads are equal to that of CPUs claimed in CPU set, we can then pin each vCPU thread to one specified CPU, to reduce the cost of random scheduling.
+If the number of vCPU threads are equal to that of CPUs claimed in CPU set, we can then pin each vCPU thread to one specified CPU, to reduce the cost of random scheduling. 
 
 ## Detailed Design
 
@@ -20,7 +20,7 @@ Two ways are provided to use this vCPU thread pinning feature: through `QEMU` co
 
 ### When is VCPUs Pinning Checked?
 
-As shown in Section 1, when `num(vCPU threads) == num(CPUs in CPU set)`, we shall pin each vCPU thread to a specified CPU. And when this condition is broken, we should restore to the original random scheduling pattern.
+As shown in Section 1, when `num(vCPU threads) == num(CPUs in CPU set)`, we shall pin each vCPU thread to a specified CPU. And when this condition is broken, we should restore to the original random scheduling pattern.  
 So when may `num(CPUs in CPU set)` change? There are 5 possible scenes:
 
 | Possible scenes                   | Related Code                               |
@@ -34,4 +34,4 @@ So when may `num(CPUs in CPU set)` change? There are 5 possible scenes:
 ### Core Pinning Logics
 
 We can split the whole process into the following steps. Related methods are `checkVCPUsPinning` and `resetVCPUsPinning`, in file Sandbox.go.
-![](arch-images/vcpus-pinning-process.png)
+![](arch-images/vcpus-pinning-process.png) 

docs/design/virtualization.md

@@ -1,324 +1,137 @@
 # Virtualization in Kata Containers
 
-## Overview
+Kata Containers, a second layer of isolation is created on top of those provided by traditional namespace-containers. The
+hardware virtualization interface is the basis of this additional layer. Kata will launch a lightweight virtual machine,
+and use the guest’s Linux kernel to create a container workload, or workloads in the case of multi-container pods. In Kubernetes
+and in the Kata implementation, the sandbox is carried out at the pod level. In Kata, this sandbox is created using a virtual machine.
 
-Kata Containers creates a second layer of isolation on top of traditional namespace-based containers using hardware virtualization. Kata launches a lightweight virtual machine (VM) and uses the guest Linux kernel to create container workloads. In Kubernetes, the sandbox is implemented at the pod level using VMs.
+This document describes how Kata Containers maps container technologies to virtual machines technologies, and how this is realized in
+the multiple hypervisors and virtual machine monitors that Kata supports.
 
-This document describes:
+## Mapping container concepts to virtual machine technologies
 
-- How Kata Containers maps container technologies to virtualization technologies
-- The multiple hypervisors and Virtual Machine Monitors (VMMs) supported by Kata
-- Guidance for selecting the appropriate hypervisor for your use case
+A typical deployment of Kata Containers will be in Kubernetes by way of a Container Runtime Interface (CRI) implementation. On every node,
+Kubelet will interact with a CRI implementer (such as containerd or CRI-O), which will in turn interface with Kata Containers (an OCI based runtime).
 
-### Architecture
+The CRI API, as defined at the [Kubernetes CRI-API repo](https://github.com/kubernetes/cri-api/), implies a few constructs being supported by the
+CRI implementation, and ultimately in Kata Containers. In order to support the full [API](https://github.com/kubernetes/cri-api/blob/a6f63f369f6d50e9d0886f2eda63d585fbd1ab6a/pkg/apis/runtime/v1alpha2/api.proto#L34-L110) with the CRI-implementer, Kata must provide the following constructs:
 
-A typical Kata Containers deployment integrates with Kubernetes through a Container Runtime Interface (CRI) implementation:
+![API to construct](./arch-images/api-to-construct.png)
 
-```
-Kubelet → CRI (containerd/CRI-O) → Kata Containers (OCI runtime) → VM → Containers
-```
+These constructs can then be further mapped to what devices are necessary for interfacing with the virtual machine:
 
-The CRI API requires Kata to support the following constructs:
+![construct to VM concept](./arch-images/construct-to-vm-concept.png)
 
-| CRI Construct | VM Equivalent | Virtualization Technology |
-|---------------|---------------|---------------------------|
-| Pod Sandbox | VM | Hypervisor/VMM |
-| Container | Process in VM | Namespace/Cgroup in guest |
-| Network | Network Interface | virtio-net, vhost-net, physical, etc. |
-| Storage | Block/File Device | virtio-block, virtio-scsi, virtio-fs |
-| Compute | vCPU/Memory | KVM, ACPI hotplug |
+Ultimately, these concepts map to specific para-virtualized devices or virtualization technologies.
 
-### Mapping Container Concepts to Virtualization Technologies
+![VM concept to underlying technology](./arch-images/vm-concept-to-tech.png)
 
-Kata Containers implements the Kubernetes Container Runtime Interface (CRI) to provide pod and container lifecycle management. The CRI API defines abstractions that Kata must translate into virtualization primitives.
+Each hypervisor or VMM varies on how or if it handles each of these.
 
-The mapping from CRI constructs to virtualization technologies follows a three-layer model:
+## Kata Containers Hypervisor and VMM support
 
-```
-CRI API Constructs → VM Abstractions → Para-virtualized Devices
-```
+Kata Containers [supports multiple hypervisors](../hypervisors.md).
 
-**Layer 1: CRI API Constructs**
-
-The CRI API ([kubernetes/cri-api](https://github.com/kubernetes/cri-api)) defines the following abstractions that Kata must implement:
-
-| Construct | Description |
-|-----------|-------------|
-| Pod Sandbox | Isolated execution environment for containers |
-| Container | Process workload within a sandbox |
-| Network | Pod and container networking interfaces |
-| Storage | Volume mounts and image storage |
-| RuntimeConfig | Resource constraints (CPU, memory, cgroups) |
-
-![CRI API to Kata Constructs](./arch-images/api-to-construct.png)
-
-**Layer 2: VM Abstractions**
-
-Kata translates CRI constructs into VM-level concepts:
-
-| CRI Construct | VM Equivalent |
-|---------------|---------------|
-| Pod Sandbox | Virtual Machine |
-| Container | Process/namespace in guest OS |
-| Network | Virtual NIC (vNIC) |
-| Storage | Virtual block device or filesystem |
-| RuntimeConfig | VM resources (vCPU, memory) |
-
-![Kata Constructs to VM Concepts](./arch-images/construct-to-vm-concept.png)
-
-**Layer 3: Para-virtualized Devices**
-
-VM abstractions are realized through para-virtualized drivers for optimal performance:
-
-| VM Concept | Device Technology |
-|------------|-------------------|
-| vNIC | virtio-net, vhost-net, macvtap |
-| Block Storage | virtio-block, virtio-scsi |
-| Shared Filesystem | virtio-fs |
-| Agent Communication | virtio-vsock |
-| Device Passthrough | VFIO with IOMMU |
-
-![VM Concepts to Underlying Technology](./arch-images/vm-concept-to-tech.png)
-
-> **Note:** Each hypervisor implements these mappings differently based on its device model and feature set. See the [Hypervisor Details](#hypervisor-details) section for specific implementations.
-
-### Device Mapping
-
-Container constructs map to para-virtualized devices:
-
-| Construct | Device Type | Technology |
-|-----------|-------------|------------|
-| Network | Network Interface | virtio-net, vhost-net |
-| Storage (ephemeral) | Block Device | virtio-block, virtio-scsi |
-| Storage (shared) | Filesystem | virtio-fs |
-| Communication | Socket | virtio-vsock |
-| GPU/Passthrough | PCI Device | VFIO, IOMMU |
-
-## Supported Hypervisors and VMMs
-
-Kata Containers supports multiple hypervisors, each with different characteristics:
-
-| Hypervisor | Language | Architectures | Type |
-|------------|----------|---------------|------|
-| [QEMU] | C | x86_64, aarch64, ppc64le, s390x, risc-v | Type 2 (KVM) |
-| [Cloud Hypervisor] | Rust | x86_64, aarch64 | Type 2 (KVM) |
-| [Firecracker] | Rust | x86_64, aarch64 | Type 2 (KVM) |
-| `Dragonball` | Rust | x86_64, aarch64 | Type 2 (KVM) Built-in |
-
-> **Note:** All supported hypervisors use KVM (Kernel-based Virtual Machine) as the underlying hardware virtualization interface on Linux.
-
-## Hypervisor Details
+Details of each solution and a summary are provided below.
 
 ### QEMU/KVM
 
-QEMU is the most mature and feature-complete hypervisor option for Kata Containers.
+Kata Containers with QEMU has complete compatibility with Kubernetes.
 
-**Machine Types:**
+Depending on the host architecture, Kata Containers supports various machine types,
+for example `q35` on x86 systems, `virt` on ARM systems and `pseries` on IBM Power systems. The default Kata Containers
+machine type is `q35`. The machine type and its [`Machine accelerators`](#machine-accelerators) can
+be changed by editing the runtime [`configuration`](architecture/README.md#configuration) file.
 
-- `q35` (x86_64, default)
-- `s390x` (s390x)
-- `virt` (aarch64)
-- `pseries` (ppc64le)
-- `risc-v` (riscv64, experimental)
+Devices and features used:
+- virtio VSOCK or virtio serial
+- virtio block or virtio SCSI
+- [virtio net](https://www.redhat.com/en/virtio-networking-series)
+- virtio fs or virtio 9p (recommend: virtio fs)
+- VFIO
+- hotplug
+- machine accelerators
 
-**Devices and Features:**
+Machine accelerators and hotplug are used in Kata Containers to manage resource constraints, improve boot time and reduce memory footprint. These are documented below.
 
-- virtio-vsock (agent communication)
-- virtio-block or virtio-scsi (storage)
-- virtio-net/vhost-net/vhost-user-net (networking)
-- virtio-fs (shared filesystem, virtio-fs recommended)
-- VFIO (device passthrough)
-- CPU and memory hotplug
-- NVDIMM (x86_64, for rootfs as persistent memory)
+#### Machine accelerators
 
-**Use Cases:**
+Machine accelerators are architecture specific and can be used to improve the performance
+and enable specific features of the machine types. The following machine accelerators
+are used in Kata Containers:
 
-- Production workloads requiring full CRI API compatibility
-- Scenarios requiring device passthrough (VFIO)
-- Multi-architecture deployments
+- NVDIMM: This machine accelerator is x86 specific and only supported by `q35` machine types.
+`nvdimm` is used to provide the root filesystem as a persistent memory device to the Virtual Machine.
 
-**Configuration:** See [`configuration-qemu.toml`](../../src/runtime/config/configuration-qemu.toml.in)
+#### Hotplug devices
 
-### Dragonball (Built-in VMM)
-
-Dragonball is a Rust-based VMM integrated directly into the Kata Containers Rust runtime as a library.
-
-**Advantages:**
-
-- **Zero IPC overhead**: VMM runs in the same process as the runtime
-- **Unified lifecycle**: Simplified resource management and error handling
-- **Optimized for containers**: Purpose-built for container workloads
-- **Upcall support**: Direct VMM-to-Guest communication for efficient hotplug operations
-- **Low resource overhead**: Minimal CPU and memory footprint
-
-**Architecture:**
-```
-┌─────────────────────────────────────────┐
-│     Kata Containers Runtime (Rust)      │
-│  ┌─────────────────────────────────┐    │
-│  │      Dragonball VMM Library     │    │
-│  └─────────────────────────────────┘    │
-└─────────────────────────────────────────┘
-```
-
-**Features:**
-
-- Built-in virtio-fs/nydus support
-- Async I/O via Tokio
-- Single binary deployment
-- Optimized startup latency
-
-**Use Cases:**
-
-- Default choice for most container workloads
-- High-density container deployments and low resource overhead scenarios
-- Scenarios requiring optimal startup performance
-
-**Configuration:** See [`configuration-dragonball.toml`](../../src/runtime-rs/config/configuration-dragonball.toml.in)
-
-### Cloud Hypervisor/KVM
-
-Cloud Hypervisor is a Rust-based VMM designed for modern cloud workloads with a focus on performance and security.
-
-**Features:**
-
-- CPU and memory resize
-- Device hotplug (disk, VFIO)
-- virtio-fs (shared filesystem)
-- virtio-pmem (persistent memory)
-- virtio-block (block storage)
-- virtio-vsock (agent communication)
-- Fine-grained seccomp filters per VMM thread
-- HTTP OpenAPI for management
-
-**Use Cases:**
-
-- High-performance cloud-native workloads
-- Applications requiring memory/CPU resizing
-- Security-sensitive deployments (seccomp isolation)
-
-**Configuration:** See [`configuration-cloud-hypervisor.toml`](../../src/runtime-rs/config/configuration-cloud-hypervisor.toml.in)
+The Kata Containers VM starts with a minimum amount of resources, allowing for faster boot time and a reduction in memory footprint.  As the container launch progresses,
+devices are hotplugged to the VM. For example, when a CPU constraint is specified which includes additional CPUs, they can be hot added.  Kata Containers has support
+for hot-adding the following devices:
+- Virtio block
+- Virtio SCSI
+- VFIO
+- CPU
 
 ### Firecracker/KVM
 
-Firecracker is a minimalist VMM built on rust-vmm crates, optimized for serverless and FaaS workloads.
+Firecracker, built on many rust crates that are within [rust-VMM](https://github.com/rust-vmm),  has a very limited device model, providing a lighter
+footprint and attack surface, focusing on function-as-a-service like use cases. As a result, Kata Containers with Firecracker VMM supports a subset of the CRI API.
+Firecracker does not support file-system sharing, and as a result only block-based storage drivers are supported. Firecracker does not support device
+hotplug nor does it support VFIO. As a result, Kata Containers with Firecracker VMM does not support updating container resources after boot, nor
+does it support device passthrough.
 
-**Devices:**
+Devices used:
+- virtio VSOCK
+- virtio block
+- virtio net
 
-- virtio-vsock (agent communication)
-- virtio-block (block storage)
-- virtio-net (networking)
+### Cloud Hypervisor/KVM
 
-**Limitations:**
+[Cloud Hypervisor](https://github.com/cloud-hypervisor/cloud-hypervisor), based
+on [rust-vmm](https://github.com/rust-vmm), is designed to have a
+lighter footprint and smaller attack surface for running modern cloud
+workloads. Kata Containers with Cloud
+Hypervisor provides mostly complete compatibility with Kubernetes
+comparable to the QEMU configuration. As of the 1.12 and 2.0.0 release
+of Kata Containers, the Cloud Hypervisor configuration supports both CPU
+and memory resize, device hotplug (disk and VFIO), file-system sharing through virtio-fs,
+block-based volumes, booting from VM images backed by pmem device, and
+fine-grained seccomp filters for each VMM threads (e.g. all virtio
+device worker threads).
 
-- No filesystem sharing (virtio-fs not supported)
-- No device hotplug
-- No VFIO/passthrough support
-- No CPU/memory hotplug
-- Limited CRI API support
+Devices and features used:
+- virtio VSOCK or virtio serial
+- virtio block
+- virtio net
+- virtio fs
+- virtio pmem
+- VFIO
+- hotplug
+- seccomp filters
+- [HTTP OpenAPI](https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/vmm/src/api/openapi/cloud-hypervisor.yaml)
 
-**Use Cases:**
+### StratoVirt/KVM
 
-- Serverless/FaaS workloads
-- Single-tenant microVMs
-- Scenarios prioritizing minimal attack surface
+[StratoVirt](https://gitee.com/openeuler/stratovirt) is an enterprise-level open source VMM oriented to cloud data centers, implements a unified architecture to support Standard-VMs, containers and serverless (Micro-VM). StratoVirt has some competitive advantages, such as lightweight and low resource overhead, fast boot, hardware acceleration, and language-level security with Rust.
 
-**Configuration:** See [`configuration-fc.toml`](../../src/runtime/config/configuration-fc.toml.in)
+Currently, StratoVirt in Kata supports Micro-VM machine type, mainly focus on FaaS cases, supporting device hotplug (virtio block), file-system sharing through virtio fs and so on. Kata Containers with StratoVirt now use virtio-mmio bus as driver, and doesn't support CPU/memory resize nor VFIO, thus doesn't support updating container resources after booted.
 
-## Hypervisor Comparison Summary
+Devices and features used currently:
+- Micro-VM machine type for FaaS(mmio, no ACPI)
+- Virtual Socket(vhost VSOCK、virtio console)
+- Virtual Storage(virtio block, mmio)
+- Virtual Networking(virtio net, mmio)
+- Shared Filesystem(virtio fs)
+- Device Hotplugging(virtio block hotplug)
+- Entropy Source(virtio RNG)
+- QMP API
 
-| Feature | QEMU | Cloud Hypervisor | Firecracker | Dragonball |
-|---------|------|------------------|-------------|------------|
-| Maturity | Excellent | Good | Good | Good |
-| CRI Compatibility | Full | Full | Partial | Full |
-| Filesystem Sharing | ✓ | ✓ | ✗ | ✓ |
-| Device Hotplug | ✓ | ✓ | ✗ | ✓ |
-| VFIO/Passthrough | ✓ | ✓ | ✗ | ✓ |
-| CPU/Memory Hotplug | ✓ | ✓ | ✗ | ✓ |
-| Security Isolation | Good | Excellent (seccomp) | Excellent | Excellent |
-| Startup Latency | Good | Excellent | Excellent | Best |
-| Resource Overhead | Medium | Low | Lowest | Lowest |
+### Summary
 
-## Choosing a Hypervisor
-
-### Decision Matrix
-
-| Requirement | Recommended Hypervisor |
-|-------------|------------------------|
-| Full CRI API compatibility | QEMU, Cloud Hypervisor, Dragonball |
-| Device passthrough (VFIO) | QEMU, Cloud Hypervisor, Dragonball |
-| Minimal resource overhead | Dragonball, Firecracker |
-| Fastest startup time | Dragonball, Firecracker |
-| Serverless/FaaS | Dragonball, Firecracker |
-| Production workloads | Dragonball, QEMU |
-| Memory/CPU resizing | Dragonball, Cloud Hypervisor, QEMU |
-| Maximum security isolation | Cloud Hypervisor (seccomp), Firecracker, Dragonball |
-| Multi-architecture | QEMU |
-
-### Recommendations
-
-**For Most Users:** Use the default Dragonball VMM with the Kata Containers Rust runtime. It provides the best balance of performance, security, and container density.
-
-**For Device Passthrough:** Use QEMU, Cloud Hypervisor, or Dragonball if you require VFIO device assignment.
-
-**For Serverless:** Use Dragonball or Firecracker for ultra-lightweight, single-tenant microVMs.
-
-**For Legacy/Ecosystem Compatibility:** Use QEMU for its extensive hardware emulation and multi-architecture support.
-
-## Hypervisor Configuration
-
-### Configuration Files
-
-Each hypervisor has a dedicated configuration file:
-
-| Hypervisor | Rust Runtime Configuration | Go Runtime Configuration |
-|------------|----------------|-----------------|
-| QEMU |`configuration-qemu-runtime-rs.toml` |`configuration-qemu.toml` |
-| Cloud Hypervisor | `configuration-cloud-hypervisor.toml` | `configuration-clh.toml` |
-| Firecracker | `configuration-rs-fc.toml` | `configuration-fc.toml` |
-| Dragonball | `configuration-dragonball.toml` (default) | `No` |
-
-> **Note:** Configuration files are typically installed in `/opt/kata/share/defaults/kata-containers/` or  `/opt/kata/share/defaults/kata-containers/runtime-rs/` or `/usr/share/defaults/kata-containers/`.
-
-### Switching Hypervisors
-
-Use the `kata-manager` tool to switch the configured hypervisor:
-
-```bash
-# List available hypervisors
-$ kata-manager -L
-
-# Switch to a different hypervisor
-$ sudo kata-manager -S <hypervisor-name>
-```
-
-For detailed instructions, see the [`kata-manager` documentation](../../utils/README.md).
-
-## Hypervisor Versions
-
-The following versions are used in this release (from [versions.yaml](../../versions.yaml)):
-
-| Hypervisor | Version | Repository |
-|------------|---------|------------|
-| Cloud Hypervisor | v51.1 | https://github.com/cloud-hypervisor/cloud-hypervisor |
-| Firecracker | v1.12.1 | https://github.com/firecracker-microvm/firecracker |
-| QEMU | v10.2.1 | https://github.com/qemu/qemu |
-| Dragonball | builtin | https://github.com/kata-containers/kata-containers/tree/main/src/dragonball |
-
-> **Note:** Dragonball is integrated into the Kata Containers Rust runtime and does not have a separate version number.
-> For the latest hypervisor versions, see the [versions.yaml](../../versions.yaml) file in the Kata Containers repository.
-
-## References
-
-- [Kata Containers Architecture](./architecture/README.md)
-- [Configuration Guide](../../src/runtime/README.md#configuration)
-- [QEMU Documentation](https://www.qemu.org/documentation/)
-- [Cloud Hypervisor Documentation](https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/api.md)
-- [Firecracker Documentation](https://github.com/firecracker-microvm/firecracker/tree/main/docs)
-- [Dragonball Source](https://github.com/kata-containers/kata-containers/tree/main/src/dragonball)
-
-[KVM]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
-[QEMU]: https://www.qemu.org
-[Cloud Hypervisor]: https://github.com/cloud-hypervisor/cloud-hypervisor
-[Firecracker]: https://github.com/firecracker-microvm/firecracker
-[`Dragonball`]: https://github.com/kata-containers/kata-containers/tree/main/src/dragonball
+| Solution | release introduced | brief summary |
+|-|-|-|
+| Cloud Hypervisor | 1.10 | upstream Cloud Hypervisor with rich feature support, e.g. hotplug, VFIO and FS sharing|
+| Firecracker | 1.5 | upstream Firecracker, rust-VMM based, no VFIO, no FS sharing, no memory/CPU hotplug |
+| QEMU | 1.0 | upstream QEMU, with support for hotplug and filesystem sharing |
+| StratoVirt | 3.3 | upstream StratoVirt with FS sharing and virtio block hotplug, no VFIO, no CPU/memory resize |

docs/helm-configuration.md

@@ -1,264 +0,0 @@
-# Helm Configuration
-
-## Parameters
-
-The helm chart provides a comprehensive set of configuration options. You may view the parameters and their descriptions by going to the [GitHub source](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/values.yaml) or by using helm:
-
-```sh
-# List available kata-deploy chart versions:
-#   helm search repo kata-deploy-charts/kata-deploy --versions
-#
-# Then replace X.Y.Z below with the desired chart version:
-helm show values --version X.Y.Z oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy
-```
-
-### shims
-
-Kata ships with a number of pre-built artifacts and runtimes. You may selectively enable or disable specific shims. For example:
-
-```yaml title="values.yaml"
-shims:
-  disableAll: true
-  qemu:
-    enabled: true
-  qemu-nvidia-gpu:
-    enabled: true
-  qemu-nvidia-gpu-snp:
-    enabled: false
-
-```
-
-Shims can also have configuration options specific to them:
-
-```yaml
-  qemu-nvidia-gpu:
-    enabled: ~
-    supportedArches:
-      - amd64
-      - arm64
-    allowedHypervisorAnnotations: []
-    containerd:
-      snapshotter: ""
-    runtimeClass:
-      # This label is automatically added by gpu-operator. Override it
-      # if you want to use a different label.
-      # Uncomment once GPU Operator v26.3 is out
-      # nodeSelector:
-        # nvidia.com/cc.ready.state: "false"
-```
-
-It's best to reference the default `values.yaml` file above for more details.
-
-### Custom Runtimes
-
-Kata allows you to create custom runtime configurations. This is done by overlaying one of the pre-existing runtime configs with user-provided configs. For example, we can use the `qemu-nvidia-gpu` as a base config and overlay our own parameters to it:
-
-```yaml
-customRuntimes:
-  enabled: false
-  runtimes:
-    my-gpu-runtime:
-      baseConfig: "qemu-nvidia-gpu"  # Required: existing config to use as base
-      dropIn: |                      # Optional: overrides via config.d mechanism
-        [hypervisor.qemu]
-        default_memory = 1024
-        default_vcpus = 4
-      runtimeClass: |
-        kind: RuntimeClass
-        apiVersion: node.k8s.io/v1
-        metadata:
-          name: kata-my-gpu-runtime
-          labels:
-            app.kubernetes.io/managed-by: kata-deploy
-        handler: kata-my-gpu-runtime
-        overhead:
-          podFixed:
-            memory: "640Mi"
-            cpu: "500m"
-        scheduling:
-          nodeSelector:
-            katacontainers.io/kata-runtime: "true"
-      # Optional: CRI-specific configuration
-      containerd:
-        snapshotter: "nydus"  # Configure containerd snapshotter (nydus, erofs, etc.)
-      crio:
-        pullType: "guest-pull"  # Configure CRI-O runtime_pull_image = true
-```
-
-Again, view the default [`values.yaml`](#parameters) file for more details.
-
-## Examples
-
-We provide a few examples that you can pass to helm via the `-f`/`--values` flag.
-
-### [`try-kata-tee.values.yaml`](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/try-kata-tee.values.yaml)
-
-This file enables only the TEE (Trusted Execution Environment) shims for confidential computing:
-
-```sh
-helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-  --version VERSION \
-  -f try-kata-tee.values.yaml
-```
-
-Includes:
-
-- `qemu-snp` - AMD SEV-SNP (amd64)
-- `qemu-tdx` - Intel TDX (amd64)
-- `qemu-se` - IBM Secure Execution for Linux (SEL) (s390x)
-- `qemu-se-runtime-rs` - IBM Secure Execution for Linux (SEL) Rust runtime (s390x)
-- `qemu-cca` - Arm Confidential Compute Architecture (arm64)
-- `qemu-coco-dev` - Confidential Containers development (amd64, s390x)
-- `qemu-coco-dev-runtime-rs` - Confidential Containers development Rust runtime (amd64, s390x)
-
-### [`try-kata-nvidia-gpu.values.yaml`](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/try-kata-nvidia-gpu.values.yaml)
-
-This file enables only the NVIDIA GPU-enabled shims:
-
-```sh
-helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-  --version VERSION \
-  -f try-kata-nvidia-gpu.values.yaml
-```
-
-Includes:
-
-- `qemu-nvidia-gpu` - Standard NVIDIA GPU support (amd64, arm64)
-- `qemu-nvidia-gpu-snp` - NVIDIA GPU with AMD SEV-SNP (amd64)
-- `qemu-nvidia-gpu-tdx` - NVIDIA GPU with Intel TDX (amd64)
-
-### `nodeSelector`
-
-We can deploy Kata only to specific nodes using `nodeSelector`
-
-```sh
-# First, label the nodes where you want kata-containers to be installed
-$ kubectl label nodes worker-node-1 kata-containers=enabled
-$ kubectl label nodes worker-node-2 kata-containers=enabled
-
-# Then install the chart with `nodeSelector`
-$ helm install kata-deploy \
-  --set nodeSelector.kata-containers="enabled" \
-  "${CHART}" --version  "${VERSION}"
-```
-
-You can also use a values file:
-
-```yaml title="values.yaml"
-nodeSelector:
-  kata-containers: "enabled"
-  node-type: "worker"
-```
-
-```sh
-$ helm install kata-deploy -f values.yaml "${CHART}" --version "${VERSION}"
-```
-
-### Multiple Kata installations on the Same Node
-
-For debugging, testing and other use-case it is possible to deploy multiple
-versions of Kata on the very same node. All the needed artifacts are getting the
-`multiInstallSuffix` appended to distinguish each installation. **BEWARE** that one
-needs at least **containerd-2.0** since this version has drop-in conf support
-which is a prerequisite for the `multiInstallSuffix` to work properly.
-
-```sh
-$ helm install kata-deploy-cicd       \
-  -n kata-deploy-cicd                 \
-  --set env.multiInstallSuffix=cicd   \
-  --set env.debug=true                \
-  "${CHART}" --version  "${VERSION}"
-```
-
-Note: `runtimeClasses` are automatically created by Helm (via
-      `runtimeClasses.enabled=true`, which is the default).
-
-Now verify the installation by examining the `runtimeClasses`:
-
-```sh
-$ kubectl get runtimeClasses
-NAME                            HANDLER                         AGE
-kata-clh-cicd                   kata-clh-cicd                   77s
-kata-cloud-hypervisor-cicd      kata-cloud-hypervisor-cicd      77s
-kata-dragonball-cicd            kata-dragonball-cicd            77s
-kata-fc-cicd                    kata-fc-cicd                    77s
-kata-qemu-cicd                  kata-qemu-cicd                  77s
-kata-qemu-coco-dev-cicd         kata-qemu-coco-dev-cicd         77s
-kata-qemu-nvidia-gpu-cicd       kata-qemu-nvidia-gpu-cicd       77s
-kata-qemu-nvidia-gpu-snp-cicd   kata-qemu-nvidia-gpu-snp-cicd   77s
-kata-qemu-nvidia-gpu-tdx-cicd   kata-qemu-nvidia-gpu-tdx-cicd   76s
-kata-qemu-runtime-rs-cicd       kata-qemu-runtime-rs-cicd       77s
-kata-qemu-se-runtime-rs-cicd    kata-qemu-se-runtime-rs-cicd    77s
-kata-qemu-snp-cicd              kata-qemu-snp-cicd              77s
-kata-qemu-tdx-cicd              kata-qemu-tdx-cicd              77s
-kata-stratovirt-cicd            kata-stratovirt-cicd            77s
-```
-
-## RuntimeClass Node Selectors for TEE Shims
-
-**Manual configuration:** Any `nodeSelector` you set under `shims.<shim>.runtimeClass.nodeSelector`
-is **always applied** to that shim's RuntimeClass, whether or not NFD is present. Use this when
-you want to pin TEE workloads to specific nodes (e.g. without NFD, or with custom labels).
-
-**Auto-inject when NFD is present:** If you do *not* set a `runtimeClass.nodeSelector` for a
-TEE shim, the chart can **automatically inject** NFD-based labels when NFD is detected in the
-cluster (deployed by this chart with `node-feature-discovery.enabled=true` or found externally):
-
-- AMD SEV-SNP shims: `amd.feature.node.kubernetes.io/snp: "true"`
-- Intel TDX shims: `intel.feature.node.kubernetes.io/tdx: "true"`
-- IBM Secure Execution for Linux (SEL) shims (s390x): `feature.node.kubernetes.io/cpu-security.se.enabled: "true"`
-
-The chart uses Helm's `lookup` function to detect NFD (by looking for the
-`node-feature-discovery-worker` DaemonSet). Auto-inject only runs when NFD is detected and
-no manual `runtimeClass.nodeSelector` is set for that shim.
-
-**Note**: NFD detection requires cluster access. During `helm template` (dry-run without a
-cluster), external NFD is not seen, so auto-injected labels are not added. Manual
-`runtimeClass.nodeSelector` values are still applied in all cases.
-
-## Customizing Configuration with Drop-in Files
-
-When kata-deploy installs Kata Containers, the base configuration files should not
-be modified directly. Instead, use drop-in configuration files to customize
-settings. This approach ensures your customizations survive kata-deploy upgrades.
-
-### How Drop-in Files Work
-
-The Kata runtime reads the base configuration file and then applies any `.toml`
-files found in the `config.d/` directory alongside it. Files are processed in
-alphabetical order, with later files overriding earlier settings.
-
-### Creating Custom Drop-in Files
-
-To add custom settings, create a `.toml` file in the appropriate `config.d/`
-directory. Use a numeric prefix to control the order of application.
-
-**Reserved prefixes** (used by kata-deploy):
-
-- `10-*`: Core kata-deploy settings
-- `20-*`: Debug settings
-- `30-*`: Kernel parameters
-
-**Recommended prefixes for custom settings**: `50-89`
-
-### Drop-In Config Examples
-
-#### Adding Custom Kernel Parameters
-
-```bash
-# SSH into the node or use kubectl exec
-sudo mkdir -p /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/
-sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-custom.toml << 'EOF'
-[hypervisor.qemu]
-kernel_params = "my_param=value"
-EOF
-```
-
-#### Changing Default Memory Size
-
-```bash
-sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-memory.toml << 'EOF'
-[hypervisor.qemu]
-default_memory = 4096
-EOF
-```

docs/how-to/README.md

@@ -3,9 +3,9 @@
 ## Kubernetes Integration
 
 - [Run Kata containers with `crictl`](run-kata-with-crictl.md)
+- [Run Kata Containers with Kubernetes](run-kata-with-k8s.md)
 - [How to use Kata Containers and Containerd](containerd-kata.md)
 - [How to use Kata Containers and containerd with Kubernetes](how-to-use-k8s-with-containerd-and-kata.md)
-- [How to use Kata Containers and CRI-O with Kubernetes](how-to-use-k8s-with-crio-and-kata.md)
 - [Kata Containers and service mesh for Kubernetes](service-mesh.md)
 - [How to import Kata Containers logs into Fluentd](how-to-import-kata-logs-with-fluentd.md)
 
@@ -49,5 +49,4 @@
 - [How to use the Kata Agent Policy](how-to-use-the-kata-agent-policy.md)
 - [How to pull images in the guest](how-to-pull-images-in-guest-with-kata.md)
 - [How to use mem-agent to decrease the memory usage of Kata container](how-to-use-memory-agent.md)
-- [How to use seccomp with runtime-rs](how-to-use-seccomp-with-runtime-rs.md)
-- [How to use passthroughfd-IO with runtime-rs and Dragonball](how-to-use-passthroughfd-io-within-runtime-rs.md)
+- [How to use seccomp with runtime-rs](how-to-use-seccomp-with-runtime-rs.md)

docs/how-to/containerd-kata.md

@@ -1,29 +1,29 @@
 # How to use Kata Containers and Containerd
 
-This document covers the installation and configuration of [containerd](https://containerd.io/)
+This document covers the installation and configuration of [containerd](https://containerd.io/) 
 and [Kata Containers](https://katacontainers.io). The containerd provides not only the `ctr`
-command line tool, but also the [CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
+command line tool, but also the [CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) 
 interface for [Kubernetes](https://kubernetes.io) and other CRI clients.
 
-This document is primarily written for Kata Containers v3.28 or above, and containerd v1.7.0 or above.
+This document is primarily written for Kata Containers v1.5.0-rc2 or above, and containerd v1.2.0 or above. 
 Previous versions are addressed here, but we suggest users upgrade to the newer versions for better support.
 
 ## Concepts
 
 ### Kubernetes `RuntimeClass`
 
-[`RuntimeClass`](https://kubernetes.io/docs/concepts/containers/runtime-class/) is a Kubernetes feature first
-introduced in Kubernetes 1.12 as alpha. It is the feature for selecting the container runtime configuration to
-use to run a pod's containers. This feature is supported in `containerd` since [v1.2.0](https://github.com/containerd/containerd/releases/tag/v1.2.0).
+[`RuntimeClass`](https://kubernetes.io/docs/concepts/containers/runtime-class/) is a Kubernetes feature first 
+introduced in Kubernetes 1.12 as alpha. It is the feature for selecting the container runtime configuration to 
+use to run a pod’s containers. This feature is supported in `containerd` since [v1.2.0](https://github.com/containerd/containerd/releases/tag/v1.2.0).
 
 Before the `RuntimeClass` was introduced, Kubernetes was not aware of the difference of runtimes on the node. `kubelet`
 creates Pod sandboxes and containers through CRI implementations, and treats all the Pods equally. However, there
-are requirements to run trusted Pods (i.e. Kubernetes plugin) in a native container like runc, and to run untrusted
+are requirements to run trusted Pods (i.e. Kubernetes plugin) in a native container like runc, and to run untrusted 
 workloads with isolated sandboxes (i.e. Kata Containers).
 
 As a result, the CRI implementations extended their semantics for the requirements:
 
-- At the beginning, [`Frakti`](https://github.com/kubernetes/frakti) checks the network configuration of a Pod, and
+- At the beginning, [Frakti](https://github.com/kubernetes/frakti) checks the network configuration of a Pod, and
   treat Pod with `host` network as trusted, while others are treated as untrusted.
 - The containerd introduced an annotation for untrusted Pods since [v1.0](https://github.com/containerd/cri/blob/v1.0.0-rc.0/docs/config.md):
   ```yaml
@@ -32,17 +32,17 @@ As a result, the CRI implementations extended their semantics for the requiremen
   ```
 - Similarly, CRI-O introduced the annotation `io.kubernetes.cri-o.TrustedSandbox` for untrusted Pods.
 
-To eliminate the complexity of user configuration introduced by the non-standardized annotations and provide
-extensibility, `RuntimeClass` was introduced. This gives users the ability to affect the runtime behavior
-through `RuntimeClass` without the knowledge of the CRI daemons. We suggest that users with multiple runtimes
+To eliminate the complexity of user configuration introduced by the non-standardized annotations and provide 
+extensibility, `RuntimeClass` was introduced. This gives users the ability to affect the runtime behavior 
+through `RuntimeClass` without the knowledge of the CRI daemons. We suggest that users with multiple runtimes 
 use `RuntimeClass` instead of the deprecated annotations.
 
 ### Containerd Runtime V2 API: Shim V2 API
 
 The [`containerd-shim-kata-v2` (short as `shimv2` in this documentation)](../../src/runtime/cmd/containerd-shim-kata-v2/)
 implements the [Containerd Runtime V2 (Shim API)](https://github.com/containerd/containerd/tree/main/core/runtime/v2) for Kata.
-With `shimv2`, Kubernetes can launch Pod and OCI-compatible containers with one shim per Pod. Prior to `shimv2`, `2N+1`
-shims (i.e. a `containerd-shim` and a `kata-shim` for each container and the Pod sandbox itself) and no standalone `kata-proxy`
+With `shimv2`, Kubernetes can launch Pod and OCI-compatible containers with one shim per Pod. Prior to `shimv2`, `2N+1` 
+shims (i.e. a `containerd-shim` and a `kata-shim` for each container and the Pod sandbox itself) and no standalone `kata-proxy` 
 process were used, even with VSOCK not available.
 
 ![Kubernetes integration with shimv2](../design/arch-images/shimv2.svg)
@@ -87,7 +87,7 @@ $ popd
 
 ### Install `cri-tools`
 
-> **Note:** `cri-tools` is a set of tools for CRI used for development and testing. Users who only want
+> **Note:** `cri-tools` is a set of tools for CRI used for development and testing. Users who only want 
 > to use containerd with Kubernetes can skip the `cri-tools`.
 
 You can install the `cri-tools` from source code:
@@ -104,7 +104,7 @@ $ popd
 
 ### Configure containerd to use Kata Containers
 
-By default, the configuration of containerd is located at `/etc/containerd/config.toml`, and the
+By default, the configuration of containerd is located at `/etc/containerd/config.toml`, and the 
 `cri` plugins are placed in the following section:
 
 ```toml
@@ -123,56 +123,18 @@ The following sections outline how to add Kata Containers to the configurations.
 
 #### Kata Containers as a `RuntimeClass`
 
-For Kubernetes users, we suggest using `RuntimeClass` to select Kata Containers as the runtime for untrusted workloads. The configuration is as follows:
-
-- Kata Containers v3.28.0 or above
-- Containerd v1.7.0 or above
-- Kubernetes v1.33 or above
+For 
+- Kata Containers v1.5.0 or above (including `1.5.0-rc`)
+- Containerd v1.2.0 or above
+- Kubernetes v1.12.0 or above
 
 The `RuntimeClass` is suggested.
 
-The following example registers custom runtimes into containerd:
-
-You can check the detailed information about the configuration of containerd in the [Containerd config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md).
-
-+ In containerd 2.x
-
-```toml
-version = 3
-[plugins."io.containerd.cri.v1.runtime".containerd]
-  [plugins."io.containerd.cri.v1.runtime".containerd.runtimes]
-    [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.runc]
-      runtime_type = "io.containerd.runc.v2"
-    [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata]
-      runtime_type = "io.containerd.kata.v2"
-      [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata.options]
-        ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration.toml"
-```
-
-+ In containerd 1.7.x
-
-```toml
-version = 2
-[plugins."io.containerd.grpc.v1.cri".containerd]
-  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
-    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
-      runtime_type = "io.containerd.runc.v2"
-    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
-      runtime_type = "io.containerd.kata.v2"
-      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
-        ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration.toml"
-```
-
 The following configuration includes two runtime classes:
-
-- `plugins.<X>.containerd.runtimes.runc`: the runc, and it is the default runtime.
-- `plugins.<X>.containerd.runtimes.kata`: The function in containerd (reference [the document here](https://github.com/containerd/containerd/tree/main/core/runtime/v2))
-  where the dot-connected string `io.containerd.kata.v2` is translated to `containerd-shim-kata-v2` (i.e. the
-  binary name of the Kata implementation of [Containerd Runtime V2 (Shim API)](https://github.com/containerd/containerd/tree/main/core/runtime/v2)). By default, the `containerd-shim-kata-v2` (short of `shimv2`) binary will be installed under the path of `/usr/local/bin/`.
-
-And `<X>` is `io.containerd.cri.v1.runtime` for containerd v2.x and `io.containerd.grpc.v1.cri` for containerd v1.7.x.
-
-+ In containerd 1.7.x
+- `plugins.cri.containerd.runtimes.runc`: the runc, and it is the default runtime.
+- `plugins.cri.containerd.runtimes.kata`: The function in containerd (reference [the document here](https://github.com/containerd/containerd/tree/main/core/runtime/v2)) 
+  where the dot-connected string `io.containerd.kata.v2` is translated to `containerd-shim-kata-v2` (i.e. the 
+  binary name of the Kata implementation of [Containerd Runtime V2 (Shim API)](https://github.com/containerd/containerd/tree/main/core/runtime/v2)).
 
 ```toml
     [plugins.cri.containerd]
@@ -187,7 +149,7 @@ And `<X>` is `io.containerd.cri.v1.runtime` for containerd v2.x and `io.containe
             CriuPath = ""
             CriuWorkPath = ""
             IoGid = 0
-      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
+      [plugins.cri.containerd.runtimes.kata]
          runtime_type = "io.containerd.kata.v2"
          privileged_without_host_devices = true
          pod_annotations = ["io.katacontainers.*"]
@@ -196,93 +158,33 @@ And `<X>` is `io.containerd.cri.v1.runtime` for containerd v2.x and `io.containe
             ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration.toml"
 ```
 
-+ In containerd 2.x
-
-```toml
-    [plugins."io.containerd.cri.v1.runtime".containerd]
-      no_pivot = false
-    [plugins."io.containerd.cri.v1.runtime".containerd.runtimes]
-      [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.runc]
-         privileged_without_host_devices = false
-         runtime_type = "io.containerd.runc.v2"
-        [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.runc.options]
-            BinaryName = ""
-            CriuImagePath = ""
-            CriuPath = ""
-            CriuWorkPath = ""
-            IoGid = 0
-      [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata]
-         runtime_type = "io.containerd.kata.v2"
-         privileged_without_host_devices = true
-         pod_annotations = ["io.katacontainers.*"]
-         container_annotations = ["io.katacontainers.*"]
-         [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata.options]
-            ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration.toml"
-```
-
 `privileged_without_host_devices` tells containerd that a privileged Kata container should not have direct access to all host devices. If unset, containerd will pass all host devices to Kata container, which may cause security issues.
 
 `pod_annotations` is the list of pod annotations passed to both the pod sandbox as well as container through the OCI config.
 
 `container_annotations` is the list of container annotations passed through to the OCI config of the containers.
 
-This `ConfigPath` option is optional. If you want to use a different configuration file, you can specify the path of the configuration file with `ConfigPath` in the containerd configuration file. We use containerd 2.x configuration as an example here, and the configuration for containerd 1.7.x is similar, just replace `io.containerd.cri.v1.runtime` with `io.containerd.grpc.v1.cri`.
-
-```toml
-         [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata.options]
-            ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"
-```
-
-> **Note:** In this example, the specified `ConfigPath` is valid in Kubernetes/Containerd workflow with containerd v1.7+ but doesn't work with ctr and nerdctl.
-
-If you do not specify it, `shimv2` first tries to get the configuration file from the environment variable `KATA_CONF_FILE`. If you want to adopt this way, you should first create a shell script as `containerd-shim-kata-v2` which is placed under the path of `/usr/local/bin/`. The following is an example of the shell script `containerd-shim-kata-qemu-v2` which specifies the configuration file with `KATA_CONF_FILE`
-
-> **Note:** Just use containerd 2.x configuration as an example, the configuration for containerd 1.7.x is similar, just replace `io.containerd.cri.v1.runtime` with `io.containerd.grpc.v1.cri`
-
-```shell
-~$ cat /usr/local/bin/containerd-shim-kata-qemu-v2
-#!/bin/bash
-KATA_CONF_FILE=/opt/kata/share/defaults/kata-containers/configuration-qemu.toml /opt/kata/bin/containerd-shim-kata-v2 "$@"
-```
-
-And then just reference it in the configuration of containerd:
-
-```toml
-      [plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu]
-         runtime_type = "io.containerd.kata-qemu.v2"
-```
-
-Finally you can run a Kata container with the runtime `io.containerd.kata-qemu.v2`:
-
-```shell
-$ sudo ctr run --cni --runtime io.containerd.kata-qemu.v2 -t --rm docker.io/library/busybox:latest hello sh
-```
-
-> **Note:** The `KATA_CONF_FILE` environment variable is valid in both Kubernetes/Containerd workflow with containerd and containerd tools(ctr, nerdctl, etc.) scenarios.
-
-If neither are set, shimv2 will use the default Kata configuration file paths (`/etc/kata-containers/configuration.toml` and `/usr/share/defaults/kata-containers/configuration.toml` and `/opt/kata/share/defaults/kata-containers/configuration.toml`).
+This `ConfigPath` option is optional. If you do not specify it, shimv2 first tries to get the configuration file from the environment variable `KATA_CONF_FILE`. If neither are set, shimv2 will use the default Kata configuration file paths (`/etc/kata-containers/configuration.toml` and `/usr/share/defaults/kata-containers/configuration.toml`).
 
 #### Kata Containers as the runtime for untrusted workload
 
-For cases without `RuntimeClass` support, we can use the legacy annotation method to support using Kata Containers
-for an untrusted workload. With the following configuration, you can run trusted workloads with a runtime such as `runc`
-and then, run an untrusted workload with Kata Containers:
+For cases without `RuntimeClass` support, we can use the legacy annotation method to support using Kata Containers 
+for an untrusted workload. With the following configuration, you can run trusted workloads with a runtime such as `runc` 
+and then, run an untrusted workload with Kata Containers: 
 
 ```toml
-    [plugins."io.containerd.grpc.v1.cri".containerd]
-    # "plugins."io.containerd.grpc.v1.cri".containerd.default_runtime" is the runtime to use in containerd.
-    [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
+    [plugins.cri.containerd]
+    # "plugins.cri.containerd.default_runtime" is the runtime to use in containerd.
+    [plugins.cri.containerd.default_runtime]
       # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
       runtime_type = "io.containerd.runtime.v1.linux"
 
-    # "plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime" is a runtime to run untrusted workloads on it.
-    [plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
+    # "plugins.cri.containerd.untrusted_workload_runtime" is a runtime to run untrusted workloads on it.
+    [plugins.cri.containerd.untrusted_workload_runtime]
       # runtime_type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
       runtime_type = "io.containerd.kata.v2"
 ```
 
-> **Note:** The `untrusted_workload_runtime` is deprecated since containerd v1.7.0, and it is recommended to use `RuntimeClass` instead.
-
 You can find more information on the [Containerd config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 
 #### Kata Containers as the default runtime
@@ -290,8 +192,8 @@ You can find more information on the [Containerd config documentation](https://g
 If you want to set Kata Containers as the only runtime in the deployment, you can simply configure as follows:
 
 ```toml
-    [plugins."io.containerd.grpc.v1.cri".containerd]
-    [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
+    [plugins.cri.containerd]
+    [plugins.cri.containerd.default_runtime]
       runtime_type = "io.containerd.kata.v2"
 ```
 
@@ -299,9 +201,9 @@ If you want to set Kata Containers as the only runtime in the deployment, you ca
 
 > **Note:** If you skipped the [Install `cri-tools`](#install-cri-tools) section, you can skip this section too.
 
-First, add the CNI configuration in the containerd configuration.
+First, add the CNI configuration in the containerd configuration. 
 
-The following is the configuration if you installed CNI as the *[Install CNI plugins](#install-cni-plugins)* section outlined.
+The following is the configuration if you installed CNI as the *[Install CNI plugins](#install-cni-plugins)* section outlined. 
 
 Put the CNI configuration as `/etc/cni/net.d/10-mynet.conf`:
 
@@ -344,14 +246,11 @@ debug: true
 
 ### Launch containers with `ctr` command line
 
-> **Note:** With containerd command tool `ctr`, the `ConfigPath` is not supported, and the configuration file should be explicitly specified with the option `--runtime-config-path`, otherwise, it'll use the default configurations.
-
 To run a container with Kata Containers through the containerd command line, you can run the following:
 
 ```bash
 $ sudo ctr image pull docker.io/library/busybox:latest
-$ CONFIG_PATH="/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"
-$ sudo ctr run --cni --runtime io.containerd.kata.v2 --runtime-config-path $CONFIG_PATH -t --rm docker.io/library/busybox:latest hello sh
+$ sudo ctr run --cni --runtime io.containerd.run.kata.v2 -t --rm docker.io/library/busybox:latest hello sh
 ```
 
 This launches a BusyBox container named `hello`, and it will be removed by `--rm` after it quits.
@@ -361,9 +260,7 @@ loopback interface is created.
 ### Launch containers using `ctr` command line with rootfs bundle
 
 #### Get rootfs
-
 Use the script to create rootfs
-
 ```bash
 ctr i pull quay.io/prometheus/busybox:latest
 ctr i export rootfs.tar quay.io/prometheus/busybox:latest
@@ -381,9 +278,7 @@ for ((i=0;i<$(cat ${layers_dir}/manifest.json | jq -r ".[].Layers | length");i++
   tar -C ${rootfs_dir} -xf ${layers_dir}/$(cat ${layers_dir}/manifest.json | jq -r ".[].Layers[${i}]")
 done
 ```
-
 #### Get `config.json`
-
 Use runc spec to generate `config.json`
 ```bash
 cd ./bundle/rootfs
@@ -400,13 +295,10 @@ Change the root `path` in `config.json` to the absolute path of rootfs
 ```
 
 #### Run container
-
 ```bash
-CONFIG_PATH="/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"
-sudo ctr run -d --runtime io.containerd.kata.v2 --runtime-config-path $CONFIG_PATH --config bundle/config.json hello
+sudo ctr run -d --runtime io.containerd.run.kata.v2 --config bundle/config.json hello
 sudo ctr t exec --exec-id ${ID} -t hello sh
 ```
-
 ### Launch Pods with `crictl` command line
 
 With the `crictl` command line of `cri-tools`, you can specify runtime class with `-r` or `--runtime` flag.
@@ -432,7 +324,7 @@ $ sudo crictl start 1aab7585530e6
 1aab7585530e6
 ```
 
-In Kubernetes, you need to create a `RuntimeClass` resource and add the `RuntimeClass` field in the Pod Spec
+In Kubernetes, you need to create a `RuntimeClass` resource and add the `RuntimeClass` field in the Pod Spec 
 (see this [document](https://kubernetes.io/docs/concepts/containers/runtime-class/) for more information).
 
 If `RuntimeClass` is not supported, you can use the following annotation in a Kubernetes pod to identify as an untrusted workload:

docs/how-to/data/dashboard.json

@@ -3358,4 +3358,4 @@
   "title": "Kata containers",
   "uid": "75pdqURGk",
   "version": 1
-}
+}

docs/how-to/data/kata-monitor-daemonset.yml

@@ -27,7 +27,7 @@ spec:
       containers:
       - name: kata-monitor
         image: quay.io/kata-containers/kata-monitor:2.0.0
-        args:
+        args: 
           - -log-level=debug
         ports:
           - containerPort: 8090

docs/how-to/data/prometheus.yml

@@ -79,7 +79,7 @@ metadata:
 spec:
   replicas: 1
   selector:
-    matchLabels:
+    matchLabels: 
       app: prometheus
   template:
     metadata:

docs/how-to/how-to-pull-images-in-guest-with-kata.md

@@ -16,7 +16,7 @@ To pull images in the guest, we need to do the following steps:
 
 ### Delete images used for pulling in the guest
 
-Though the `CRI Runtime Specific Snapshotter` is still an [experimental feature](https://github.com/containerd/containerd/blob/main/RELEASES.md#experimental-features) in containerd, which containerd is not supported to manage the same image in different `snapshotters`(The default `snapshotter` in containerd is `overlayfs`). To avoid errors caused by this, it is recommended to delete images (including the pause image) in containerd that needs to be pulled in guest later before configuring `nydus snapshotter` in containerd.
+Though the `CRI Runtime Specific Snapshotter` is still an [experimental feature](https://github.com/containerd/containerd/blob/main/RELEASES.md#experimental-features) in containerd, which containerd is not supported to manage the same image in different `snapshotters`(The default `snapshotter` in containerd is `overlayfs`). To avoid errors caused by this, it is recommended to delete images (including the pause image) in containerd that needs to be pulled in guest later before configuring `nydus snapshotter` in containerd. 
 
 ### Install `nydus snapshotter`
 
@@ -24,7 +24,7 @@ Though the `CRI Runtime Specific Snapshotter` is still an [experimental feature]
 
 To use DaemonSet to install `nydus snapshotter`, we need to ensure that `yq` exists in the host.
 
-1. Download `nydus snapshotter` repo
+1. Download `nydus snapshotter` repo 
 ```bash
 $ nydus_snapshotter_install_dir="/tmp/nydus-snapshotter"
 $ nydus_snapshotter_url=https://github.com/containerd/nydus-snapshotter
@@ -42,7 +42,7 @@ $ yq -i \
 $ yq -i \
 >	 'data.ENABLE_CONFIG_FROM_VOLUME = "false"' -P \
 >	 misc/snapshotter/base/nydus-snapshotter.yaml
-# Enable to run snapshotter as a systemd service
+# Enable to run snapshotter as a systemd service 
 # (skip if you want to run nydus snapshotter as a standalone process)
 $ yq -i \
 >	 'data.ENABLE_SYSTEMD_SERVICE = "true"' -P \
@@ -79,7 +79,7 @@ Created symlink /etc/systemd/system/multi-user.target.wants/nydus-snapshotter.se
 
 #### Install `nydus snapshotter` manually
 
-1. Download `nydus snapshotter` binary from release
+1. Download `nydus snapshotter` binary from release 
 ```bash
 $ ARCH=$(uname -m)
 $ golang_arch=$(case "$ARCH" in
@@ -111,7 +111,7 @@ level=info msg="Run daemons monitor..."
 Configure `nydus snapshotter` to enable `CRI Runtime Specific Snapshotter` in containerd. This ensures run kata containers with `nydus snapshotter`. Below, the steps are illustrated using `kata-qemu` as an example.
 
 ```toml
-# Modify containerd configuration to ensure that the following lines appear in the containerd configuration
+# Modify containerd configuration to ensure that the following lines appear in the containerd configuration 
 # (Assume that the containerd config is located in /etc/containerd/config.toml)
 
 [plugins."io.containerd.grpc.v1.cri".containerd]
@@ -124,7 +124,7 @@ Configure `nydus snapshotter` to enable `CRI Runtime Specific Snapshotter` in co
   snapshotter = "nydus"
 ```
 
-> **Notes:**
+> **Notes:** 
 > The `CRI Runtime Specific Snapshotter` feature only works for containerd v1.7.0 and above. So for Containerd v1.7.0 below, in addition to the above settings, we need to set the global `snapshotter` to `nydus` in containerd config. For example:
 
 ```toml
@@ -280,7 +280,7 @@ quay.io/confidential-containers/test-images               largeimage
 ```bash
 $ lsblk --fs
 NAME                 FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
-sda
+sda                                                   
 └─encrypted_disk_GsLDt
                                           178M    87% /run/kata-containers/image
 
@@ -309,4 +309,4 @@ $ free -m
               total        used        free      shared  buff/cache   available
 Mem:           1989          52          43           0        1893        1904
 Swap:             0           0           0
-```
+```

docs/how-to/how-to-run-kata-containers-with-SNP-VMs.md

@@ -18,7 +18,7 @@ The host kernel must be equal to or later than upstream version [6.11](https://c
 
 [`sev-utils`](https://github.com/amd/sev-utils/blob/coco-202501150000/docs/snp.md) is an easy way to install the required host kernel with the `setup-host` command. However, it will also build compatible guest kernel, OVMF, and QEMU components which are not necessary as these components are packaged with kata. The `sev-utils` script utility can be used with these additional components to test the memory encrypted launch and attestation of a base QEMU SNP guest.
 
-For a simplified way to build just the upstream compatible host kernel, use the Confidential Containers fork of [`amdese-amdsev`](https://github.com/confidential-containers/amdese-amdsev/tree/amd-snp-202501150000). Individual components can be built by running the following command:
+For a simplified way to build just the upstream compatible host kernel, use the Confidential Containers fork of [AMDESE AMDSEV](https://github.com/confidential-containers/amdese-amdsev/tree/amd-snp-202501150000). Individual components can be built by running the following command:
 
 ```
 ./build.sh kernel host --install
@@ -65,7 +65,7 @@ $ ./configure --enable-virtfs --target-list=x86_64-softmmu --enable-debug
 $ make -j "$(nproc)"
 $ popd
 ```
-- Create cert-chain for SNP attestation ( using [`snphost`](https://github.com/virtee/snphost/blob/main/docs/snphost.1.adoc) )
+- Create cert-chain for SNP attestation ( using [snphost](https://github.com/virtee/snphost/blob/main/docs/snphost.1.adoc) )
 ```bash
 $ git clone https://github.com/virtee/snphost.git && cd snphost/
 $ cargo build
@@ -96,10 +96,6 @@ path = "/path/to/qemu/build/qemu-system-x86_64"
 ```toml
 shared_fs = "virtio-9p"
 ```
-- Use `blockfile` snapshotter: Since virtio-fs remains unsupported due to bugs in QEMU snp-v3, and virtio-9p is no longer supported in runtime-rs, it is recommended to use the blockfile snapshotter. This allows container images to be managed via block devices without relying on a shared file system. To enable this, set the `snapshotter` to `blockfile` in the containerd config file, please refer to [blockfile guide](https://github.com/containerd/containerd/blob/main/docs/snapshotters/blockfile.md) for more information. Additionally, shared_fs should be set to "none" since no shared file system is used.
-```toml
-shared_fs = "none"
-```
 - Disable `virtiofsd` since it is no longer required (comment out)
 ```toml
 # virtio_fs_daemon = "/usr/libexec/virtiofsd"
@@ -182,3 +178,4 @@ sudo reboot
 ```bash
 sudo rmmod kvm_amd && sudo modprobe kvm_amd sev_snp=0
 ```
+

docs/how-to/how-to-run-kata-containers-with-kinds-of-Block-Volumes.md

@@ -10,19 +10,19 @@ Currently, there is no widely applicable and convenient method available for use
 
 ## Solution
 
-According to the proposal, it requires to use the `kata-ctl direct-volume` command to add a direct assigned block volume device to the Kata Containers runtime.
+According to the proposal, it requires to use the `kata-ctl direct-volume` command to add a direct assigned block volume device to the Kata Containers runtime. 
 
-And then with the help of method [get_volume_mount_info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L95), get information from JSON file: `(mountInfo.json)` and parse them into structure [Direct Volume Info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L70) which is used to save device-related information.
+And then with the help of method [get_volume_mount_info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L95), get information from JSON file: `(mountinfo.json)` and parse them into structure [Direct Volume Info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L70) which is used to save device-related information. 
 
-We only fill the `mountInfo.json`, such as `device` ,`volume-type`, `fstype`, `metadata` and `options`, which correspond to the fields in [Direct Volume Info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L70), to describe a device.
+We only fill the `mountinfo.json`, such as `device` ,`volume_type`, `fs_type`, `metadata` and `options`, which correspond to the fields in [Direct Volume Info](https://github.com/kata-containers/kata-containers/blob/099b4b0d0e3db31b9054e7240715f0d7f51f9a1c/src/libs/kata-types/src/mount.rs#L70), to describe a device. 
 
-The JSON file `mountInfo.json` placed in a sub-path `/kubelet/kata-test-vol-001/volume001` which under fixed path `/run/kata-containers/shared/direct-volumes/`.
-And the full path looks like: `/run/kata-containers/shared/direct-volumes/kubelet/kata-test-vol-001/volume001`, But for some security reasons. it is
+The JSON file `mountinfo.json` placed in a sub-path `/kubelet/kata-test-vol-001/volume001` which under fixed path `/run/kata-containers/shared/direct-volumes/`. 
+And the full path looks like: `/run/kata-containers/shared/direct-volumes/kubelet/kata-test-vol-001/volume001`, But for some security reasons. it is 
 encoded as `/run/kata-containers/shared/direct-volumes/L2t1YmVsZXQva2F0YS10ZXN0LXZvbC0wMDEvdm9sdW1lMDAx`.
 
-Finally, when running a Kata Containers with `ctr run --mount type=X, src=Y, dst=Z,,options=rbind:rw`, the `type=X` should be specified a proprietary type specifically designed for some kind of volume.
+Finally, when running a Kata Containers with `ctr run --mount type=X, src=Y, dst=Z,,options=rbind:rw`, the `type=X` should be specified a proprietary type specifically designed for some kind of volume. 
 
-Now, supported types:
+Now, supported types: 
 
 - `directvol` for direct volume
 - `vfiovol` for VFIO device based volume
@@ -46,19 +46,19 @@ $ sudo mkfs.ext4 /tmp/stor/rawdisk01.20g
 
 ```json
 {
-  "device": "/tmp/stor/rawdisk01.20g",
-  "volume-type": "directvol",
-  "fstype": "ext4",
-  "metadata":"{}",
+  "device": "/tmp/stor/rawdisk01.20g", 
+  "volume_type": "directvol", 
+  "fs_type": "ext4", 
+  "metadata":"{}", 
   "options": []
 }
 ```
 
 ```bash
-$ sudo kata-ctl direct-volume add /kubelet/kata-direct-vol-002/directvol002 "{\"device\": \"/tmp/stor/rawdisk01.20g\", \"volume-type\": \"directvol\", \"fstype\": \"ext4\", \"metadata\":"{}", \"options\": []}"
+$ sudo kata-ctl direct-volume add /kubelet/kata-direct-vol-002/directvol002 "{\"device\": \"/tmp/stor/rawdisk01.20g\", \"volume_type\": \"directvol\", \"fs_type\": \"ext4\", \"metadata\":"{}", \"options\": []}"
 $# /kubelet/kata-direct-vol-002/directvol002 <==> /run/kata-containers/shared/direct-volumes/W1lMa2F0ZXQva2F0YS10a2F0DAxvbC0wMDEvdm9sdW1lMDAx
-$ cat W1lMa2F0ZXQva2F0YS10a2F0DAxvbC0wMDEvdm9sdW1lMDAx/mountInfo.json
-{"volume-type":"directvol","device":"/tmp/stor/rawdisk01.20g","fstype":"ext4","metadata":{},"options":[]}
+$ cat W1lMa2F0ZXQva2F0YS10a2F0DAxvbC0wMDEvdm9sdW1lMDAx/mountInfo.json 
+{"volume_type":"directvol","device":"/tmp/stor/rawdisk01.20g","fs_type":"ext4","metadata":{},"options":[]}
 ```
 
 #### Run a Kata container with direct block device volume
@@ -76,11 +76,11 @@ $ sudo ctr run -t --rm --runtime io.containerd.kata.v2 --mount type=directvol,sr
 > **Tip:** It only supports `vfio-pci` based PCI device passthrough mode.
 
 In this scenario, the device's host kernel driver will be replaced by `vfio-pci`, and IOMMU group ID generated.
-And either device's BDF or its VFIO IOMMU group ID in `/dev/vfio/` is fine for "device" in `mountInfo.json`.
+And either device's BDF or its VFIO IOMMU group ID in `/dev/vfio/` is fine for "device" in `mountinfo.json`.
 
 ```bash
-$ lspci -nn -k -s 45:00.1
-45:00.1 SCSI storage controller
+$ lspci -nn -k -s 45:00.1 
+45:00.1 SCSI storage controller 
 ...
 Kernel driver in use: vfio-pci
 ...
@@ -92,16 +92,16 @@ $ ls /sys/kernel/iommu_groups/110/devices/
 
 #### setup VFIO device for kata-containers
 
-First, configure the `mountInfo.json`, as below:
+First, configure the `mountinfo.json`, as below:
 
 - (1) device with `BB:DD:F`
 
 ```json
 {
   "device": "45:00.1",
-  "volume-type": "vfiovol",
-  "fstype": "ext4",
-  "metadata":"{}",
+  "volume_type": "vfiovol", 
+  "fs_type": "ext4", 
+  "metadata":"{}", 
   "options": []
 }
 ```
@@ -111,9 +111,9 @@ First, configure the `mountInfo.json`, as below:
 ```json
 {
   "device": "0000:45:00.1",
-  "volume-type": "vfiovol",
-  "fstype": "ext4",
-  "metadata":"{}",
+  "volume_type": "vfiovol", 
+  "fs_type": "ext4", 
+  "metadata":"{}", 
   "options": []
 }
 ```
@@ -122,10 +122,10 @@ First, configure the `mountInfo.json`, as below:
 
 ```json
 {
-  "device": "/dev/vfio/110",
-  "volume-type": "vfiovol",
-  "fstype": "ext4",
-  "metadata":"{}",
+  "device": "/dev/vfio/110", 
+  "volume_type": "vfiovol", 
+  "fs_type": "ext4", 
+  "metadata":"{}", 
   "options": []
 }
 ```
@@ -133,10 +133,10 @@ First, configure the `mountInfo.json`, as below:
 Second, run kata-containers with device(`/dev/vfio/110`) as an example:
 
 ```bash
-$ sudo kata-ctl direct-volume add /kubelet/kata-vfio-vol-003/vfiovol003 "{\"device\": \"/dev/vfio/110\", \"volume-type\": \"vfiovol\", \"fstype\": \"ext4\", \"metadata\":"{}", \"options\": []}"
+$ sudo kata-ctl direct-volume add /kubelet/kata-vfio-vol-003/vfiovol003 "{\"device\": \"/dev/vfio/110\", \"volume_type\": \"vfiovol\", \"fs_type\": \"ext4\", \"metadata\":"{}", \"options\": []}"
 $ # /kubelet/kata-vfio-vol-003/directvol003 <==> /run/kata-containers/shared/direct-volumes/F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx
-$ cat F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx/mountInfo.json
-{"volume-type":"vfiovol","device":"/dev/vfio/110","fstype":"ext4","metadata":{},"options":[]}
+$ cat F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx/mountInfo.json 
+{"volume_type":"vfiovol","device":"/dev/vfio/110","fs_type":"ext4","metadata":{},"options":[]}
 ```
 
 #### Run a Kata container with VFIO block device based volume
@@ -190,25 +190,25 @@ be passed to Hypervisor, such as Dragonball, Cloud-Hypervisor, Firecracker or QE
 
 First, `mkdir` a sub-path `kubelet/kata-test-vol-001/` under `/run/kata-containers/shared/direct-volumes/`.
 
-Second, fill fields in `mountInfo.json`, it looks like as below:
+Second, fill fields in `mountinfo.json`, it looks like as below:
 ```json
 {
   "device": "/tmp/vhu-targets/vhost-blk-rawdisk01.sock",
-  "volume-type": "spdkvol",
-  "fstype": "ext4",
+  "volume_type": "spdkvol",
+  "fs_type": "ext4",
   "metadata":"{}",
   "options": []
 }
 ```
 
-Third, with the help of `kata-ctl direct-volume` to add block device to generate `mountInfo.json`, and run a kata container with `--mount`.
+Third, with the help of `kata-ctl direct-volume` to add block device to generate `mountinfo.json`, and run a kata container with `--mount`.
 
 ```bash
 $ # kata-ctl direct-volume add
-$ sudo kata-ctl direct-volume add /kubelet/kata-test-vol-001/volume001 "{\"device\": \"/tmp/vhu-targets/vhost-blk-rawdisk01.sock\", \"volume-type\":\"spdkvol\", \"fstype\": \"ext4\", \"metadata\":"{}", \"options\": []}"
+$ sudo kata-ctl direct-volume add /kubelet/kata-test-vol-001/volume001 "{\"device\": \"/tmp/vhu-targets/vhost-blk-rawdisk01.sock\", \"volume_type\":\"spdkvol\", \"fs_type\": \"ext4\", \"metadata\":"{}", \"options\": []}"
 $ # /kubelet/kata-test-vol-001/volume001 <==> /run/kata-containers/shared/direct-volumes/L2t1YmVsZXQva2F0YS10ZXN0LXZvbC0wMDEvdm9sdW1lMDAx
 $ cat L2t1YmVsZXQva2F0YS10ZXN0LXZvbC0wMDEvdm9sdW1lMDAx/mountInfo.json
-$ {"volume-type":"spdkvol","device":"/tmp/vhu-targets/vhost-blk-rawdisk01.sock","fstype":"ext4","metadata":{},"options":[]}
+$ {"volume_type":"spdkvol","device":"/tmp/vhu-targets/vhost-blk-rawdisk01.sock","fs_type":"ext4","metadata":{},"options":[]}
 ```
 
 As `/run/kata-containers/shared/direct-volumes/` is a fixed path , we will be able to run a kata pod with `--mount` and set

docs/how-to/how-to-run-rootless-vmm.md

@@ -1,5 +1,5 @@
 ## Introduction
-To improve security, Kata Container supports running the VMM process (QEMU and cloud-hypervisor) as a non-`root` user.
+To improve security, Kata Container supports running the VMM process (QEMU and cloud-hypervisor) as a non-`root` user. 
 This document describes how to enable the rootless VMM mode and its limitations.
 
 ## Pre-requisites
@@ -20,8 +20,8 @@ By default, the VMM process still runs as the root user. There are two ways to e
 2. Set the Kubernetes annotation `io.katacontainers.hypervisor.rootless` to `true`.
 
 ## Implementation details
-When `rootless` flag is enabled, upon a request to create a Pod, Kata Containers runtime creates a random user and group (e.g. `kata-123`), and uses them to start the hypervisor process.
-The `kvm` group is also given to the hypervisor process as a supplemental group to give the hypervisor process access to the `/dev/kvm` device.
+When `rootless` flag is enabled, upon a request to create a Pod, Kata Containers runtime creates a random user and group (e.g. `kata-123`), and uses them to start the hypervisor process. 
+The `kvm` group is also given to the hypervisor process as a supplemental group to give the hypervisor process access to the `/dev/kvm` device. 
 Another necessary change is to move the hypervisor runtime files (e.g. `vhost-fs.sock`, `qmp.sock`) to a directory (under `/run/user/[uid]/`) where only the non-root hypervisor has access to.
 
 ## Limitations
@@ -30,4 +30,4 @@ Another necessary change is to move the hypervisor runtime files (e.g. `vhost-fs
 2. Currently, this feature is only supported in QEMU and cloud-hypervisor. For firecracker, you can use jailer to run the VMM process with a non-root user.
 3. Certain features will not work when rootless VMM is enabled, including:
    1. Passing devices to the guest (`virtio-blk`, `virtio-scsi`) will not work if the non-privileged user does not have permission to access it (leading to a permission denied error). A more permissive permission (e.g. 666) may overcome this issue. However, you need to be aware of the potential security implications of reducing the security on such devices.
-   2. `vfio` device will also not work because of permission denied error.
+   2. `vfio` device will also not work because of permission denied error.

docs/how-to/how-to-set-prometheus-in-k8s.md

@@ -17,7 +17,7 @@ You must have a running Kubernetes cluster first. If not, [install a Kubernetes
 Also you should ensure that `kubectl` working correctly.
 
 > **Note**: More information about Kubernetes integrations:
->   - [Run Kata Containers with Kubernetes](how-to-use-k8s-with-crio-and-kata.md)
+>   - [Run Kata Containers with Kubernetes](run-kata-with-k8s.md)
 >   - [How to use Kata Containers and Containerd](containerd-kata.md)
 >   - [How to use Kata Containers and containerd with Kubernetes](how-to-use-k8s-with-containerd-and-kata.md)
 

docs/how-to/how-to-set-sandbox-config-kata.md

@@ -46,8 +46,6 @@ There are several kinds of Kata configurations and they are listed below.
 | `io.katacontainers.config.hypervisor.block_device_cache_noflush` | `boolean` | Denotes whether flush requests for the device are ignored |
 | `io.katacontainers.config.hypervisor.block_device_cache_set` | `boolean` | cache-related options will be set to block devices or not |
 | `io.katacontainers.config.hypervisor.block_device_driver` | string | the driver to be used for block device, valid values are `virtio-blk`, `virtio-scsi`, `nvdimm`|
-| `io.katacontainers.config.hypervisor.blk_logical_sector_size` | uint32 | logical sector size in bytes reported by block devices to the guest (0 = hypervisor default, must be a power of 2 between 512 and 65536) |
-| `io.katacontainers.config.hypervisor.blk_physical_sector_size` | uint32 | physical sector size in bytes reported by block devices to the guest (0 = hypervisor default, must be a power of 2 between 512 and 65536) |
 | `io.katacontainers.config.hypervisor.cpu_features` | `string` | Comma-separated list of CPU features to pass to the CPU (QEMU) |
 | `io.katacontainers.config.hypervisor.default_max_vcpus` | uint32| the maximum number of vCPUs allocated for the VM by the hypervisor |
 | `io.katacontainers.config.hypervisor.default_memory` | uint32| the memory assigned for a VM by the hypervisor in `MiB` |
@@ -61,7 +59,7 @@ There are several kinds of Kata configurations and they are listed below.
 | `io.katacontainers.config.hypervisor.enable_iothreads` | `boolean`| enable IO to be processed in a separate thread. Supported currently for virtio-`scsi` driver |
 | `io.katacontainers.config.hypervisor.enable_mem_prealloc` | `boolean` | the memory space used for `nvdimm` device by the hypervisor |
 | `io.katacontainers.config.hypervisor.enable_vhost_user_store` | `boolean` | enable vhost-user storage device (QEMU) |
-| `io.katacontainers.config.hypervisor.vhost_user_reconnect_timeout_sec` | `string`| the timeout for reconnecting vhost user socket (QEMU)
+| `io.katacontainers.config.hypervisor.vhost_user_reconnect_timeout_sec` | `string`| the timeout for reconnecting vhost user socket (QEMU) 
 | `io.katacontainers.config.hypervisor.enable_virtio_mem` | `boolean` | enable virtio-mem (QEMU) |
 | `io.katacontainers.config.hypervisor.entropy_source` (R) | string| the path to a host source of entropy (`/dev/random`, `/dev/urandom` or real hardware RNG device) |
 | `io.katacontainers.config.hypervisor.file_mem_backend` (R) | string | file based memory backend root directory |

docs/how-to/how-to-use-k8s-with-containerd-and-kata.md

@@ -19,7 +19,7 @@ The Kubernetes cluster will use the
 
 ## Install and configure containerd
 
-First, follow the [How to use Kata Containers and Containerd](containerd-kata.md) to install and configure containerd.
+First, follow the [How to use Kata Containers and Containerd](containerd-kata.md) to install and configure containerd. 
 Then, make sure the containerd works with the [examples in it](containerd-kata.md#run).
 
 ## Install and configure Kubernetes
@@ -44,13 +44,11 @@ In order to allow Kubelet to use containerd (using the CRI interface), configure
   ```bash
   $ sudo mkdir -p  /etc/systemd/system/kubelet.service.d/
   $ cat << EOF | sudo tee  /etc/systemd/system/kubelet.service.d/0-containerd.conf
-  [Service]
+  [Service]                                                 
   Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
   EOF
   ```
 
-  For Kata Containers (and especially CoCo / Confidential Containers tests), use at least `--runtime-request-timeout=600s` (10m) so CRI CreateContainerRequest does not time out.
-
 - Inform systemd about the new configuration
 
   ```bash
@@ -184,7 +182,7 @@ If a pod has the `runtimeClassName` set to `kata`, the CRI runs the pod with the
     containers:
     - name: nginx
       image: nginx
-
+      
   EOF
   ```
 

docs/how-to/how-to-use-memory-agent.md

@@ -315,7 +315,7 @@ $ kata-agent-ctl connect --server-address "unix:///var/run/kata/$PODID/root/kata
 ### compact_threshold
 Control the mem-agent compaction function compact threshold.<br>
 compact_threshold is the pages number.<br>
-When examining the `/proc/pagetypeinfo`, if there's an increase in the number of movable pages of orders smaller than the compact_order compared to the amount following the previous compaction period, and this increase surpasses a certain threshold specifically, more than compact_threshold number of pages, or the number of free pages has decreased by compact_threshold since the previous compaction. Current compact run period will not do compaction because there is no enough fragmented pages to be compaction.<br>
+When examining the /proc/pagetypeinfo, if there's an increase in the number of movable pages of orders smaller than the compact_order compared to the amount following the previous compaction period, and this increase surpasses a certain threshold specifically, more than compact_threshold number of pages, or the number of free pages has decreased by compact_threshold since the previous compaction. Current compact run period will not do compaction because there is no enough fragmented pages to be compaction.<br>
 This design aims to minimize the impact of unnecessary compaction calls on system performance.<br>
 Default to 1024.
 

docs/how-to/how-to-use-passthroughfd-io-within-runtime-rs.md

@@ -1,159 +0,0 @@
-# How to Use Passthrough-FD IO within Runtime-rs and Dragonball
-
-This document describes the Passthrough-FD (pass-fd) technology implemented in Kata Containers to optimize IO performance. By bypassing the intermediate proxy layers, this technology significantly reduces latency and CPU overhead for container IO streams.
-
-## Important Limitation
-
-Before diving into the technical details, please note the following restriction:
-
-- Exclusive Support for Dragonball VMM: This feature is currently implemented only for Kata Containers' built-in VMM, Dragonball.
-- Unsupported VMMs: Other VMMs such as QEMU, Cloud Hypervisor, and Firecracker do not support this feature at this time.
-
-## Overview
-
-The original IO implementation in Kata Containers suffered from an excessively long data path, leading to poor efficiency. For instance, copying a 10GB file could take as long as 10 minutes.
-
-To address this, Kata AC member @lifupan and @frezcirno introduced a series of optimizations using passthrough-fd technology. This approach allows the VMM to directly handle file descriptors (FDs), dramatically improving IO throughput.
-
-## Traditional IO Path
-
-Before the introduction of Passthrough-FD, Kata's IO streams were implemented using `ttrpc + virtio-vsock`.
-
-The data flow was as follows:
-
-```mermaid
-graph LR
-    subgraph Host ["Host"]
-        direction LR
-        Containerd["Containerd"]
-
-        subgraph KS ["kata-shim"]
-            buffer(("buffer"))
-        end
-
-        Vsock["vsock"]
-
-        subgraph VM ["vm"]
-            Agent["kata-agent"]
-            Container["container"]
-        end
-    end
-
-    Containerd -->|stdin| buffer
-    buffer --> Vsock
-    Vsock --> Agent
-    Agent -.-> Container
-
-    %% Style Rendering
-    style Host fill:#f0f8ff,stroke:#333,stroke-dasharray: 5 5
-    style VM fill:#fff9c4,stroke:#e0e0e0
-    style buffer fill:#c8e6c9,stroke:#ff9800,stroke-dasharray: 5 5
-    style Vsock fill:#bbdefb,stroke:#2196f3
-    style Containerd fill:#f5f5f5,stroke:#333
-    style Agent fill:#fff,stroke:#333
-    style Container fill:#fff,stroke:#333
-
-```
-
-The kata-shim (containerd-shim-kata-v2) on the Host opens the FIFO pipes provided by containerd via the shimv2 interface.
-This results in three FDs (stdin, stdout, and stderr).
-The kata-shim manages three separate threads to handle these streams.
-The Bottleneck: kata-shim acts as a "middleman," maintaining three internal buffers. It must read data from the FDs into its own buffers before forwarding them via ttrpc over vsock to the destination.
-This multi-threaded proxying and buffering in the shim layer introduced significant overhead.
-
-
-## What is Passthrough-FD?
-
-Passthrough-FD technology enhances the Dragonball VMM's hybrid-vsock implementation with support for recv-fd.
-
-```mermaid
-graph LR
-    subgraph Host ["Host"]
-        direction LR
-        Containerd["Containerd"]
-
-        Vsock["vsock"]
-
-        subgraph VM ["vm"]
-            Agent["kata-agent"]
-            Container["container"]
-        end
-    end
-
-    Containerd -->|stdin| Vsock
-    Vsock --> Agent
-    Agent -.-> Container
-
-    %% Style Rendering
-    style Host fill:#f0f8ff,stroke:#333,stroke-dasharray: 5 5
-    style VM fill:#fff9c4,stroke:#e0e0e0
-    style Vsock fill:#bbdefb,stroke:#2196f3
-    style Containerd fill:#f5f5f5,stroke:#333
-    style Agent fill:#fff,stroke:#333
-    style Container fill:#fff,stroke:#333
-```
-
-Instead of requiring an intermediate layer to read and forward data, the hybrid-vsock module can now directly receive file descriptors from the Host. This allows the system to "pass through" the host's FDs directly to the kata-agent. By eliminating the proxying logic in kata-shim, the IO stream is effectively connected directly to the guest environment.
-
-## Technical Details
-
-The end-to-end process follows these steps:
-
-```mermaid
-sequenceDiagram
-    autonumber
-
-    box rgb(220,235,255) Guest (VM)
-        participant Agent as kata-agent<br/>(Server)
-        participant VSOCK as AF_VSOCK socket<br/>(Hybrid Vsock)
-    end
-
-    box rgb(255,240,220) Host
-        participant Shim as kata-shim<br/>(Client)
-        participant FIFO as File or FIFO<br/>(stdin/stdout/stderr)
-    end
-
-    Note over Agent: Agent Initialization:<br/>listen() on passfd_listener_port
-
-    Shim->>FIFO: open() to acquire Fd<br/>(for stdin / stdout / stderr)
-
-    Shim->>VSOCK: connect() + send("passfd\n")<br/>+ send_with_fd(Fd, PortA)
-
-    Note over VSOCK,Agent: FD Transfer via Hybrid Vsock<br/>(repeat for stdin-port, stdout-port, stderr-port)
-
-    VSOCK->>Agent: forward connection + Fd + PortA
-
-    Agent->>Agent: accept() → get conn_fd + host-port<br/>save: map[host-port] = conn_fd<br/>(3 entries: stdin-port, stdout-port, stderr-port)
-
-    Shim->>Agent: create_container RPC<br/>(includes stdin-port, stdout-port, stderr-port)
-
-    Agent->>Agent: lookup map[stdin-port] → bind to container stdin<br/>lookup map[stdout-port] → bind to container stdout<br/>lookup map[stderr-port] → bind to container stderr
-
-    Agent-->>Shim: create_container RPC response (OK)
-```
-
-1. Agent Initialization: The kata-agent starts a server listening on the port specified by passfd_listener_port.
-2. FD Transfer: During the container creation phase, the kata-shim sends the FDs for stdin, stdout, and stderr to the Dragonball hybrid-vsock module using the sendfd mechanism.
-3. Connection Establishment: Through hybrid-vsock, these FDs connect to the server started by the agent in Step 1.
-4. Identification: The agent's server calls accept() to obtain the connection FD and a corresponding host-port. It saves the connection using the host-port as a unique identifier. At this stage, the agent has three established connections (identified by stdin-port, stdout-port, and stderr-port).
-5. RPC Mapping: When kata-shim invokes the create_container RPC, it includes these three port identifiers in the request.
-6. Final Binding: Upon receiving the RPC, the agent retrieves the saved connections using the provided ports and binds them directly to the container's standard IO streams.
-
-
-## How to enable PassthroughFD IO within Configuration?
-
-The Passthrough-FD feature is controlled by two main parameters in the Kata configuration file:
-
-- use_passfd_io: A boolean flag to enable or disable the Passthrough-FD IO feature.
-- passfd_listener_port: Specifies the port on which the kata-agent listens for FD connections. The default value is 1027.
-To enable Passthrough-FD IO, set use_passfd_io to true in the configuration file:
-
-```toml
-...
-# If enabled, the runtime will attempt to use fd passthrough feature for process io.
-# Note: this feature is only supported by the Dragonball hypervisor.
-use_passfd_io = true
-
-# If fd passthrough io is enabled, the runtime will attempt to use the specified port instead of the default port.
-passfd_listener_port = 1027
-```

docs/how-to/how-to-use-sysctls-with-kata.md

@@ -2,9 +2,9 @@
 
 ## Sysctls
 
-In Linux, the sysctl interface allows an administrator to modify kernel
-parameters at runtime. Parameters are available via the `/proc/sys/` virtual
-process file system.
+In Linux, the sysctl interface allows an administrator to modify kernel 
+parameters at runtime. Parameters are available via the `/proc/sys/` virtual 
+process file system. 
 
 The parameters include the following subsystems among others:
 - `fs` (file systems)
@@ -17,9 +17,9 @@ To get a complete list of kernel parameters, run:
 $ sudo sysctl -a
 ```
 
-Kubernetes provide mechanisms for setting namespaced sysctls.
+Kubernetes provide mechanisms for setting namespaced sysctls. 
 Namespaced sysctls can be set per pod in the case of Kubernetes.
-The following sysctls are known to be namespaced and can be set with
+The following sysctls are known to be namespaced and can be set with 
 Kubernetes:
 
 - `kernel.shm*`
@@ -84,14 +84,14 @@ The recommendation is to set them directly on the host or use a privileged
 container in the case of Kubernetes.
 
 In the case of Kata, the approach of setting sysctls on the host does not
-work since the host sysctls have no effect on a Kata Container running
+work since the host sysctls have no effect on a Kata Container running 
 inside a guest. Kata gives you the ability to set non-namespaced sysctls using a privileged container.
-This has the advantage that the non-namespaced sysctls are set inside the guest
-without having any effect on the `/proc/sys` values of any other pod or the
-host itself.
+This has the advantage that the non-namespaced sysctls are set inside the guest 
+without having any effect on the `/proc/sys` values of any other pod or the 
+host itself. 
 
 The recommended approach to do this would be to set the sysctl value in a
-privileged init container. In this way, the application containers do not need any elevated
+privileged init container. In this way, the application containers do not need any elevated 
 privileges.
 
 ```

docs/how-to/how-to-use-template-in-runtime-rs.md

@@ -116,4 +116,4 @@ time for I in $(seq 100); do
 done
 
 # Display the memory usage again after running the test
-free -h
+free -h

docs/how-to/how-to-use-the-kata-agent-policy.md

@@ -1,6 +1,6 @@
 # Kata Agent Policy
 
-Agent Policy is a Kata Containers feature that enables the Guest VM to perform additional validation for each [ttRPC API](../../src/libs/protocols/protos/agent.proto) request.
+Agent Policy is a Kata Containers feature that enables the Guest VM to perform additional validation for each [ttRPC API](../../src/libs/protocols/protos/agent.proto) request. 
 
 The Policy is commonly used for implementing confidential containers, where the Kata Shim and the Kata Agent have different trust properties. However, the Policy can be used for non-confidential containers too - e.g., for a basic defense in depth step of blocking the Host from starting an application on the Guest. However, for non-confidential containers, the Host might be able to modify the Policy and/or replace the Agent and disable its Policy rules, so a Policy is more helpful for confidential containers.
 
@@ -35,7 +35,7 @@ Kubernetes users can encode in `base64` format their Policy documents, and add t
 For example, the [`allow-all-except-exec-process.rego`](../../src/kata-opa/allow-all-except-exec-process.rego) sample policy file is different from the [default Policy](../../src/kata-opa/allow-all.rego) because it rejects any `ExecProcess` requests. To encode this policy file, you need to:
 - Embed the policy inside an init data struct
 - Compress
-- Base64 encode
+- Base64 encode 
 For example:
 
 ```bash
@@ -99,9 +99,6 @@ The [`genpolicy`](../../src/tools/genpolicy/) application can be used to generat
 
 **Warning** Users should review carefully the automatically-generated Policy, and modify the Policy file if needed to match better their use case, before using this Policy.
 
-**Important — User / Group / Supplemental groups for Policy and genpolicy**
-When using features like **nydus guest-pull**, set user/group IDs explicitly in the pod spec, as described in [Limitations](../Limitations.md#guest-pulled-container-images).
-
 See the [`genpolicy` documentation](../../src/tools/genpolicy/README.md) and the [Policy contents examples](#policy-contents) for additional information.
 
 ## Policy contents

docs/how-to/privileged.md

@@ -22,7 +22,7 @@ mitigation does not affect a container's ability to mount *guest* devices.
 ## Containerd
 
 The Containerd allows configuring the privileged host devices behavior for each runtime in the containerd config. This is
-done with the `privileged_without_host_devices` option. Setting this to `true` will disable hot plugging of the host
+done with the `privileged_without_host_devices` option. Setting this to `true` will disable hot plugging of the host 
 devices into the guest, even when privileged is enabled.
 
 Support for configuring privileged host devices behaviour was added in containerd `1.3.0` version.
@@ -49,7 +49,7 @@ See below example config:
 ## CRI-O
 
 Similar to containerd, CRI-O allows configuring the privileged host devices
-behavior for each runtime in the CRI config. This is done with the
+behavior for each runtime in the CRI config. This is done with the 
 `privileged_without_host_devices` option. Setting this to `true` will disable
  hot plugging of the host devices into the guest, even when privileged is enabled.
 
@@ -73,5 +73,5 @@ See below example config:
   privileged_without_host_devices = true
 ```
 
- - [Kata Containers with CRI-O](../how-to/how-to-use-k8s-with-crio-and-kata.md#cri-o)
-
+ - [Kata Containers with CRI-O](../how-to/run-kata-with-k8s.md#cri-o)
+  

docs/how-to/run-kata-with-crictl.md

@@ -8,7 +8,7 @@
 
 > **Note:** `cri-tools` is only used for debugging and validation purpose, and don't use it to run production workloads.
 
-> **Note:** For how to install and configure `cri-tools` with CRI runtimes like `containerd` or CRI-O, please also refer to other [how-tos](./README.md).
+> **Note:** For how to install and configure `cri-tools` with CRI runtimes like `containerd` or CRI-O, please also refer to other [howtos](./README.md).
 
 ## Use `crictl` run Pods in Kata containers
 
@@ -30,7 +30,7 @@ POD ID              CREATED             STATE               NAME
 #### Create container in the pod sandbox with config file
 
 ```bash
-$ sudo crictl create 16a62b035940f container_config.json sandbox_config.json
+$ sudo crictl create 16a62b035940f container_config.json sandbox_config.json 
 e6ca0e0f7f532686236b8b1f549e4878e4fe32ea6b599a5d684faf168b429202
 ```
 
@@ -66,7 +66,7 @@ $ sudo crictl exec -it e6ca0e0f7f532 sh
 And run commands in it:
 
 ```
-/ # hostname
+/ # hostname 
 busybox_host
 / # id
 uid=0(root) gid=0(root)

docs/how-to/run-kata-with-k8s.md

@@ -1,7 +1,6 @@
-# How to use Kata Containers and CRI-O with Kubernetes
+# Run Kata Containers with Kubernetes
 
 ## Prerequisites
-
 This guide requires Kata Containers available on your system, install-able by following [this guide](../install/README.md).
 
 ## Install a CRI implementation
@@ -10,16 +9,22 @@ Kubernetes CRI (Container Runtime Interface) implementations allow using any
 OCI-compatible runtime with Kubernetes, such as the Kata Containers runtime.
 
 Kata Containers support both the [CRI-O](https://github.com/kubernetes-incubator/cri-o) and
-[containerd](https://github.com/containerd/containerd) CRI implementations. We choose `CRI-O` for our examples in this guide.
+[containerd](https://github.com/containerd/containerd) CRI implementations.
+
+After choosing one CRI implementation, you must make the appropriate configuration
+to ensure it integrates with Kata Containers.
+
+Kata Containers 1.5 introduced the `shimv2` for containerd 1.2.0, reducing the components
+required to spawn pods and containers, and this is the preferred way to run Kata Containers with Kubernetes ([as documented here](../how-to/how-to-use-k8s-with-containerd-and-kata.md#configure-containerd-to-use-kata-containers)).
+
+An equivalent shim implementation for CRI-O is planned.
 
 ### CRI-O
-
 For CRI-O installation instructions, refer to the [CRI-O Tutorial](https://github.com/cri-o/cri-o/blob/main/tutorial.md) page.
 
 The following sections show how to set up the CRI-O snippet configuration file (default path: `/etc/crio/crio.conf`) for Kata.
 
 Unless otherwise stated, all the following settings are specific to the `crio.runtime` table:
-
 ```toml
 # The "crio.runtime" table contains settings pertaining to the OCI
 # runtime used and options for how to set up and manage the OCI runtime.
@@ -28,17 +33,16 @@ Unless otherwise stated, all the following settings are specific to the `crio.ru
 A comprehensive documentation of the configuration file can be found [here](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md).
 
 > **Note**: After any change to this file, the CRI-O daemon have to be restarted with:
-
 >````
 >$ sudo systemctl restart crio
 >````
 
 #### Kubernetes Runtime Class (CRI-O v1.12+)
-
 The [Kubernetes Runtime Class](https://kubernetes.io/docs/concepts/containers/runtime-class/)
 is the preferred way of specifying the container runtime configuration to run a Pod's containers.
-To use this feature, Kata must added as a runtime handler. This can be done by dropping a `50-kata`
-snippet file into `/etc/crio/crio.conf.d`, with the content shown below:
+To use this feature, Kata must added as a runtime handler. This can be done by
+dropping a `50-kata` snippet file into `/etc/crio/crio.conf.d`, with the
+content shown below:
 
 ```toml
 [crio.runtime.runtimes.kata]
@@ -48,6 +52,13 @@ snippet file into `/etc/crio/crio.conf.d`, with the content shown below:
 	privileged_without_host_devices = true
 ```
 
+
+### containerd
+
+To customize containerd to select Kata Containers runtime, follow our
+"Configure containerd to use Kata Containers" internal documentation
+[here](../how-to/how-to-use-k8s-with-containerd-and-kata.md#configure-containerd-to-use-kata-containers).
+
 ## Install Kubernetes
 
 Depending on what your needs are and what you expect to do with Kubernetes,
@@ -61,16 +72,25 @@ implementation you chose, and the Kubelet service has to be updated accordingly.
 ### Configure for CRI-O
 
 `/etc/systemd/system/kubelet.service.d/0-crio.conf`
-
 ```
 [Service]
 Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///var/run/crio/crio.sock"
 ```
 
+### Configure for containerd
+
+`/etc/systemd/system/kubelet.service.d/0-cri-containerd.conf`
+```
+[Service]
+Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
+```
+For more information about containerd see the "Configure Kubelet to use containerd"
+documentation [here](../how-to/how-to-use-k8s-with-containerd-and-kata.md#configure-kubelet-to-use-containerd).
+
 ## Run a Kubernetes pod with Kata Containers
 
-After you update your Kubelet service based on the CRI implementation you are using, reload and restart Kubelet. Then, start your cluster:
-
+After you update your Kubelet service based on the CRI implementation you
+are using, reload and restart Kubelet. Then, start your cluster:
 ```bash
 $ sudo systemctl daemon-reload
 $ sudo systemctl restart kubelet
@@ -78,6 +98,12 @@ $ sudo systemctl restart kubelet
 # If using CRI-O
 $ sudo kubeadm init --ignore-preflight-errors=all --cri-socket /var/run/crio/crio.sock --pod-network-cidr=10.244.0.0/16
 
+# If using containerd
+$ cat <<EOF | tee kubeadm-config.yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: InitConfiguration
+nodeRegistration:
+  criSocket: "/run/containerd/containerd.sock"
 ---
 kind: KubeletConfiguration
 apiVersion: kubelet.config.k8s.io/v1beta1
@@ -92,7 +118,6 @@ $ export KUBECONFIG=/etc/kubernetes/admin.conf
 ### Allow pods to run in the control-plane node
 
 By default, the cluster will not schedule pods in the control-plane node. To enable control-plane node scheduling:
-
 ```bash
 $ sudo -E kubectl taint nodes --all node-role.kubernetes.io/control-plane-
 ```
@@ -136,7 +161,6 @@ If a pod has the `runtimeClassName` set to `kata`, the CRI plugin runs the pod w
   ```
 
 - Create the pod
-
   ```bash
   $ sudo -E kubectl apply -f nginx-kata.yaml
   ```
@@ -148,7 +172,6 @@ If a pod has the `runtimeClassName` set to `kata`, the CRI plugin runs the pod w
   ```
 
 - Check hypervisor is running
-
   ```bash
   $ ps aux | grep qemu
   ```

docs/how-to/service-mesh.md

@@ -169,7 +169,7 @@ Add the following annotation for CRI-O
 ```yaml
 io.kubernetes.cri-o.TrustedSandbox: "false"
 ```
-The following is an example of what your YAML can look like:
+The following is an example of what your YAML can look like: 
 
 ```yaml
 ...
@@ -199,7 +199,7 @@ Add the following annotation for containerd
 ```yaml
 io.kubernetes.cri.untrusted-workload: "true"
 ```
-The following is an example of what your YAML can look like:
+The following is an example of what your YAML can look like: 
 
 ```yaml
 ...

docs/how-to/what-is-vm-cache-and-how-do-I-use-it.md

@@ -3,12 +3,12 @@
 ### What is VMCache
 
 VMCache is a new function that creates VMs as caches before using it.
-It helps speed up new container creation.
+It helps speed up new container creation.  
 The function consists of a server and some clients communicating
-through Unix socket.  The protocol is gRPC in [`protocols/cache/cache.proto`](../../src/runtime/protocols/cache/cache.proto).
+through Unix socket.  The protocol is gRPC in [`protocols/cache/cache.proto`](../../src/runtime/protocols/cache/cache.proto).  
 The VMCache server will create some VMs and cache them by factory cache.
 It will convert the VM to gRPC format and transport it when gets
-requested from clients.
+requested from clients.  
 Factory `grpccache` is the VMCache client.  It will request gRPC format
 VM and convert it back to a VM.  If VMCache function is enabled,
 `kata-runtime` will request VM from factory `grpccache` when it creates
@@ -16,8 +16,8 @@ a new sandbox.
 
 ### How is this different to VM templating
 
-Both [VM templating](../how-to/what-is-vm-templating-and-how-do-I-use-it.md) and VMCache help speed up new container creation.
-When VM templating enabled, new VMs are created by cloning from a pre-created template VM, and they will share the same initramfs, kernel and agent memory in readonly mode.  So it saves a lot of memory if there are many Kata Containers running on the same host.
+Both [VM templating](../how-to/what-is-vm-templating-and-how-do-I-use-it.md) and VMCache help speed up new container creation.  
+When VM templating enabled, new VMs are created by cloning from a pre-created template VM, and they will share the same initramfs, kernel and agent memory in readonly mode.  So it saves a lot of memory if there are many Kata Containers running on the same host.  
 VMCache is not vulnerable to [share memory CVE](../how-to/what-is-vm-templating-and-how-do-I-use-it.md#what-are-the-cons) because each VM doesn't share the memory.
 
 ### How to enable VMCache
@@ -25,9 +25,9 @@ VMCache is not vulnerable to [share memory CVE](../how-to/what-is-vm-templating-
 VMCache can be enabled by changing your Kata Containers config file (`/usr/share/defaults/kata-containers/configuration.toml`,
 overridden by `/etc/kata-containers/configuration.toml` if provided) such that:
 * `vm_cache_number` specifies the number of caches of VMCache:
-    *  unspecified or == 0
+    *  unspecified or == 0  
        VMCache is disabled
-    * `> 0`
+    * `> 0`  
       will be set to the specified number
 *  `vm_cache_endpoint` specifies the address of the Unix socket.