docs: Use more accurate wording for /dev hostPath behavior

I got lazy when I first added this section in 5c21b1f, so updating the
language to specify that any non-regular host file (under /dev) qualifies,
not just devices.

This matches the actual code, see:

330bfff4be/src/runtime/virtcontainers/mount.go (L57-L83)

Signed-off-by: Aurélien Bombo <abombo@microsoft.com>

.editorconfig

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

.editorconfig-checker.json

@@ -0,0 +1,30 @@
+{
+  "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/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/workflows/basic-ci-amd64.yaml

@@ -347,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/build-checks.yaml

@@ -74,7 +74,7 @@ jobs:
               - rust
               - protobuf-compiler
         instance:
-          - ${{ inputs.instance }} 
+          - ${{ inputs.instance }}
 
     steps:
       - name: Adjust a permission for repo
@@ -94,11 +94,19 @@ jobs:
           ./ci/install_yq.sh
         env:
           INSTALL_IN_GOPATH: false
-      - name: Install golang
+      - name: Read properties from versions.yaml
         if: contains(matrix.component.needs, 'golang')
         run: |
-          ./tests/install_go.sh -f -p
-          echo "/usr/local/go/bin" >> "$GITHUB_PATH"
+          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' || '' }}
       - name: Setup rust
         if: contains(matrix.component.needs, 'rust')
         run: |

.github/workflows/build-helm-image.yaml

@@ -1,75 +0,0 @@
-name: Build helm multi-arch image
-
-on:
-  schedule:
-    # Run every Sunday at 12:00 UTC (12 hours after kubectl image build)
-    - cron: '0 12 * * 0'
-  workflow_dispatch:
-    # Allow manual triggering
-  push:
-    branches:
-      - main
-    paths:
-      - 'tools/packaging/helm/Dockerfile'
-      - '.github/workflows/build-helm-image.yaml'
-
-permissions: {}
-
-env:
-  REGISTRY: quay.io
-  IMAGE_NAME: kata-containers/helm
-
-jobs:
-  build-and-push:
-    name: Build and push multi-arch image
-    runs-on: ubuntu-24.04
-    permissions:
-      contents: read
-      packages: write
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-        with:
-          persist-credentials: false
-
-      - name: Set up QEMU
-        uses: docker/setup-qemu-action@29109295f81e9208d7d86ff1c6c12d2833863392 # v3.6.0
-
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0
-
-      - name: Login to Quay.io
-        uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0
-        with:
-          registry: ${{ env.REGISTRY }}
-          username: ${{ vars.QUAY_DEPLOYER_USERNAME }}
-          password: ${{ secrets.QUAY_DEPLOYER_PASSWORD }}
-
-      - name: Get helm version
-        id: helm-version
-        run: |
-          HELM_VERSION=$(curl -s https://api.github.com/repos/helm/helm/releases/latest | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
-          echo "version=${HELM_VERSION}" >> "$GITHUB_OUTPUT"
-
-      - name: Generate image metadata
-        id: meta
-        uses: docker/metadata-action@902fa8ec7d6ecbf8d84d538b9b233a880e428804 # v5.7.0
-        with:
-          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
-          tags: |
-            type=raw,value=latest
-            type=raw,value={{date 'YYYYMMDD'}}
-            type=raw,value=${{ steps.helm-version.outputs.version }}
-            type=sha,prefix=
-
-      - name: Build and push multi-arch image
-        uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0
-        with:
-          context: tools/packaging/helm/
-          file: tools/packaging/helm/Dockerfile
-          platforms: linux/amd64,linux/arm64,linux/s390x,linux/ppc64le
-          push: true
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max

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

@@ -47,10 +47,8 @@ jobs:
           - coco-guest-components
           - firecracker
           - kernel
-          - kernel-confidential
           - kernel-dragonball-experimental
           - kernel-nvidia-gpu
-          - kernel-nvidia-gpu-confidential
           - nydus
           - ovmf
           - ovmf-sev
@@ -145,7 +143,7 @@ jobs:
           if-no-files-found: error
 
       - name: store-extratarballs-artifact ${{ matrix.asset }}
-        if: ${{ startsWith(matrix.asset, 'kernel-nvidia-gpu') }}
+        if: ${{ matrix.asset == 'kernel' || startsWith(matrix.asset, 'kernel-nvidia-gpu') }}
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
         with:
           name: kata-artifacts-amd64-${{ matrix.asset }}-modules${{ inputs.tarball-suffix }}
@@ -237,8 +235,8 @@ jobs:
         asset:
           - busybox
           - coco-guest-components
+          - kernel-modules
           - kernel-nvidia-gpu-modules
-          - kernel-nvidia-gpu-confidential-modules
           - pause-image
     steps:
       - uses: geekyeggo/delete-artifact@f275313e70c08f6120db482d7a6b98377786765b # v5.1.0

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

@@ -44,7 +44,6 @@ jobs:
           - agent
           - coco-guest-components
           - kernel
-          - kernel-confidential
           - pause-image
           - qemu
           - virtiofsd
@@ -121,6 +120,15 @@ jobs:
           retention-days: 15
           if-no-files-found: error
 
+      - name: store-extratarballs-artifact ${{ matrix.asset }}
+        if: ${{ matrix.asset == 'kernel' }}
+        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
+        with:
+          name: kata-artifacts-s390x-${{ matrix.asset }}-modules${{ inputs.tarball-suffix }}
+          path: kata-build/kata-static-${{ matrix.asset }}-modules.tar.zst
+          retention-days: 15
+          if-no-files-found: error
+
   build-asset-rootfs:
     name: build-asset-rootfs
     runs-on: s390x

.github/workflows/ci.yaml

@@ -297,6 +297,21 @@ 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

.github/workflows/editorconfig-checker.yaml

@@ -0,0 +1,29 @@
+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/push-oras-tarball-cache.yaml

@@ -0,0 +1,43 @@
+# 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/release.yaml

@@ -284,15 +284,11 @@ jobs:
           echo "${QUAY_DEPLOYER_PASSWORD}" | helm registry login quay.io --username "${QUAY_DEPLOYER_USERNAME}" --password-stdin
           echo "${GITHUB_TOKEN}" | helm registry login ghcr.io --username "${GITHUB_ACTOR}" --password-stdin
 
-      - name: Push helm charts to the OCI registries
+      - name: Push helm chart to the OCI registries
         run: |
           release_version=$(./tools/packaging/release/release.sh release-version)
-          # Push kata-deploy chart
           helm push "kata-deploy-${release_version}.tgz" oci://quay.io/kata-containers/kata-deploy-charts
           helm push "kata-deploy-${release_version}.tgz" oci://ghcr.io/kata-containers/kata-deploy-charts
-          # Push kata-lifecycle-manager chart
-          helm push "kata-lifecycle-manager-${release_version}.tgz" oci://quay.io/kata-containers/kata-deploy-charts
-          helm push "kata-lifecycle-manager-${release_version}.tgz" oci://ghcr.io/kata-containers/kata-deploy-charts
 
   publish-release:
     name: publish-release

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

@@ -42,17 +42,6 @@ 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
@@ -80,6 +69,7 @@ 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

@@ -0,0 +1,127 @@
+# 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-kata-coco-tests.yaml

@@ -140,165 +140,36 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        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
+        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
     permissions:
-      id-token: write # Used for OIDC access to log into Azure
+      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.vmm }}
+      KATA_HYPERVISOR: ${{ matrix.environment.vmm }}
       # Some tests rely on that variable to run (or not)
       KBS: "true"
       # Set the KBS ingress handler (empty string disables handling)
-      KBS_INGRESS: "aks"
+      KBS_INGRESS: "nodeport"
       KUBERNETES: "vanilla"
-      PULL_TYPE: ${{ matrix.pull-type }}
+      PULL_TYPE: ${{ matrix.environment.pull_type }}
       AUTHENTICATED_IMAGE_USER: ${{ vars.AUTHENTICATED_IMAGE_USER }}
       AUTHENTICATED_IMAGE_PASSWORD: ${{ secrets.AUTHENTICATED_IMAGE_PASSWORD }}
-      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.
+      SNAPSHOTTER: ${{ matrix.environment.snapshotter }}
+      EXPERIMENTAL_FORCE_GUEST_PULL: ${{ matrix.environment.pull_type == 'experimental-force-guest-pull' && matrix.environment.vmm || '' }}
+      AUTO_GENERATE_POLICY: "yes"
       K8S_TEST_HOST_TYPE: "all"
-    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: 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: 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-aks
-        env:
-          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
-        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
-        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: 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 delete-cluster
-
-  # Generate jobs for testing CoCo on non-TEE environments with erofs-snapshotter
-  run-k8s-tests-coco-nontee-with-erofs-snapshotter:
-    name: run-k8s-tests-coco-nontee-with-erofs-snapshotter
-    strategy:
-      fail-fast: false
-      matrix:
-        vmm:
-          - qemu-coco-dev
-        snapshotter:
-          - erofs
-        pull-type:
-          - default
-    runs-on: ubuntu-24.04
-    environment: ci
-    env:
-      DOCKER_REGISTRY: ${{ inputs.registry }}
-      DOCKER_REPO: ${{ inputs.repo }}
-      DOCKER_TAG: ${{ inputs.tag }}
-      GH_PR_NUMBER: ${{ inputs.pr-number }}
-      KATA_HYPERVISOR: ${{ matrix.vmm }}
-      # Some tests rely on that variable to run (or not)
-      KBS: "false"
-      # Set the KBS ingress handler (empty string disables handling)
-      KBS_INGRESS: ""
-      KUBERNETES: "vanilla"
       CONTAINER_ENGINE: "containerd"
-      CONTAINER_ENGINE_VERSION: "v2.2"
-      PULL_TYPE: ${{ matrix.pull-type }}
-      SNAPSHOTTER: ${{ matrix.snapshotter }}
-      USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: "true"
-      K8S_TEST_HOST_TYPE: "all"
-      # 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"
+      CONTAINER_ENGINE_VERSION: "active"
+      GH_TOKEN: ${{ github.token }}
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
@@ -342,8 +213,129 @@ jobs:
       - name: Deploy kubernetes
         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:
-          GH_TOKEN: ${{ github.token }}
+          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
+        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
+
+      - name: Delete CSI driver
+        if: always()
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh delete-csi-driver
+
+  # Generate jobs for testing CoCo on non-TEE environments with erofs-snapshotter
+  run-k8s-tests-coco-nontee-with-erofs-snapshotter:
+    name: run-k8s-tests-coco-nontee-with-erofs-snapshotter
+    strategy:
+      fail-fast: false
+      matrix:
+        vmm:
+          - qemu-coco-dev
+        snapshotter:
+          - erofs
+        pull-type:
+          - default
+    runs-on: ubuntu-24.04
+    environment: ci
+    env:
+      DOCKER_REGISTRY: ${{ inputs.registry }}
+      DOCKER_REPO: ${{ inputs.repo }}
+      DOCKER_TAG: ${{ inputs.tag }}
+      GH_PR_NUMBER: ${{ inputs.pr-number }}
+      KATA_HYPERVISOR: ${{ matrix.vmm }}
+      # Some tests rely on that variable to run (or not)
+      KBS: "false"
+      # Set the KBS ingress handler (empty string disables handling)
+      KBS_INGRESS: ""
+      KUBERNETES: "vanilla"
+      CONTAINER_ENGINE: "containerd"
+      CONTAINER_ENGINE_VERSION: "active"
+      PULL_TYPE: ${{ matrix.pull-type }}
+      SNAPSHOTTER: ${{ matrix.snapshotter }}
+      USE_EXPERIMENTAL_SETUP_SNAPSHOTTER: "true"
+      K8S_TEST_HOST_TYPE: "all"
+      # 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:
+          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 kubernetes
+        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
@@ -363,3 +355,13 @@ 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
+
+      - name: Delete CSI driver
+        if: always()
+        timeout-minutes: 5
+        run: bash tests/integration/kubernetes/gha-run.sh delete-csi-driver

Cargo.lock

@@ -44,9 +44,7 @@ version = "0.1.0"
 dependencies = [
  "anyhow",
  "async-trait",
- "futures 0.1.31",
  "kata-types",
- "log",
  "logging",
  "nix 0.26.4",
  "oci-spec 0.8.3",
@@ -141,23 +139,12 @@ version = "0.7.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "435a87a52755b8f27fcf321ac4f04b2802e337c8c4872923137471ec39c37532"
 dependencies = [
- "event-listener 5.4.1",
+ "event-listener",
  "event-listener-strategy",
  "futures-core",
  "pin-project-lite",
 ]
 
-[[package]]
-name = "async-channel"
-version = "1.9.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "81953c529336010edd6d8e358f886d9581267795c61b19475b71314bffa46d35"
-dependencies = [
- "concurrent-queue",
- "event-listener 2.5.3",
- "futures-core",
-]
-
 [[package]]
 name = "async-channel"
 version = "2.5.0"
@@ -184,21 +171,6 @@ dependencies = [
  "slab",
 ]
 
-[[package]]
-name = "async-global-executor"
-version = "2.4.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "05b1b633a2115cd122d73b955eadd9916c18c8f510ec9cd1686404c60ad1c29c"
-dependencies = [
- "async-channel 2.5.0",
- "async-executor",
- "async-io",
- "async-lock",
- "blocking",
- "futures-lite",
- "once_cell",
-]
-
 [[package]]
 name = "async-io"
 version = "2.6.0"
@@ -223,7 +195,7 @@ version = "3.4.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "5fd03604047cee9b6ce9de9f70c6cd540a0520c813cbd49bae61f33ab80ed1dc"
 dependencies = [
- "event-listener 5.4.1",
+ "event-listener",
  "event-listener-strategy",
  "pin-project-lite",
 ]
@@ -234,14 +206,14 @@ version = "2.5.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "fc50921ec0055cdd8a16de48773bfeec5c972598674347252c0399676be7da75"
 dependencies = [
- "async-channel 2.5.0",
+ "async-channel",
  "async-io",
  "async-lock",
  "async-signal",
  "async-task",
  "blocking",
  "cfg-if 1.0.0",
- "event-listener 5.4.1",
+ "event-listener",
  "futures-lite",
  "rustix 1.1.2",
 ]
@@ -275,32 +247,6 @@ dependencies = [
  "windows-sys 0.61.2",
 ]
 
-[[package]]
-name = "async-std"
-version = "1.13.2"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "2c8e079a4ab67ae52b7403632e4618815d6db36d2a010cfe41b02c1b1578f93b"
-dependencies = [
- "async-channel 1.9.0",
- "async-global-executor",
- "async-io",
- "async-lock",
- "crossbeam-utils",
- "futures-channel",
- "futures-core",
- "futures-io",
- "futures-lite",
- "gloo-timers",
- "kv-log-macro",
- "log",
- "memchr",
- "once_cell",
- "pin-project-lite",
- "pin-utils",
- "slab",
- "wasm-bindgen-futures",
-]
-
 [[package]]
 name = "async-task"
 version = "4.7.1"
@@ -447,7 +393,7 @@ version = "1.6.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e83f8d02be6967315521be875afa792a316e28d57b5a2d401897e2a7921b7f21"
 dependencies = [
- "async-channel 2.5.0",
+ "async-channel",
  "async-task",
  "futures-io",
  "futures-lite",
@@ -525,9 +471,9 @@ checksum = "14c189c53d098945499cdfa7ecc63567cf3886b3332b312a5b4585d8d3a6a610"
 
 [[package]]
 name = "bytes"
-version = "1.5.0"
+version = "1.11.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a2bd12c1caf447e69cd4528f47f94d203fd2582878ecb9e9465484c4148a8223"
+checksum = "1e748733b7cbc798e1434b6ac524f0c1ff2ab456fe201501e6497c8417a4fc33"
 
 [[package]]
 name = "caps"
@@ -644,29 +590,17 @@ dependencies = [
  "containerd-shim-protos",
  "kata-sys-util",
  "kata-types",
- "lazy_static",
  "nix 0.26.4",
  "oci-spec 0.8.3",
- "persist",
  "protobuf",
  "protocols",
  "resource",
  "runtime-spec",
- "serde_json",
- "slog",
- "slog-scope",
  "strum 0.24.1",
  "thiserror 1.0.48",
  "tokio",
- "ttrpc",
 ]
 
-[[package]]
-name = "common-path"
-version = "1.0.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "2382f75942f4b3be3690fe4f86365e9c853c1587d6ee58212cebf6e2a9ccd101"
-
 [[package]]
 name = "concurrent-queue"
 version = "2.5.0"
@@ -711,7 +645,7 @@ dependencies = [
  "async-trait",
  "cgroups-rs 0.3.4",
  "containerd-shim-protos",
- "futures 0.3.28",
+ "futures",
  "go-flag",
  "lazy_static",
  "libc",
@@ -1044,7 +978,6 @@ dependencies = [
  "dbs-interrupt",
  "dbs-utils",
  "dbs-virtio-devices",
- "downcast-rs",
  "kvm-bindings",
  "kvm-ioctls",
  "libc",
@@ -1057,7 +990,6 @@ dependencies = [
  "vfio-ioctls",
  "virtio-queue",
  "vm-memory",
- "vmm-sys-util 0.11.1",
 ]
 
 [[package]]
@@ -1074,7 +1006,6 @@ dependencies = [
 name = "dbs-upcall"
 version = "0.3.0"
 dependencies = [
- "anyhow",
  "dbs-utils",
  "dbs-virtio-devices",
  "log",
@@ -1138,12 +1069,12 @@ dependencies = [
 
 [[package]]
 name = "deranged"
-version = "0.3.11"
+version = "0.5.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "b42b6fa04a440b495c8b04d0e71b707c585f83cb9cb28cf8cd0d976c315e31b4"
+checksum = "ececcb659e7ba858fb4f10388c250a7252eb0a27373f1a72b8748afdd248e587"
 dependencies = [
  "powerfmt",
- "serde",
+ "serde_core",
 ]
 
 [[package]]
@@ -1269,12 +1200,6 @@ version = "0.11.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1435fa1053d8b2fbbe9be7e97eca7f33d37b28409959813daefc1446a14247f1"
 
-[[package]]
-name = "downcast-rs"
-version = "1.2.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9ea835d29036a4087793836fa931b08837ad5e957da9e23886b29586fb9b6650"
-
 [[package]]
 name = "dragonball"
 version = "0.1.0"
@@ -1295,7 +1220,6 @@ dependencies = [
  "dbs-utils",
  "dbs-virtio-devices",
  "derivative",
- "fuse-backend-rs",
  "kvm-bindings",
  "kvm-ioctls",
  "lazy_static",
@@ -1350,6 +1274,18 @@ version = "1.1.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "66b7e2430c6dff6a955451e2cfc438f09cea1965a9d6f87f7e3b90decc014099"
 
+[[package]]
+name = "enum-as-inner"
+version = "0.6.1"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "a1e6a265c649f3f5979b601d26f1d05ada116434c87741c9493cb56218f76cbc"
+dependencies = [
+ "heck 0.5.0",
+ "proc-macro2",
+ "quote",
+ "syn 2.0.104",
+]
+
 [[package]]
 name = "enumflags2"
 version = "0.7.12"
@@ -1403,12 +1339,6 @@ dependencies = [
  "windows-sys 0.61.2",
 ]
 
-[[package]]
-name = "event-listener"
-version = "2.5.3"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "0206175f82b8d6bf6652ff7d71a1e27fd2e4efde587fd368662814d6ec1d9ce0"
-
 [[package]]
 name = "event-listener"
 version = "5.4.1"
@@ -1426,7 +1356,7 @@ version = "0.5.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8be9f3dfaaffdae2972880079a491a1a8bb7cbed0b8dd7a347f668b4150a3b93"
 dependencies = [
- "event-listener 5.4.1",
+ "event-listener",
  "pin-project-lite",
 ]
 
@@ -1554,12 +1484,6 @@ dependencies = [
  "vmm-sys-util 0.11.1",
 ]
 
-[[package]]
-name = "futures"
-version = "0.1.31"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "3a471a38ef8ed83cd6e40aa59c1ffe17db6855c18e3604d9c4ed8c08ebc28678"
-
 [[package]]
 name = "futures"
 version = "0.3.28"
@@ -1719,18 +1643,6 @@ version = "0.3.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0cc23270f6e1808e30a928bdc84dea0b9b4136a8bc82338574f23baf47bbd280"
 
-[[package]]
-name = "gloo-timers"
-version = "0.3.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "bbb143cf96099802033e0d4f4963b19fd2e0b728bcf076cd9cf7f6634f092994"
-dependencies = [
- "futures-channel",
- "futures-core",
- "js-sys",
- "wasm-bindgen",
-]
-
 [[package]]
 name = "go-flag"
 version = "0.1.0"
@@ -1966,7 +1878,7 @@ dependencies = [
  "crossbeam-channel",
  "dbs-utils",
  "dragonball",
- "futures 0.3.28",
+ "futures",
  "go-flag",
  "hyper",
  "hyperlocal",
@@ -1977,10 +1889,8 @@ dependencies = [
  "libc",
  "logging",
  "nix 0.26.4",
- "oci-spec 0.8.3",
  "path-clean",
  "persist",
- "protobuf",
  "protocols",
  "qapi",
  "qapi-qmp",
@@ -1992,7 +1902,6 @@ dependencies = [
  "serde",
  "serde_json",
  "serial_test 2.0.0",
- "shim-interface",
  "slog",
  "slog-scope",
  "tempfile",
@@ -2269,8 +2178,6 @@ version = "0.1.0"
 dependencies = [
  "anyhow",
  "byteorder",
- "chrono",
- "common-path",
  "fail",
  "hex",
  "kata-types",
@@ -2279,11 +2186,9 @@ dependencies = [
  "mockall",
  "nix 0.26.4",
  "oci-spec 0.8.3",
- "once_cell",
  "pci-ids",
  "rand 0.8.5",
  "runtime-spec",
- "safe-path 0.1.0",
  "serde",
  "serde_json",
  "slog",
@@ -2302,8 +2207,8 @@ dependencies = [
  "byte-unit",
  "flate2",
  "glob",
- "hex",
  "lazy_static",
+ "nix 0.26.4",
  "num_cpus",
  "oci-spec 0.8.3",
  "regex",
@@ -2314,18 +2219,10 @@ dependencies = [
  "sha2 0.10.9",
  "slog",
  "slog-scope",
+ "sysctl",
  "sysinfo",
  "thiserror 1.0.48",
- "toml 0.5.11",
-]
-
-[[package]]
-name = "kv-log-macro"
-version = "1.0.7"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "0de8b303297635ad57c9f5059fd9cee7a47f8e8daa09df0fcd07dd39fb22977f"
-dependencies = [
- "log",
+ "toml",
 ]
 
 [[package]]
@@ -2646,7 +2543,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b65d130ee111430e47eed7896ea43ca693c387f097dd97376bffafbf25812128"
 dependencies = [
  "bytes",
- "futures 0.3.28",
+ "futures",
  "log",
  "netlink-packet-core",
  "netlink-sys",
@@ -2660,7 +2557,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "416060d346fbaf1f23f9512963e3e878f1a78e707cb699ba9215761754244307"
 dependencies = [
  "bytes",
- "futures 0.3.28",
+ "futures",
  "libc",
  "log",
  "tokio",
@@ -2784,9 +2681,9 @@ dependencies = [
 
 [[package]]
 name = "num-conv"
-version = "0.1.0"
+version = "0.2.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "51d515d32fb182ee37cda2ccdcb92950d6a3c2893aa280e540671c2cd0f3b1d9"
+checksum = "cf97ec579c3c42f953ef76dbf8d55ac91fb219dde70e49aa4a6b7d74e9919050"
 
 [[package]]
 name = "num-traits"
@@ -2817,7 +2714,7 @@ dependencies = [
  "log",
  "serde",
  "serde_json",
- "toml 0.5.11",
+ "toml",
 ]
 
 [[package]]
@@ -3044,7 +2941,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1e785d273968748578931e4dc3b4f5ec86b26e09d9e0d66b55adda7fce742f7a"
 dependencies = [
  "async-trait",
- "futures 0.3.28",
+ "futures",
  "futures-executor",
  "headers",
  "http",
@@ -3212,11 +3109,9 @@ dependencies = [
  "async-trait",
  "kata-sys-util",
  "kata-types",
- "libc",
  "safe-path 0.1.0",
  "serde",
  "serde_json",
- "shim-interface",
 ]
 
 [[package]]
@@ -3626,7 +3521,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "7b047adab56acc4948d4b9b58693c1f33fd13efef2d6bb5f0f66a47436ceada8"
 dependencies = [
  "bytes",
- "futures 0.3.28",
+ "futures",
  "log",
  "memchr",
  "qapi-qmp",
@@ -3908,11 +3803,10 @@ dependencies = [
  "agent",
  "anyhow",
  "async-trait",
- "bitflags 2.10.0",
  "byte-unit",
  "cgroups-rs 0.5.0",
  "flate2",
- "futures 0.3.28",
+ "futures",
  "hex",
  "hypervisor",
  "inotify",
@@ -3922,7 +3816,6 @@ dependencies = [
  "libc",
  "logging",
  "netlink-packet-route",
- "netlink-sys",
  "netns-rs",
  "nix 0.26.4",
  "oci-spec 0.8.3",
@@ -3945,9 +3838,9 @@ dependencies = [
 
 [[package]]
 name = "rkyv"
-version = "0.7.45"
+version = "0.7.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9008cd6385b9e161d8229e1f6549dd23c3d022f132a2ea37ac3a10ac4935779b"
+checksum = "2297bf9c81a3f0dc96bc9521370b88f054168c29826a75e89c55ff196e7ed6a1"
 dependencies = [
  "bitvec",
  "bytecheck",
@@ -3963,9 +3856,9 @@ dependencies = [
 
 [[package]]
 name = "rkyv_derive"
-version = "0.7.45"
+version = "0.7.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "503d1d27590a2b0a3a4ca4c94755aa2875657196ecbf401a42eff41d7de532c0"
+checksum = "84d7b42d4b8d06048d3ac8db0eb31bcb942cbeb709f0b5f2b2ebde398d3038f5"
 dependencies = [
  "proc-macro2",
  "quote",
@@ -4007,7 +3900,6 @@ dependencies = [
  "common",
  "containerd-shim-protos",
  "go-flag",
- "logging",
  "nix 0.26.4",
  "runtimes",
  "shim",
@@ -4018,7 +3910,6 @@ dependencies = [
 name = "runtime-spec"
 version = "0.1.0"
 dependencies = [
- "libc",
  "serde",
  "serde_derive",
  "serde_json",
@@ -4032,7 +3923,6 @@ dependencies = [
  "anyhow",
  "common",
  "hyper",
- "hyperlocal",
  "hypervisor",
  "kata-sys-util",
  "kata-types",
@@ -4047,6 +3937,8 @@ dependencies = [
  "persist",
  "procfs 0.12.0",
  "prometheus",
+ "protobuf",
+ "protocols",
  "resource",
  "runtime-spec",
  "serde_json",
@@ -4349,7 +4241,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1c789ec87f4687d022a2405cf46e0cd6284889f1839de292cadeb6c6019506f2"
 dependencies = [
  "dashmap",
- "futures 0.3.28",
+ "futures",
  "lazy_static",
  "log",
  "parking_lot",
@@ -4363,7 +4255,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0e56dd856803e253c8f298af3f4d7eb0ae5e23a737252cd90bb4f3b435033b2d"
 dependencies = [
  "dashmap",
- "futures 0.3.28",
+ "futures",
  "lazy_static",
  "log",
  "parking_lot",
@@ -4403,12 +4295,10 @@ dependencies = [
  "containerd-shim-protos",
  "kata-types",
  "logging",
- "persist",
  "runtimes",
  "slog",
  "slog-scope",
  "tokio",
- "tracing",
  "ttrpc",
 ]
 
@@ -4472,9 +4362,7 @@ dependencies = [
  "nix 0.26.4",
  "oci-spec 0.8.3",
  "protobuf",
- "rand 0.8.5",
  "runtime-spec",
- "runtimes",
  "serial_test 0.10.0",
  "service",
  "sha2 0.10.9",
@@ -4483,11 +4371,8 @@ dependencies = [
  "slog-scope",
  "slog-stdlog",
  "tempfile",
- "tests_utils",
  "thiserror 1.0.48",
  "tokio",
- "tracing",
- "tracing-opentelemetry",
  "unix_socket2",
 ]
 
@@ -4497,7 +4382,6 @@ version = "0.1.0"
 dependencies = [
  "anyhow",
  "common",
- "logging",
  "runtimes",
  "tokio",
 ]
@@ -4791,6 +4675,20 @@ dependencies = [
  "syn 2.0.104",
 ]
 
+[[package]]
+name = "sysctl"
+version = "0.7.1"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "cca424247104946a59dacd27eaad296223b7feec3d168a6dd04585183091eb0b"
+dependencies = [
+ "bitflags 2.10.0",
+ "byteorder",
+ "enum-as-inner",
+ "libc",
+ "thiserror 2.0.12",
+ "walkdir",
+]
+
 [[package]]
 name = "sysinfo"
 version = "0.34.2"
@@ -4948,30 +4846,30 @@ dependencies = [
 
 [[package]]
 name = "time"
-version = "0.3.37"
+version = "0.3.47"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "35e7868883861bd0e56d9ac6efcaaca0d6d5d82a2a7ec8209ff492c07cf37b21"
+checksum = "743bd48c283afc0388f9b8827b976905fb217ad9e647fae3a379a9283c4def2c"
 dependencies = [
  "deranged",
  "itoa",
  "num-conv",
  "powerfmt",
- "serde",
+ "serde_core",
  "time-core",
  "time-macros",
 ]
 
 [[package]]
 name = "time-core"
-version = "0.1.2"
+version = "0.1.8"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "ef927ca75afb808a4d64dd374f00a2adf8d0fcff8e7b184af886c3c87ec4a3f3"
+checksum = "7694e1cfe791f8d31026952abf09c69ca6f6fa4e1a1229e18988f06a04a12dca"
 
 [[package]]
 name = "time-macros"
-version = "0.2.19"
+version = "0.2.27"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "2834e6017e3e5e4b9834939793b282bc03b37a3336245fa820e35e233e2a85de"
+checksum = "2e70e4c5a0e0a8a4823ad65dfe1a6930e4f4d756dcd9dd7939022b5e8c501215"
 dependencies = [
  "num-conv",
  "time-core",
@@ -5081,21 +4979,12 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "52a15c15b1bc91f90902347eff163b5b682643aff0c8e972912cca79bd9208dd"
 dependencies = [
  "bytes",
- "futures 0.3.28",
+ "futures",
  "libc",
  "tokio",
  "vsock",
 ]
 
-[[package]]
-name = "toml"
-version = "0.4.10"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "758664fc71a3a69038656bee8b6be6477d2a6c315a6b81f7081f591bffa4111f"
-dependencies = [
- "serde",
-]
-
 [[package]]
 name = "toml"
 version = "0.5.11"
@@ -5238,7 +5127,7 @@ dependencies = [
  "async-trait",
  "byteorder",
  "crossbeam",
- "futures 0.3.28",
+ "futures",
  "home",
  "libc",
  "log",
@@ -5440,16 +5329,13 @@ version = "0.1.0"
 dependencies = [
  "agent",
  "anyhow",
- "async-std",
  "async-trait",
  "awaitgroup",
  "common",
  "containerd-shim-protos",
- "futures 0.3.28",
  "hypervisor",
  "kata-sys-util",
  "kata-types",
- "lazy_static",
  "libc",
  "logging",
  "nix 0.26.4",
@@ -5465,7 +5351,6 @@ dependencies = [
  "slog-scope",
  "strum 0.24.1",
  "tokio",
- "toml 0.4.10",
  "tracing",
  "url",
  "uuid 1.18.1",
@@ -6098,7 +5983,7 @@ dependencies = [
  "async-trait",
  "blocking",
  "enumflags2",
- "event-listener 5.4.1",
+ "event-listener",
  "futures-core",
  "futures-lite",
  "hex",

Makefile

@@ -47,10 +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-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 
+	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 \

VERSION

@@ -1 +1 @@
-3.26.0
+3.27.0

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

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.
+the following example. Specifying the `OS_VERSION` is required when using `distro="ubuntu"`.
 
 ```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 ./rootfs.sh "${distro}"'
+$ script -fec 'sudo -E USE_DOCKER=true OS_VERSION=noble ./rootfs.sh "${distro}"'
 $ popd
 ```
 

docs/Kata-Containers-Lifecycle-Management.md

@@ -1,118 +0,0 @@
-# Kata Containers Lifecycle Management
-
-## Overview
-
-Kata Containers lifecycle management in Kubernetes consists of two operations:
-
-1. **Installation** - Deploy Kata Containers to cluster nodes
-2. **Upgrades** - Update Kata Containers to newer versions without disrupting workloads
-
-The Kata Containers project provides two Helm charts to address these needs:
-
-| Chart | Purpose |
-|-------|---------|
-| `kata-deploy` | Initial installation and configuration |
-| `kata-lifecycle-manager` | Orchestrated rolling upgrades with verification |
-
----
-
-## Installation with kata-deploy
-
-The `kata-deploy` Helm chart installs Kata Containers across all (or selected) nodes using a Kubernetes DaemonSet. When deployed, it:
-
-- Installs Kata runtime binaries on each node
-- Configures the container runtime (containerd) to use Kata
-- Registers RuntimeClasses (`kata-qemu-nvidia-gpu-snp`, `kata-qemu-nvidia-gpu-tdx`, `kata-qemu-nvidia-gpu`, etc.)
-
-After installation, workloads can use Kata isolation by specifying `runtimeClassName: kata-qemu-nvidia-gpu-snp` (or another Kata RuntimeClass) in their pod spec.
-
----
-
-## Upgrades with kata-lifecycle-manager
-
-### The Problem
-
-Standard `helm upgrade kata-deploy` updates all nodes simultaneously via the DaemonSet. This approach:
-
-- Provides no per-node verification
-- Offers no controlled rollback mechanism
-- Can leave the cluster in an inconsistent state if something fails
-
-### The Solution
-
-The `kata-lifecycle-manager` Helm chart uses Argo Workflows to orchestrate upgrades with the following guarantees:
-
-| Guarantee | Description |
-|-----------|-------------|
-| **Sequential Processing** | Nodes are upgraded one at a time |
-| **Per-Node Verification** | A user-provided pod validates Kata functionality after each node upgrade |
-| **Fail-Fast** | If verification fails, the workflow stops immediately |
-| **Automatic Rollback** | On failure, Helm rollback is executed and the node is restored |
-
-### Upgrade Flow
-
-For each node in the cluster:
-
-1. **Cordon** - Mark node as unschedulable
-2. **Drain** (optional) - Evict existing workloads
-3. **Upgrade** - Run `helm upgrade kata-deploy` targeting this node
-4. **Wait** - Ensure kata-deploy DaemonSet pod is ready
-5. **Verify** - Run verification pod to confirm Kata works
-6. **Uncordon** - Mark node as schedulable again
-
-If verification fails on any node, the workflow:
-- Rolls back the Helm release
-- Uncordons the node
-- Stops processing (remaining nodes are not upgraded)
-
-### Verification Pod
-
-Users must provide a verification pod that tests Kata functionality. This pod:
-
-- Uses a Kata RuntimeClass
-- Is scheduled on the specific node being verified
-- Runs whatever validation logic the user requires (smoke tests, attestation checks, etc.)
-
-**Basic GPU Verification Example:**
-
-For clusters with NVIDIA GPUs, the CUDA VectorAdd sample provides a more comprehensive verification:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: ${TEST_POD}
-spec:
-  runtimeClassName: kata-qemu-nvidia-gpu-snp # or kata-qemu-nvidia-gpu-tdx
-  restartPolicy: Never
-  nodeSelector:
-    kubernetes.io/hostname: ${NODE}
-  containers:
-  - name: cuda-vectoradd
-    image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04
-    resources:
-      limits:
-        nvidia.com/pgpu: "1"
-        memory: 16Gi
-```
-
-This verifies that GPU passthrough works correctly with the upgraded Kata runtime.
-
-The placeholders `${NODE}` and `${TEST_POD}` are substituted at runtime.
-
----
-
-## Demo Recordings
-
-| Demo | Description | Link |
-|------|-------------|------|
-| Sunny Path | Successful upgrade from 3.24.0 to 3.25.0 | [TODO] |
-| Rainy Path | Failed verification triggers rollback | [TODO] |
-
----
-
-## References
-
-- [kata-deploy Helm Chart](tools/packaging/kata-deploy/helm-chart/README.md)
-- [kata-lifecycle-manager Helm Chart](tools/packaging/kata-deploy/helm-chart/kata-lifecycle-manager/README.md)
-- [kata-lifecycle-manager Design Document](docs/design/kata-lifecycle-manager-design.md)

docs/Limitations.md

@@ -187,9 +187,10 @@ 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`, 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.
+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.
 
 [runtime-config]: /src/runtime/README.md#configuration
 [k8s-hostpath]: https://kubernetes.io/docs/concepts/storage/volumes/#hostpath
@@ -206,7 +207,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`

docs/Release-Process.md

@@ -28,15 +28,13 @@ Bug fixes are released as part of `MINOR` or `MAJOR` releases only. `PATCH` is a
 
 ## Release Process
 
-### Bump the `VERSION` and `Chart.yaml` files
+### Bump the `VERSION` and `Chart.yaml` file
 
 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 following `Chart.yaml` files:
-- [`kata-deploy/Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-deploy/Chart.yaml)
-- [`kata-lifecycle-manager/Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-lifecycle-manager/Chart.yaml)
-
-Have the PR merged before proceeding.
+`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
 

docs/design/README.md

@@ -19,7 +19,6 @@ Kata Containers design documents:
 - [Design for direct-assigned volume](direct-blk-device-assignment.md)
 - [Design for core-scheduling](core-scheduling.md)
 - [Virtualization Reference Architecture](kata-vra.md)
-- [Design for kata-lifecycle-manager Helm chart](kata-lifecycle-manager-design.md)
 ---
 
 - [Design proposals](proposals)

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

@@ -111,20 +111,20 @@ In our case, there will be a variety of resources, and every resource has severa
 - 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. 
+  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? 
-  
+- 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?
@@ -134,35 +134,35 @@ In our case, there will be a variety of resources, and every resource has severa
   `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 
+   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/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-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-lifecycle-manager-design.md

@@ -1,502 +0,0 @@
-# Kata Containers Lifecycle Manager Design
-
-## Summary
-
-This document proposes a Helm chart-based orchestration solution for Kata Containers that
-enables controlled, node-by-node upgrades with verification and rollback capabilities
-using Argo Workflows.
-
-## Motivation
-
-### Problem Statement
-
-Upgrading Kata Containers in a production Kubernetes cluster presents several challenges:
-
-1. **Workload Scheduling Control**: New Kata workloads should not be scheduled on a node
-   during upgrade until the new runtime is verified.
-
-2. **Verification Gap**: There is no standardized way to verify that Kata is working correctly
-   after an upgrade before allowing workloads to return to the node. This solution addresses
-   the gap by running a user-provided verification pod on each upgraded node.
-
-3. **Rollback Complexity**: If an upgrade fails, administrators must manually coordinate
-   rollback across multiple nodes.
-
-4. **Controlled Rollout**: Operators need the ability to upgrade nodes incrementally
-   (canary approach) with fail-fast behavior if any node fails verification.
-
-5. **Multi-Architecture Support**: The upgrade tooling must work across all architectures
-   supported by Kata Containers (amd64, arm64, s390x, ppc64le).
-
-### Current State
-
-The `kata-deploy` Helm chart provides installation and configuration of Kata Containers,
-including a post-install verification job. However, there is no built-in mechanism for
-orchestrating upgrades across nodes in a controlled manner.
-
-## Goals
-
-1. Provide a standardized, automated way to upgrade Kata Containers node-by-node
-2. Ensure each node is verified before returning to service
-3. Support user-defined verification logic
-4. Automatically rollback if verification fails
-5. Work with the existing `kata-deploy` Helm chart
-6. Support all Kata-supported architectures
-
-## Non-Goals
-
-1. Initial Kata Containers installation (use kata-deploy Helm chart for that)
-2. Managing Kubernetes cluster upgrades
-3. Providing Kata-specific verification logic (this is user responsibility)
-4. Managing Argo Workflows installation
-
-## Argo Workflows Dependency
-
-### What Works Without Argo
-
-The following components work independently of Argo Workflows:
-
-| Component | Description |
-|-----------|-------------|
-| **kata-deploy Helm chart** | Full installation, configuration, `RuntimeClasses` |
-| **Post-install verification** | Helm hook runs verification pod after install |
-| **Label-gated deployment** | Progressive rollout via node labels |
-| **Manual upgrades** | User can script: cordon, helm upgrade, verify, `uncordon` |
-
-Users who do not want Argo can still:
-- Install and configure Kata via kata-deploy
-- Perform upgrades manually or with custom scripts
-- Use the verification pod pattern in their own automation
-
-### What Requires Argo
-
-The kata-lifecycle-manager Helm chart provides orchestration via Argo Workflows:
-
-| Feature | Description |
-|---------|-------------|
-| **Automated node-by-node upgrades** | Sequential processing with fail-fast |
-| **Taint-based node selection** | Select nodes by taint key/value |
-| **`WorkflowTemplate`** | Reusable upgrade workflow |
-| **Rollback entrypoint** | `argo submit --entrypoint rollback-node` |
-| **Status tracking** | Node annotations updated at each phase |
-
-### For Users Already Using Argo
-
-If your cluster already has Argo Workflows installed:
-
-```bash
-# Install kata-lifecycle-manager - integrates with your existing Argo installation
-helm install kata-lifecycle-manager oci://ghcr.io/kata-containers/kata-deploy-charts/kata-lifecycle-manager \
-  --set argoNamespace=argo \
-  --set-file defaults.verificationPod=./verification-pod.yaml
-
-# Trigger upgrades via argo CLI or integrate with existing workflows
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager -p target-version=3.25.0
-```
-
-kata-lifecycle-manager can also be triggered by other Argo workflows, CI/CD pipelines, or `GitOps`
-tools that support Argo.
-
-### For Users Not Wanting Argo
-
-If you prefer not to use Argo Workflows:
-
-1. **Use kata-deploy directly** - handles installation and basic verification
-2. **Script your own orchestration** - example approach:
-
-```bash
-#!/bin/bash
-# Manual upgrade script (no Argo required)
-set -euo pipefail
-
-VERSION="3.25.0"
-
-# Upgrade each node with Kata runtime
-kubectl get nodes -l katacontainers.io/kata-runtime=true -o name | while read -r node_path; do
-  NODE="${node_path#node/}"
-  echo "Upgrading $NODE..."
-  kubectl cordon "$NODE"
-  
-  helm upgrade kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-    --namespace kube-system \
-    --version "$VERSION" \
-    --reuse-values \
-    --wait
-  
-  # Wait for DaemonSet pod on this node
-  kubectl rollout status daemonset/kata-deploy -n kube-system
-  
-  # Run verification (apply your pod, wait, check exit code)
-  kubectl apply -f verification-pod.yaml
-  kubectl wait pod/kata-verify --for=jsonpath='{.status.phase}'=Succeeded --timeout=180s
-  kubectl delete pod/kata-verify
-  
-  kubectl uncordon "$NODE"
-  echo "$NODE upgraded successfully"
-done
-```
-
-This approach requires more manual effort but avoids the Argo dependency.
-
-## Proposed Design
-
-### Architecture Overview
-
-```text
-┌─────────────────────────────────────────────────────────────────┐
-│                    Argo Workflows Controller                    │
-│                         (pre-installed)                         │
-└────────────────────────────┬────────────────────────────────────┘
-                             │
-                             ▼
-┌──────────────────────────────────────────────────────────────┐
-│                    kata-lifecycle-manager Helm Chart                   │
-│  ┌────────────────────────────────────────────────────────┐  │
-│  │                   WorkflowTemplate                     │  │
-│  │  - upgrade-all-nodes (entrypoint)                      │  │
-│  │  - upgrade-single-node (per-node steps)                │  │
-│  │  - rollback-node (manual recovery)                     │  │
-│  └────────────────────────────────────────────────────────┘  │
-│  ┌────────────────────────────────────────────────────────┐  │
-│  │                   RBAC Resources                       │  │
-│  │  - ServiceAccount                                      │  │
-│  │  - ClusterRole (node, pod, helm operations)            │  │
-│  │  - ClusterRoleBinding                                  │  │
-│  └────────────────────────────────────────────────────────┘  │
-└──────────────────────────────────────────────────────────────┘
-                             │
-                             ▼
-┌─────────────────────────────────────────────────────────────────┐
-│                    kata-deploy Helm Chart                       │
-│                   (existing installation)                       │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### Upgrade Flow
-
-For each node selected by the upgrade label:
-
-```text
-┌────────────┐    ┌──────────────┐    ┌────────────┐    ┌────────────┐
-│  Prepare   │───▶│  Cordon      │───▶│  Upgrade   │───▶│Wait Ready  │
-│ (annotate) │    │  (mark       │    │  (helm     │    │(kata-deploy│
-│            │    │unschedulable)│    │ upgrade)   │    │ DaemonSet) │
-└────────────┘    └──────────────┘    └────────────┘    └────────────┘
-                                                               │
-                                                               ▼
-                  ┌────────────┐    ┌──────────────┐    ┌────────────┐
-                  │  Complete  │◀───│   Uncordon   │◀───│  Verify    │
-                  │ (annotate  │    │  (mark       │    │  (user pod)│
-                  │  version)  │    │schedulable)  │    │            │
-                  └────────────┘    └──────────────┘    └────────────┘
-```
-
-**Note:** Drain is not required for Kata upgrades. Running Kata VMs continue using
-the in-memory binaries. Only new workloads use the upgraded binaries. Cordon ensures
-the verification pod runs before any new workloads are scheduled with the new runtime.
-
-**Optional Drain:** For users who prefer to evict workloads before any maintenance
-operation, an optional drain step can be enabled via `drain-enabled=true`. When
-enabled, an additional drain step runs after cordon and before upgrade.
-
-### Node Selection Model
-
-Nodes can be selected for upgrade using **labels**, **taints**, or **both**.
-
-**Label-based selection:**
-
-```bash
-# Select nodes by label
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  -p target-version=3.25.0 \
-  -p node-selector="katacontainers.io/kata-lifecycle-manager-window=true"
-```
-
-**Taint-based selection:**
-
-Some organizations use taints to mark nodes for maintenance. The workflow supports
-selecting nodes by taint key and optionally taint value:
-
-```bash
-# Select nodes with a specific taint
-kubectl taint nodes worker-1 kata-lifecycle-manager=pending:NoSchedule
-
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  -p target-version=3.25.0 \
-  -p node-taint-key=kata-lifecycle-manager \
-  -p node-taint-value=pending
-```
-
-**Combined selection:**
-
-Labels and taints can be used together for precise targeting:
-
-```bash
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  -p target-version=3.25.0 \
-  -p node-selector="node-pool=kata-pool" \
-  -p node-taint-key=maintenance
-```
-
-This allows operators to:
-1. Upgrade a single canary node first
-2. Gradually add nodes to the upgrade window
-3. Control upgrade timing via `GitOps` or automation
-4. Integrate with existing taint-based maintenance workflows
-
-### Node Pool Support
-
-The node selector and taint selector parameters enable basic node pool targeting:
-
-```bash
-# Upgrade only nodes matching a specific node pool label
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  -p target-version=3.25.0 \
-  -p node-selector="node-pool=kata-pool"
-```
-
-**Current Capabilities:**
-
-| Feature | Status | Chart | Notes |
-|---------|--------|-------|-------|
-| Label-based selection | Supported | kata-lifecycle-manager | Works with any label combination |
-| Taint-based selection | Supported | kata-lifecycle-manager | Select by taint key/value |
-| Sequential upgrades | Supported | kata-lifecycle-manager | One node at a time with fail-fast |
-| Pool-specific verification pods | Not supported | kata-lifecycle-manager | Same verification for all nodes |
-| Pool-ordered upgrades | Not supported | kata-lifecycle-manager | Upgrade pool A before pool B |
-
-See the [Potential Enhancements](#potential-enhancements) section for future work.
-
-### Verification Model
-
-**Verification runs on each node that is upgraded.** The node is only `uncordoned` after
-its verification pod succeeds. If verification fails, automatic rollback is triggered
-to restore the previous version before `uncordoning` the node.
-
-**Common failure modes detected by verification:**
-- Pod stuck in Pending/`ContainerCreating` (runtime can't start VM)
-- Pod crashes immediately (containerd/CRI-O configuration issues)
-- Pod times out (resource issues, image pull failures)
-- Pod exits with non-zero code (verification logic failed)
-
-All of these trigger automatic rollback. The workflow logs include pod status, events,
-and logs to help diagnose the issue.
-
-The user provides a complete Pod YAML that:
-- Uses the Kata runtime class they want to verify
-- Contains their verification logic (e.g., attestation checks)
-- Exits 0 on success, non-zero on failure
-- Includes tolerations for cordoned nodes (verification runs while node is cordoned)
-- Includes a `nodeSelector` to ensure it runs on the specific node being upgraded
-
-When upgrading multiple nodes (via label selector), nodes are processed sequentially.
-For each node, the following placeholders are substituted with that node's specific values,
-ensuring the verification pod runs on the exact node that was just upgraded:
-
-- `${NODE}` - The hostname of the node being upgraded/verified
-- `${TEST_POD}` - A generated unique pod name
-
-Example verification pod:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: ${TEST_POD}
-spec:
-  runtimeClassName: kata-qemu
-  restartPolicy: Never
-  nodeSelector:
-    kubernetes.io/hostname: ${NODE}
-  tolerations:
-    - operator: Exists    # Required: node is cordoned during verification
-  containers:
-    - name: verify
-      image: quay.io/kata-containers/alpine-bash-curl:latest
-      command: ["uname", "-a"]
-```
-
-This design keeps verification logic entirely in the user's domain, supporting:
-- Different runtime classes (`kata-qemu`, `kata-qemu-snp`, `kata-qemu-tdx`, etc.)
-- TEE-specific attestation verification
-- GPU/accelerator validation
-- Custom application smoke tests
-
-### Sequential Execution with Fail-Fast
-
-Nodes are upgraded strictly sequentially using recursive Argo templates. This design
-ensures that if any node fails verification, the workflow stops immediately before
-touching remaining nodes, preventing a mixed-version fleet.
-
-Alternative approaches considered:
-- **`withParam` + semaphore**: Provides cleaner UI but semaphore only controls concurrency,
-  not failure propagation. Other nodes would still proceed after one fails.
-- **`withParam` + `failFast`**: Would be ideal, but Argo only supports `failFast` for DAG
-  tasks, not for steps with `withParam`.
-
-The recursive template approach (`upgrade-node-chain`) naturally provides fail-fast
-behavior because if any step in the chain fails, the recursion stops.
-
-### Status Tracking
-
-Node upgrade status is tracked via Kubernetes annotations:
-
-| Annotation | Values |
-|------------|--------|
-| `katacontainers.io/kata-lifecycle-manager-status` | preparing, cordoned, draining, upgrading, verifying, completed, rolling-back, rolled-back |
-| `katacontainers.io/kata-current-version` | Version string (e.g., "3.25.0") |
-
-This enables:
-- Monitoring upgrade progress via `kubectl get nodes`
-- Integration with external monitoring systems
-- Recovery from interrupted upgrades
-
-### Rollback Support
-
-**Automatic rollback on verification failure:** If the verification pod fails (non-zero exit),
-kata-lifecycle-manager automatically:
-1. Runs `helm rollback` to revert to the previous Helm release
-2. Waits for kata-deploy DaemonSet to be ready with the previous version
-3. `Uncordons` the node
-4. Annotates the node with `rolled-back` status
-
-This ensures nodes are never left in a broken state.
-
-**Manual rollback:** For cases where you need to rollback a successfully upgraded node:
-
-```bash
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  --entrypoint rollback-node \
-  -p node-name=worker-1
-```
-
-## Components
-
-### Container Images
-
-Two multi-architecture container images are built and published:
-
-| Image | Purpose | Architectures |
-|-------|---------|---------------|
-| `quay.io/kata-containers/kubectl:latest` | Kubernetes operations | amd64, arm64, s390x, ppc64le |
-| `quay.io/kata-containers/helm:latest` | Helm operations | amd64, arm64, s390x, ppc64le |
-
-Images are rebuilt weekly to pick up security updates and tool version upgrades.
-
-### Helm Chart Structure
-
-```text
-kata-lifecycle-manager/
-├── Chart.yaml                  # Chart metadata
-├── values.yaml                 # Configurable defaults
-├── README.md                   # Usage documentation
-└── templates/
-    ├── _helpers.tpl            # Template helpers
-    ├── rbac.yaml               # ServiceAccount, ClusterRole, ClusterRoleBinding
-    └── workflow-template.yaml  # Argo `WorkflowTemplate`
-```
-
-### RBAC Requirements
-
-The workflow requires the following permissions:
-
-| Resource | Verbs | Purpose |
-|----------|-------|---------|
-| nodes | get, list, watch, patch | `cordon`/`uncordon`, annotations |
-| pods | get, list, watch, create, delete | Verification pods |
-| pods/log | get | Verification output |
-| `daemonsets` | get, list, watch | Wait for `kata-deploy` |
-
-## User Experience
-
-### Installation
-
-```bash
-# Install kata-lifecycle-manager with verification config
-helm install kata-lifecycle-manager oci://ghcr.io/kata-containers/kata-deploy-charts/kata-lifecycle-manager \
-  --set-file defaults.verificationPod=/path/to/verification-pod.yaml
-```
-
-### Triggering an Upgrade
-
-```bash
-# Label nodes for upgrade
-kubectl label node worker-1 katacontainers.io/kata-lifecycle-manager-window=true
-
-# Submit upgrade workflow
-argo submit -n argo --from workflowtemplate/kata-lifecycle-manager \
-  -p target-version=3.25.0
-
-# Watch progress
-argo watch @latest
-```
-
-### Monitoring
-
-```bash
-kubectl get nodes \
-  -L katacontainers.io/kata-runtime \
-  -L katacontainers.io/kata-lifecycle-manager-status \
-  -L katacontainers.io/kata-current-version
-```
-
-## Security Considerations
-
-1. **Namespace-Scoped Templates**: The chart creates a `WorkflowTemplate` (namespace-scoped)
-   rather than `ClusterWorkflowTemplate` by default, reducing blast radius.
-
-2. **Required Verification**: The chart fails to install if `defaults.verificationPod` is
-   not provided, ensuring upgrades are always verified.
-
-3. **Minimal RBAC**: The `ServiceAccount` has only the permissions required for upgrade
-   operations.
-
-4. **User-Controlled Verification**: Verification logic is entirely user-defined, avoiding
-   any hardcoded assumptions about what "working" means.
-
-## Integration with Release Process
-
-The `kata-lifecycle-manager` chart is:
-- Packaged alongside `kata-deploy` during releases
-- Published to the same OCI registries (`quay.io`, `ghcr.io`)
-- Versioned to match `kata-deploy`
-
-## Potential Enhancements
-
-The following enhancements could be considered if needed:
-
-### kata-lifecycle-manager
-
-1. **Pool-Specific Verification**: Different verification pods for different node pools
-   (e.g., GPU nodes vs. CPU-only nodes).
-
-2. **Ordered Pool Upgrades**: Upgrade node pool A completely before starting pool B.
-
-## Alternatives Considered
-
-### 1. DaemonSet-Based Upgrades
-
-Using a DaemonSet to coordinate upgrades on each node.
-
-**Rejected because**: DaemonSets don't provide the node-by-node sequencing and
-verification workflow needed for controlled upgrades.
-
-### 2. Operator Pattern
-
-Building a Kubernetes Operator to manage upgrades.
-
-**Rejected because**: Adds significant complexity and maintenance burden. Argo Workflows
-is already widely adopted and provides the orchestration primitives needed.
-
-### 3. Shell Script Orchestration
-
-Providing a shell script that loops through nodes.
-
-**Rejected because**: Less reliable, harder to monitor, no built-in retry/recovery,
-and doesn't integrate with Kubernetes-native tooling.
-
-## References
-
-- [kata-deploy Helm Chart](https://github.com/kata-containers/kata-containers/tree/main/tools/packaging/kata-deploy/helm-chart/kata-deploy)
-- [Argo Workflows](https://argoproj.github.io/argo-workflows/)
-- [Helm Documentation](https://helm.sh/docs/)

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/how-to/README.md

@@ -49,4 +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 seccomp with runtime-rs](how-to-use-seccomp-with-runtime-rs.md)

docs/how-to/containerd-kata.md

@@ -1,24 +1,24 @@
 # 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 v1.5.0-rc2 or above, and containerd v1.2.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 
+[`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:
@@ -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,7 +123,7 @@ The following sections outline how to add Kata Containers to the configurations.
 
 #### Kata Containers as a `RuntimeClass`
 
-For 
+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
@@ -132,8 +132,8 @@ The `RuntimeClass` is suggested.
 
 The following configuration includes two runtime classes:
 - `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 
+- `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
@@ -168,9 +168,9 @@ This `ConfigPath` option is optional. If you do not specify it, shimv2 first tri
 
 #### 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.cri.containerd]
@@ -201,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`:
 
@@ -324,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-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`, `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. 
+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,10 +46,10 @@ $ sudo mkfs.ext4 /tmp/stor/rawdisk01.20g
 
 ```json
 {
-  "device": "/tmp/stor/rawdisk01.20g", 
-  "volume_type": "directvol", 
-  "fs_type": "ext4", 
-  "metadata":"{}", 
+  "device": "/tmp/stor/rawdisk01.20g",
+  "volume_type": "directvol",
+  "fs_type": "ext4",
+  "metadata":"{}",
   "options": []
 }
 ```
@@ -57,7 +57,7 @@ $ sudo mkfs.ext4 /tmp/stor/rawdisk01.20g
 ```bash
 $ 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 
+$ cat W1lMa2F0ZXQva2F0YS10a2F0DAxvbC0wMDEvdm9sdW1lMDAx/mountInfo.json
 {"volume_type":"directvol","device":"/tmp/stor/rawdisk01.20g","fs_type":"ext4","metadata":{},"options":[]}
 ```
 
@@ -79,8 +79,8 @@ In this scenario, the device's host kernel driver will be replaced by `vfio-pci`
 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
 ...
@@ -99,9 +99,9 @@ First, configure the `mountinfo.json`, as below:
 ```json
 {
   "device": "45:00.1",
-  "volume_type": "vfiovol", 
-  "fs_type": "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", 
-  "fs_type": "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", 
-  "fs_type": "ext4", 
-  "metadata":"{}", 
+  "device": "/dev/vfio/110",
+  "volume_type": "vfiovol",
+  "fs_type": "ext4",
+  "metadata":"{}",
   "options": []
 }
 ```
@@ -135,7 +135,7 @@ 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\", \"fs_type\": \"ext4\", \"metadata\":"{}", \"options\": []}"
 $ # /kubelet/kata-vfio-vol-003/directvol003 <==> /run/kata-containers/shared/direct-volumes/F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx
-$ cat F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx/mountInfo.json 
+$ cat F0va22F0ZvaS12F0YS10a2F0DAxvbC0F0ZXvdm9sdF0Z0YSx/mountInfo.json
 {"volume_type":"vfiovol","device":"/dev/vfio/110","fs_type":"ext4","metadata":{},"options":[]}
 ```
 

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-sandbox-config-kata.md

@@ -59,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,11 +44,13 @@ 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
@@ -182,7 +184,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-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

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.
 
@@ -74,4 +74,4 @@ See below example config:
 ```
 
  - [Kata Containers with CRI-O](../how-to/run-kata-with-k8s.md#cri-o)
-  
+

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

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

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

@@ -10,8 +10,8 @@ much like a process fork done by the kernel but here we *fork* VMs.
 
 ### How is this different from VMCache
 
-Both [VMCache](../how-to/what-is-vm-cache-and-how-do-I-use-it.md) and VM templating help speed up new container creation.  
-When VMCache enabled, new VMs are created by the VMCache server.  So it is not vulnerable to share memory CVE because each VM doesn't share the memory.  
+Both [VMCache](../how-to/what-is-vm-cache-and-how-do-I-use-it.md) and VM templating help speed up new container creation.
+When VMCache enabled, new VMs are created by the VMCache server.  So it is not vulnerable to share memory CVE because each VM doesn't share the memory.
 VM templating saves a lot of memory if there are many Kata Containers running on the same host.
 
 ### What are the Pros

docs/install/README.md

@@ -1,11 +1,11 @@
 # Kata Containers installation guides
 
-The following is an overview of the different installation methods available. 
+The following is an overview of the different installation methods available.
 
 ## Prerequisites
 
-Kata Containers requires nested virtualization or bare metal. Check 
-[hardware requirements](./../../README.md#hardware-requirements) to see if your system is capable of running Kata 
+Kata Containers requires nested virtualization or bare metal. Check
+[hardware requirements](./../../README.md#hardware-requirements) to see if your system is capable of running Kata
 Containers.
 
 The Kata Deploy Helm chart is the preferred  way to install all of the binaries and

docs/install/container-manager/containerd/containerd-install.md

@@ -101,7 +101,7 @@
     ```
 
     > **Note:**
-    >    
+    >
     > The containerd daemon needs to be able to find the
     > `containerd-shim-kata-v2` binary to allow Kata Containers to be created.
 

docs/install/kata-containers-3.0-rust-runtime-installation-guide.md

@@ -1,10 +1,10 @@
 # Kata Containers 3.0 rust runtime installation
-The following is an overview of the different installation methods available. 
+The following is an overview of the different installation methods available.
 
 ## Prerequisites
 
-Kata Containers 3.0 rust runtime requires nested virtualization or bare metal. Check 
-[hardware requirements](/src/runtime/README.md#hardware-requirements) to see if your system is capable of running Kata 
+Kata Containers 3.0 rust runtime requires nested virtualization or bare metal. Check
+[hardware requirements](/src/runtime/README.md#hardware-requirements) to see if your system is capable of running Kata
 Containers.
 
 ### Platform support
@@ -25,10 +25,10 @@ architectures:
 | Installation method                                  | Description                                                                                  | Automatic updates | Use case                                                                                      | Availability
 |------------------------------------------------------|----------------------------------------------------------------------------------------------|-------------------|-----------------------------------------------------------------------------------------------|----------- |
 | [Using kata-deploy](#kata-deploy-installation)       | The preferred way to deploy the Kata Containers distributed binaries on a Kubernetes cluster | **No!**           | Best way to give it a try on kata-containers on an already up and running Kubernetes cluster. | Yes |
-| [Using official distro packages](#official-packages) | Kata packages provided by Linux distributions official repositories                          | yes               | Recommended for most users. | No |                                                                   
+| [Using official distro packages](#official-packages) | Kata packages provided by Linux distributions official repositories                          | yes               | Recommended for most users. | No |
 | [Automatic](#automatic-installation)                 | Run a single command to install a full system                                                | **No!**           | For those wanting the latest release quickly.                                                 | No |
 | [Manual](#manual-installation)                       | Follow a guide step-by-step to install a working system                                      | **No!**           | For those who want the latest release with more control.                                      | No |
-| [Build from source](#build-from-source-installation) | Build the software components manually                                                       | **No!**           | Power users and developers only.  | Yes |              
+| [Build from source](#build-from-source-installation) | Build the software components manually                                                       | **No!**           | Power users and developers only.  | Yes |
 
 ### Kata Deploy Installation
 
@@ -57,7 +57,7 @@ Follow the [`kata-deploy`](../../tools/packaging/kata-deploy/helm-chart/README.m
     ```
 
 * Musl support for fully static binary
-    
+
     Example for `x86_64`
     ```
     $ rustup target add x86_64-unknown-linux-musl

docs/threat-model/threat-model.md

@@ -80,8 +80,8 @@ In case of Kata, today the devices which we need in the guest are:
 - Dynamic Resource Management: `ACPI` is utilized to allow for dynamic VM
  resource management (for example: CPU, memory, device hotplug). This is
  required when containers are resized, or more generally when containers are
- added to a pod. 
- 
+ added to a pod.
+
 How these devices are utilized varies depending on the VMM utilized. We clarify
 the default settings provided when integrating Kata with the QEMU, Dragonball,
 Firecracker and Cloud Hypervisor VMMs in the following sections.

docs/tracing.md

@@ -107,7 +107,7 @@ Containers agent:
 By default, tracing is disabled for all components. To enable _any_ form of
 tracing an `enable_tracing` option must be enabled for at least one component.
 
-> **Note:** 
+> **Note:**
 >
 > Enabling this option will only allow tracing for subsequently
 > started containers.
@@ -187,7 +187,7 @@ from improvements in the tracing infrastructure. Overall, the impact of
 enabling runtime and agent tracing should be extremely low.
 
 ## Agent shutdown behaviour
- 
+
 In normal operation, the Kata runtime manages the VM shutdown and performs
 certain optimisations to speed up this process. However, if agent tracing is
 enabled, the agent itself is responsible for shutting down the VM. This it to

docs/use-cases/CEX-passthrough-and-coco.md

@@ -83,10 +83,10 @@ If you have [s390-tools](https://github.com/ibm-s390-linux/s390-tools) available
 
 ```
 [container]# lszcrypt -V
-CARD.DOM TYPE  MODE        STATUS     REQUESTS  PENDING HWTYPE QDEPTH FUNCTIONS  DRIVER      SESTAT     
+CARD.DOM TYPE  MODE        STATUS     REQUESTS  PENDING HWTYPE QDEPTH FUNCTIONS  DRIVER      SESTAT
 --------------------------------------------------------------------------------------------------------
-03       CEX8P EP11-Coproc online            2        0     14     08 -----XN-F- cex4card    -          
-03.0041  CEX8P EP11-Coproc online            2        0     14     08 -----XN-F- cex4queue   usable     
+03       CEX8P EP11-Coproc online            2        0     14     08 -----XN-F- cex4card    -
+03.0041  CEX8P EP11-Coproc online            2        0     14     08 -----XN-F- cex4queue   usable
 ```
 
 ---

docs/use-cases/Intel-Discrete-GPU-passthrough-and-Kata.md

@@ -6,15 +6,15 @@ For integrated GPUs please refer to [Integrate-Intel-GPUs-with-Kata](Intel-GPU-p
 
 > **Note:** These instructions are for a system that has an x86_64 CPU.
 
-An Intel Discrete GPU can be passed to a Kata Container using GPU passthrough, 
+An Intel Discrete GPU can be passed to a Kata Container using GPU passthrough,
 or SR-IOV passthrough.
 
-In Intel GPU pass-through mode, an entire physical GPU is directly assigned to one VM. 
+In Intel GPU pass-through mode, an entire physical GPU is directly assigned to one VM.
 In this mode of operation, the GPU is accessed exclusively by the Intel driver running in
 the VM to which it is assigned. The GPU is not shared among VMs.
 
 With SR-IOV mode, it is possible to pass a Virtual GPU instance to a virtual machine.
-With this, multiple Virtual GPU instances can be carved out of a single physical GPU 
+With this, multiple Virtual GPU instances can be carved out of a single physical GPU
 and be passed to different VMs, allowing the GPU to be shared.
 
 | Technology | Description |
@@ -28,13 +28,13 @@ Intel GPUs Recommended for Virtualization:
 
 - Intel® Data Center GPU Max Series (`Ponte Vecchio`)
 - Intel® Data Center GPU Flex Series (`Arctic Sound-M`)
-- Intel® Data Center GPU Arc Series 
+- Intel® Data Center GPU Arc Series
 
 The following steps outline the workflow for using an Intel Graphics device with Kata Containers.
 
 ## Host BIOS requirements
 
-Hardware such as Intel Max and Flex series require larger PCI BARs. 
+Hardware such as Intel Max and Flex series require larger PCI BARs.
 
 For large BAR devices, MMIO mapping above the 4GB address space should be enabled in the PCI configuration of the BIOS.
 
@@ -89,7 +89,7 @@ CONFIG_VFIO_IOMMU_TYPE1
 CONFIG_VFIO_PCI
 ```
 
-## Host kernel command line 
+## Host kernel command line
 
 Your host kernel needs to be booted with `intel_iommu=on` and `i915.enable_iaf=0` on the kernel command
 line.
@@ -112,8 +112,8 @@ $ sudo update-grub
 
 For CentOS/RHEL:
 ```bash
-$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg 
-``` 
+$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
+```
 
 4. Reboot the system
 ```bash
@@ -234,7 +234,7 @@ Use the following steps to pass an Intel Graphics device in SR-IOV mode to a Kat
    $ BDF="0000:3a:00.0"
    $ cat  "/sys/bus/pci/devices/$BDF/sriov_totalvfs"
    63
-   ``` 
+   ```
 
    Create SR-IOV interfaces for the GPU:
    ```sh

rust-toolchain.toml

@@ -1,3 +1,3 @@
 [toolchain]
 # Keep in sync with versions.yaml
-channel = "1.89"
+channel = "1.91"

shellcheckrc

@@ -1,3 +1,8 @@
+# Copyright (c) 2025 NVIDIA Corporation
+#
+# SPDX-License-Identifier: Apache-2.0
+#
+
 # Allow opening any 'source'd file, even if not specified as input
 external-sources=true
 
@@ -9,7 +14,7 @@ enable=check-unassigned-uppercase
 
 # Enforces braces around variable expansions to avoid ambiguity or confusion.
 # e.g. ${filename} rather than $filename
-enable=require-variable-braces 
+enable=require-variable-braces
 
 # Requires double-bracket syntax [[ expr ]] for safer, more consistent tests.
 # NO:  if [ "$var" = "value" ]

src/agent/Cargo.lock

@@ -625,9 +625,9 @@ dependencies = [
 
 [[package]]
 name = "bytes"
-version = "1.10.1"
+version = "1.11.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "d71b6127be86fdcfddb610f7182ac57211d4b18a3e9c82eb2d17662f2227ad6a"
+checksum = "1e748733b7cbc798e1434b6ac524f0c1ff2ab456fe201501e6497c8417a4fc33"
 
 [[package]]
 name = "capctl"
@@ -743,12 +743,6 @@ version = "1.0.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "5b63caa9aa9397e2d9480a9b13673856c78d8ac123288526c37d7839f2a86990"
 
-[[package]]
-name = "common-path"
-version = "1.0.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "2382f75942f4b3be3690fe4f86365e9c853c1587d6ee58212cebf6e2a9ccd101"
-
 [[package]]
 name = "concurrent-queue"
 version = "2.5.0"
@@ -987,9 +981,9 @@ dependencies = [
 
 [[package]]
 name = "deranged"
-version = "0.4.0"
+version = "0.5.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9c9e6a11ca8224451684bc0d7d5a7adbf8f2fd6887261a1cfc3c0432f9d4068e"
+checksum = "ececcb659e7ba858fb4f10388c250a7252eb0a27373f1a72b8748afdd248e587"
 dependencies = [
  "powerfmt",
 ]
@@ -1066,27 +1060,6 @@ dependencies = [
  "crypto-common",
 ]
 
-[[package]]
-name = "dirs-next"
-version = "2.0.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "b98cf8ebf19c3d1b223e151f99a4f9f0690dca41414773390fc824184ac833e1"
-dependencies = [
- "cfg-if",
- "dirs-sys-next",
-]
-
-[[package]]
-name = "dirs-sys-next"
-version = "0.1.2"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "4ebda144c4fe02d1f7ea1a7d9641b6fc6b580adcfa024ae48797ecdeb6825b4d"
-dependencies = [
- "libc",
- "redox_users",
- "winapi",
-]
-
 [[package]]
 name = "displaydoc"
 version = "0.2.5"
@@ -1119,6 +1092,18 @@ dependencies = [
  "serde",
 ]
 
+[[package]]
+name = "enum-as-inner"
+version = "0.6.1"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "a1e6a265c649f3f5979b601d26f1d05ada116434c87741c9493cb56218f76cbc"
+dependencies = [
+ "heck 0.5.0",
+ "proc-macro2",
+ "quote",
+ "syn 2.0.101",
+]
+
 [[package]]
 name = "enumflags2"
 version = "0.7.11"
@@ -1590,7 +1575,7 @@ version = "1.3.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f4a85d31aea989eead29a3aaf9e1115a180df8282431156e533de47660892565"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "fnv",
  "itoa",
 ]
@@ -1601,7 +1586,7 @@ version = "1.0.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1efedce1fb8e6913f23e0c92de8e62cd5b772a67e7b3946df930a62566c93184"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "http",
 ]
 
@@ -1611,7 +1596,7 @@ version = "0.1.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b021d93e26becf5dc7e1b75b1bed1fd93124b374ceb73f43d4d4eafec896a64a"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures-core",
  "http",
  "http-body",
@@ -1630,7 +1615,7 @@ version = "1.6.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "cc2b571658e38e0c01b1fdca3bbbe93c00d3d71693ff2770043f8c29bc7d6f80"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures-channel",
  "futures-util",
  "http",
@@ -1649,7 +1634,7 @@ version = "0.1.11"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "497bbc33a26fdd4af9ed9c70d63f61cf56a938375fbb32df34db9b1cd6d643f2"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures-channel",
  "futures-util",
  "http",
@@ -1675,7 +1660,7 @@ dependencies = [
  "js-sys",
  "log",
  "wasm-bindgen",
- "windows-core 0.61.0",
+ "windows-core",
 ]
 
 [[package]]
@@ -2123,8 +2108,6 @@ version = "0.1.0"
 dependencies = [
  "anyhow",
  "byteorder",
- "chrono",
- "common-path",
  "fail",
  "hex",
  "kata-types",
@@ -2133,11 +2116,9 @@ dependencies = [
  "mockall",
  "nix 0.26.4",
  "oci-spec",
- "once_cell",
  "pci-ids",
  "rand",
  "runtime-spec",
- "safe-path",
  "serde",
  "serde_json",
  "slog",
@@ -2156,8 +2137,8 @@ dependencies = [
  "byte-unit",
  "flate2",
  "glob",
- "hex",
  "lazy_static",
+ "nix 0.26.4",
  "num_cpus",
  "oci-spec",
  "regex",
@@ -2168,6 +2149,7 @@ dependencies = [
  "sha2 0.10.9",
  "slog",
  "slog-scope",
+ "sysctl",
  "sysinfo",
  "thiserror 1.0.69",
  "toml",
@@ -2214,16 +2196,6 @@ version = "0.2.172"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d750af042f7ef4f724306de029d18836c26c1765a54a6a3f094cbd23a7267ffa"
 
-[[package]]
-name = "libredox"
-version = "0.1.3"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c0ff37bd590ca25063e35af745c343cb7a0271906fb7b37e4813e8f79f00268d"
-dependencies = [
- "bitflags 2.9.0",
- "libc",
-]
-
 [[package]]
 name = "libseccomp"
 version = "0.3.0"
@@ -2337,7 +2309,6 @@ name = "mem-agent"
 version = "0.2.0"
 dependencies = [
  "anyhow",
- "async-trait",
  "chrono",
  "maplit",
  "nix 0.30.1",
@@ -2488,7 +2459,7 @@ version = "0.11.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "72452e012c2f8d612410d89eea01e2d9b56205274abb35d53f60200b2ec41d60"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures",
  "log",
  "netlink-packet-core",
@@ -2514,7 +2485,7 @@ version = "0.8.7"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "16c903aa70590cb93691bf97a767c8d1d6122d2cc9070433deb3bbf36ce8bd23"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures",
  "libc",
  "log",
@@ -2678,9 +2649,9 @@ dependencies = [
 
 [[package]]
 name = "num-conv"
-version = "0.1.0"
+version = "0.2.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "51d515d32fb182ee37cda2ccdcb92950d6a3c2893aa280e540671c2cd0f3b1d9"
+checksum = "cf97ec579c3c42f953ef76dbf8d55ac91fb219dde70e49aa4a6b7d74e9919050"
 
 [[package]]
 name = "num-integer"
@@ -3183,7 +3154,7 @@ version = "0.8.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "de5e2533f59d08fcf364fd374ebda0692a70bd6d7e66ef97f306f45c6c5d8020"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "prost-derive",
 ]
 
@@ -3193,7 +3164,7 @@ version = "0.8.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "355f634b43cdd80724ee7848f95770e7e70eefa6dcf14fea676216573b8fd603"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "heck 0.3.3",
  "itertools",
  "log",
@@ -3224,7 +3195,7 @@ version = "0.8.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "603bbd6394701d13f3f25aada59c7de9d35a6a5887cfc156181234a44002771b"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "prost",
 ]
 
@@ -3372,17 +3343,6 @@ dependencies = [
  "bitflags 2.9.0",
 ]
 
-[[package]]
-name = "redox_users"
-version = "0.4.6"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "ba009ff324d1fc1b900bd1fdb31564febe58a8ccc8a6fdbb93b543d33b13ca43"
-dependencies = [
- "getrandom 0.2.16",
- "libredox",
- "thiserror 1.0.69",
-]
-
 [[package]]
 name = "ref-cast"
 version = "1.0.24"
@@ -3498,7 +3458,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d19c46a6fdd48bc4dab94b6103fccc55d34c67cc0ad04653aad4ea2a07cd7bbb"
 dependencies = [
  "base64 0.22.1",
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures-channel",
  "futures-core",
  "futures-util",
@@ -3530,13 +3490,13 @@ dependencies = [
 
 [[package]]
 name = "rkyv"
-version = "0.7.45"
+version = "0.7.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9008cd6385b9e161d8229e1f6549dd23c3d022f132a2ea37ac3a10ac4935779b"
+checksum = "2297bf9c81a3f0dc96bc9521370b88f054168c29826a75e89c55ff196e7ed6a1"
 dependencies = [
  "bitvec",
  "bytecheck",
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "hashbrown 0.12.3",
  "ptr_meta",
  "rend",
@@ -3548,9 +3508,9 @@ dependencies = [
 
 [[package]]
 name = "rkyv_derive"
-version = "0.7.45"
+version = "0.7.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "503d1d27590a2b0a3a4ca4c94755aa2875657196ecbf401a42eff41d7de532c0"
+checksum = "84d7b42d4b8d06048d3ac8db0eb31bcb942cbeb709f0b5f2b2ebde398d3038f5"
 dependencies = [
  "proc-macro2",
  "quote",
@@ -3617,7 +3577,6 @@ dependencies = [
 name = "runtime-spec"
 version = "0.1.0"
 dependencies = [
- "libc",
  "serde",
  "serde_derive",
  "serde_json",
@@ -3631,7 +3590,7 @@ checksum = "faa7de2ba56ac291bd90c6b9bece784a52ae1411f9506544b3eae36dd2356d50"
 dependencies = [
  "arrayvec",
  "borsh",
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "num-traits",
  "rand",
  "rkyv",
@@ -3827,10 +3786,11 @@ checksum = "56e6fa9c48d24d85fb3de5ad847117517440f6beceb7798af16b4a87d616b8d0"
 
 [[package]]
 name = "serde"
-version = "1.0.219"
+version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "5f0e2c6ed6606019b4e29e69dbaba95b11854410e5347d525002456dbbb786b6"
+checksum = "9a8e94ea7f378bd32cbbd37198a4a91436180c5bb472411e48b5ec2e2124ae9e"
 dependencies = [
+ "serde_core",
  "serde_derive",
 ]
 
@@ -3865,10 +3825,19 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "794e44574226fc701e3be5c651feb7939038fc67fb73f6f4dd5c4ba90fd3be70"
 
 [[package]]
-name = "serde_derive"
-version = "1.0.219"
+name = "serde_core"
+version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "5b0276cf7f2c73365f7157c8123c21cd9a50fbbd844757af28ca1f5925fc2a00"
+checksum = "41d385c7d4ca58e59fc732af25c3983b67ac852c1a25000afe1175de458b67ad"
+dependencies = [
+ "serde_derive",
+]
+
+[[package]]
+name = "serde_derive"
+version = "1.0.228"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "d540f220d3187173da220f885ab66608367b6574e925011a9353e4badda91d79"
 dependencies = [
  "proc-macro2",
  "quote",
@@ -4095,10 +4064,11 @@ dependencies = [
 
 [[package]]
 name = "slog-term"
-version = "2.9.1"
+version = "2.9.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "b6e022d0b998abfe5c3782c1f03551a596269450ccd677ea51c56f8b214610e8"
+checksum = "5cb1fc680b38eed6fad4c02b3871c09d2c81db8c96aa4e9c0a34904c830f09b5"
 dependencies = [
+ "chrono",
  "is-terminal",
  "slog",
  "term",
@@ -4246,6 +4216,20 @@ dependencies = [
  "syn 2.0.101",
 ]
 
+[[package]]
+name = "sysctl"
+version = "0.7.1"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "cca424247104946a59dacd27eaad296223b7feec3d168a6dd04585183091eb0b"
+dependencies = [
+ "bitflags 2.9.0",
+ "byteorder",
+ "enum-as-inner",
+ "libc",
+ "thiserror 2.0.12",
+ "walkdir",
+]
+
 [[package]]
 name = "sysinfo"
 version = "0.34.2"
@@ -4286,13 +4270,11 @@ dependencies = [
 
 [[package]]
 name = "term"
-version = "0.7.0"
+version = "1.2.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c59df8ac95d96ff9bede18eb7300b0fda5e5d8d90960e76f8e14ae765eedbf1f"
+checksum = "d8c27177b12a6399ffc08b98f76f7c9a1f4fe9fc967c784c5a071fa8d93cf7e1"
 dependencies = [
- "dirs-next",
- "rustversion",
- "winapi",
+ "windows-sys 0.60.2",
 ]
 
 [[package]]
@@ -4361,30 +4343,30 @@ dependencies = [
 
 [[package]]
 name = "time"
-version = "0.3.41"
+version = "0.3.47"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "8a7619e19bc266e0f9c5e6686659d394bc57973859340060a69221e57dbc0c40"
+checksum = "743bd48c283afc0388f9b8827b976905fb217ad9e647fae3a379a9283c4def2c"
 dependencies = [
  "deranged",
  "itoa",
  "num-conv",
  "powerfmt",
- "serde",
+ "serde_core",
  "time-core",
  "time-macros",
 ]
 
 [[package]]
 name = "time-core"
-version = "0.1.4"
+version = "0.1.8"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c9e9a38711f559d9e3ce1cdb06dd7c5b8ea546bc90052da6d06bb76da74bb07c"
+checksum = "7694e1cfe791f8d31026952abf09c69ca6f6fa4e1a1229e18988f06a04a12dca"
 
 [[package]]
 name = "time-macros"
-version = "0.2.22"
+version = "0.2.27"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "3526739392ec93fd8b359c8e98514cb3e8e021beb4e5f597b00a0221f8ed8a49"
+checksum = "2e70e4c5a0e0a8a4823ad65dfe1a6930e4f4d756dcd9dd7939022b5e8c501215"
 dependencies = [
  "num-conv",
  "time-core",
@@ -4422,7 +4404,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0cc3a2344dafbe23a245241fe8b09735b521110d30fcefbbd5feb1797ca35d17"
 dependencies = [
  "backtrace",
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "io-uring",
  "libc",
  "mio",
@@ -4476,7 +4458,7 @@ version = "0.4.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "52a15c15b1bc91f90902347eff163b5b682643aff0c8e972912cca79bd9208dd"
 dependencies = [
- "bytes 1.10.1",
+ "bytes 1.11.1",
  "futures",
  "libc",
  "tokio",
@@ -5021,7 +5003,7 @@ version = "0.57.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "12342cb4d8e3b046f3d80effd474a7a02447231330ef77d71daa6fbc40681143"
 dependencies = [
- "windows-core 0.57.0",
+ "windows-core",
  "windows-targets 0.52.6",
 ]
 
@@ -5031,25 +5013,12 @@ version = "0.57.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d2ed2439a290666cd67ecce2b0ffaad89c2a56b976b736e6ece670297897832d"
 dependencies = [
- "windows-implement 0.57.0",
- "windows-interface 0.57.0",
+ "windows-implement",
+ "windows-interface",
  "windows-result 0.1.2",
  "windows-targets 0.52.6",
 ]
 
-[[package]]
-name = "windows-core"
-version = "0.61.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "4763c1de310c86d75a878046489e2e5ba02c649d185f21c67d4cf8a56d098980"
-dependencies = [
- "windows-implement 0.60.0",
- "windows-interface 0.59.1",
- "windows-link",
- "windows-result 0.3.2",
- "windows-strings 0.4.0",
-]
-
 [[package]]
 name = "windows-implement"
 version = "0.57.0"
@@ -5061,17 +5030,6 @@ dependencies = [
  "syn 2.0.101",
 ]
 
-[[package]]
-name = "windows-implement"
-version = "0.60.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a47fddd13af08290e67f4acabf4b459f647552718f683a7b415d290ac744a836"
-dependencies = [
- "proc-macro2",
- "quote",
- "syn 2.0.101",
-]
-
 [[package]]
 name = "windows-interface"
 version = "0.57.0"
@@ -5083,17 +5041,6 @@ dependencies = [
  "syn 2.0.101",
 ]
 
-[[package]]
-name = "windows-interface"
-version = "0.59.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "bd9211b69f8dcdfa817bfd14bf1c97c9188afa36f4750130fcdf3f400eca9fa8"
-dependencies = [
- "proc-macro2",
- "quote",
- "syn 2.0.101",
-]
-
 [[package]]
 name = "windows-link"
 version = "0.1.1"
@@ -5107,7 +5054,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4286ad90ddb45071efd1a66dfa43eb02dd0dfbae1545ad6cc3c51cf34d7e8ba3"
 dependencies = [
  "windows-result 0.3.2",
- "windows-strings 0.3.1",
+ "windows-strings",
  "windows-targets 0.53.2",
 ]
 
@@ -5138,15 +5085,6 @@ dependencies = [
  "windows-link",
 ]
 
-[[package]]
-name = "windows-strings"
-version = "0.4.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7a2ba9642430ee452d5a7aa78d72907ebe8cfda358e8cb7918a2050581322f97"
-dependencies = [
- "windows-link",
-]
-
 [[package]]
 name = "windows-sys"
 version = "0.48.0"

src/agent/Cargo.toml

@@ -5,7 +5,7 @@ members = ["rustjail", "policy", "vsock-exporter"]
 authors = ["The Kata Containers community <kata-dev@lists.katacontainers.io>"]
 edition = "2018"
 license = "Apache-2.0"
-rust-version = "1.85.1"
+rust-version = "1.88.0"
 
 [workspace.dependencies]
 oci-spec = { version = "0.8.1", features = ["runtime"] }

src/agent/rustjail/src/mount.rs

@@ -857,7 +857,7 @@ fn mount_from(
         dest.as_str(),
         Some(mount_typ.as_str()),
         flags,
-        Some(d.as_str()),
+        Some(d.as_str()).filter(|s| !s.is_empty()),
     )
     .inspect_err(|e| log_child!(cfd_log, "mount error: {:?}", e))?;
 

src/agent/src/device/block_device_handler.rs

@@ -11,11 +11,15 @@ use crate::device::{
 };
 #[cfg(target_arch = "s390x")]
 use crate::linux_abi::CCW_ROOT_BUS_PATH;
-use crate::linux_abi::{create_pci_root_bus_path, SYSFS_DIR, SYSTEM_DEV_PATH};
+use crate::linux_abi::{
+    create_pci_root_bus_path, pcipath_from_dev_tree_path, SYSFS_DIR, SYSTEM_DEV_PATH,
+};
 use crate::pci;
 use crate::sandbox::Sandbox;
 use crate::uevent::{wait_for_uevent, Uevent, UeventMatcher};
 use anyhow::{anyhow, Context, Result};
+#[cfg(target_arch = "s390x")]
+use std::str::FromStr;
 
 #[cfg(target_arch = "s390x")]
 use kata_types::device::DRIVER_BLK_CCW_TYPE;
@@ -23,7 +27,6 @@ use kata_types::device::{DRIVER_BLK_MMIO_TYPE, DRIVER_BLK_PCI_TYPE};
 use protocols::agent::Device;
 use regex::Regex;
 use std::path::Path;
-use std::str::FromStr;
 use std::sync::Arc;
 use tokio::sync::Mutex;
 use tracing::instrument;
@@ -47,8 +50,8 @@ impl DeviceHandler for VirtioBlkPciDeviceHandler {
 
     #[instrument]
     async fn device_handler(&self, device: &Device, ctx: &mut DeviceContext) -> Result<SpecUpdate> {
-        let pcipath = pci::Path::from_str(&device.id)?;
-        let vm_path = get_virtio_blk_pci_device_name(ctx.sandbox, &pcipath).await?;
+        let (root_complex, pcipath) = pcipath_from_dev_tree_path(&device.id)?;
+        let vm_path = get_virtio_blk_pci_device_name(ctx.sandbox, root_complex, &pcipath).await?;
 
         Ok(DeviceInfo::new(&vm_path, true)
             .context("New device info")?
@@ -112,11 +115,12 @@ impl DeviceHandler for VirtioBlkMmioDeviceHandler {
 #[instrument]
 pub async fn get_virtio_blk_pci_device_name(
     sandbox: &Arc<Mutex<Sandbox>>,
+    root_complex: &str,
     pcipath: &pci::Path,
 ) -> Result<String> {
-    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path());
+    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path(root_complex));
     let sysfs_rel_path = pcipath_to_sysfs(&root_bus_sysfs, pcipath)?;
-    let matcher = VirtioBlkPciMatcher::new(&sysfs_rel_path);
+    let matcher = VirtioBlkPciMatcher::new(&sysfs_rel_path, root_complex);
 
     let uev = wait_for_uevent(sandbox, matcher).await?;
     Ok(format!("{}/{}", SYSTEM_DEV_PATH, &uev.devname))
@@ -167,8 +171,8 @@ pub struct VirtioBlkPciMatcher {
 }
 
 impl VirtioBlkPciMatcher {
-    pub fn new(relpath: &str) -> VirtioBlkPciMatcher {
-        let root_bus = create_pci_root_bus_path();
+    pub fn new(relpath: &str, root_complex: &str) -> VirtioBlkPciMatcher {
+        let root_bus = create_pci_root_bus_path(root_complex);
         let re = format!(r"^{root_bus}{relpath}/virtio[0-9]+/block/");
 
         VirtioBlkPciMatcher {
@@ -229,11 +233,13 @@ impl UeventMatcher for VirtioBlkCCWMatcher {
 #[cfg(test)]
 mod tests {
     use super::*;
+    #[cfg(target_arch = "s390x")]
+    use std::str::FromStr;
 
     #[tokio::test]
     #[allow(clippy::redundant_clone)]
     async fn test_virtio_blk_matcher() {
-        let root_bus = create_pci_root_bus_path();
+        let root_bus = create_pci_root_bus_path("00");
         let devname = "vda";
 
         let mut uev_a = crate::uevent::Uevent::default();
@@ -242,12 +248,12 @@ mod tests {
         uev_a.subsystem = BLOCK.to_string();
         uev_a.devname = devname.to_string();
         uev_a.devpath = format!("{root_bus}{relpath_a}/virtio4/block/{devname}");
-        let matcher_a = VirtioBlkPciMatcher::new(relpath_a);
+        let matcher_a = VirtioBlkPciMatcher::new(relpath_a, "00");
 
         let mut uev_b = uev_a.clone();
         let relpath_b = "/0000:00:0a.0/0000:00:0b.0";
         uev_b.devpath = format!("{root_bus}{relpath_b}/virtio0/block/{devname}");
-        let matcher_b = VirtioBlkPciMatcher::new(relpath_b);
+        let matcher_b = VirtioBlkPciMatcher::new(relpath_b, "00");
 
         assert!(matcher_a.is_match(&uev_a));
         assert!(matcher_b.is_match(&uev_b));

src/agent/src/device/mod.rs

@@ -1155,9 +1155,11 @@ mod tests {
     // test
     async fn example_get_device_name(
         sandbox: &Arc<Mutex<Sandbox>>,
+        root_complex: &str,
         relpath: &str,
     ) -> Result<String> {
-        let matcher = crate::device::block_device_handler::VirtioBlkPciMatcher::new(relpath);
+        let matcher =
+            crate::device::block_device_handler::VirtioBlkPciMatcher::new(relpath, root_complex);
 
         let uev = wait_for_uevent(sandbox, matcher).await?;
 
@@ -1167,7 +1169,8 @@ mod tests {
     #[tokio::test]
     async fn test_get_device_name() {
         let devname = "vda";
-        let root_bus = create_pci_root_bus_path();
+        let root_complex = "00";
+        let root_bus = create_pci_root_bus_path(root_complex);
         let relpath = "/0000:00:0a.0/0000:03:0b.0";
         let devpath = format!("{root_bus}{relpath}/virtio4/block/{devname}");
 
@@ -1184,7 +1187,7 @@ mod tests {
         sb.uevent_map.insert(devpath.clone(), uev);
         drop(sb); // unlock
 
-        let name = example_get_device_name(&sandbox, relpath).await;
+        let name = example_get_device_name(&sandbox, root_complex, relpath).await;
         assert!(name.is_ok(), "{}", name.unwrap_err());
         assert_eq!(name.unwrap(), devname);
 
@@ -1194,7 +1197,7 @@ mod tests {
 
         spawn_test_watcher(sandbox.clone(), uev);
 
-        let name = example_get_device_name(&sandbox, relpath).await;
+        let name = example_get_device_name(&sandbox, root_complex, relpath).await;
         assert!(name.is_ok(), "{}", name.unwrap_err());
         assert_eq!(name.unwrap(), devname);
     }

src/agent/src/device/network_device_handler.rs

@@ -38,11 +38,12 @@ fn check_existing(re: Regex) -> Result<bool> {
 #[cfg(not(target_arch = "s390x"))]
 pub async fn wait_for_pci_net_interface(
     sandbox: &Arc<Mutex<Sandbox>>,
+    root_complex: &str,
     pcipath: &pci::Path,
 ) -> Result<()> {
-    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path());
+    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path(root_complex));
     let sysfs_rel_path = pcipath_to_sysfs(&root_bus_sysfs, pcipath)?;
-    let matcher = NetPciMatcher::new(&sysfs_rel_path);
+    let matcher = NetPciMatcher::new(&sysfs_rel_path, root_complex);
     let pattern = format!(
         r"[./]+{}/[a-z0-9/]*net/[a-z0-9/]*",
         matcher.devpath.as_str()
@@ -65,8 +66,8 @@ pub struct NetPciMatcher {
 
 #[cfg(not(target_arch = "s390x"))]
 impl NetPciMatcher {
-    pub fn new(relpath: &str) -> NetPciMatcher {
-        let root_bus = create_pci_root_bus_path();
+    pub fn new(relpath: &str, root_complex: &str) -> NetPciMatcher {
+        let root_bus = create_pci_root_bus_path(root_complex);
 
         NetPciMatcher {
             devpath: format!("{root_bus}{relpath}"),
@@ -131,7 +132,7 @@ mod tests {
     #[tokio::test]
     #[allow(clippy::redundant_clone)]
     async fn test_net_pci_matcher() {
-        let root_bus = create_pci_root_bus_path();
+        let root_bus = create_pci_root_bus_path("00");
         let relpath_a = "/0000:00:02.0/0000:01:01.0";
 
         let mut uev_a = crate::uevent::Uevent::default();
@@ -139,13 +140,13 @@ mod tests {
         uev_a.devpath = format!("{root_bus}{relpath_a}");
         uev_a.subsystem = String::from("net");
         uev_a.interface = String::from("eth0");
-        let matcher_a = NetPciMatcher::new(relpath_a);
+        let matcher_a = NetPciMatcher::new(relpath_a, "00");
         println!("Matcher a : {}", matcher_a.devpath);
 
         let relpath_b = "/0000:00:02.0/0000:01:02.0";
         let mut uev_b = uev_a.clone();
         uev_b.devpath = format!("{root_bus}{relpath_b}");
-        let matcher_b = NetPciMatcher::new(relpath_b);
+        let matcher_b = NetPciMatcher::new(relpath_b, "00");
 
         assert!(matcher_a.is_match(&uev_a));
         assert!(matcher_b.is_match(&uev_b));
@@ -156,7 +157,7 @@ mod tests {
         let net_substr = "/net/eth0";
         let mut uev_c = uev_a.clone();
         uev_c.devpath = format!("{root_bus}{relpath_c}{net_substr}");
-        let matcher_c = NetPciMatcher::new(relpath_c);
+        let matcher_c = NetPciMatcher::new(relpath_c, "00");
 
         assert!(matcher_c.is_match(&uev_c));
         assert!(!matcher_a.is_match(&uev_c));

src/agent/src/device/scsi_device_handler.rs

@@ -110,7 +110,7 @@ mod tests {
     #[tokio::test]
     #[allow(clippy::redundant_clone)]
     async fn test_scsi_block_matcher() {
-        let root_bus = create_pci_root_bus_path();
+        let root_bus = create_pci_root_bus_path("00");
         let devname = "sda";
 
         let mut uev_a = crate::uevent::Uevent::default();

src/agent/src/device/vfio_device_handler.rs

@@ -66,9 +66,10 @@ impl DeviceHandler for VfioPciDeviceHandler {
                 .ok_or_else(|| anyhow!("Malformed VFIO PCI option {:?}", opt))?;
             let host =
                 pci::Address::from_str(host).context("Bad host PCI address in VFIO option {:?}")?;
-            let pcipath = pci::Path::from_str(pcipath)?;
 
-            let guestdev = wait_for_pci_device(ctx.sandbox, &pcipath).await?;
+            let (root_complex, pcipath) = pcipath_from_dev_tree_path(pcipath)?;
+
+            let guestdev = wait_for_pci_device(ctx.sandbox, root_complex, &pcipath).await?;
             if vfio_in_guest {
                 pci_driver_override(ctx.logger, SYSFS_BUS_PCI_PATH, guestdev, "vfio-pci")?;
 
@@ -212,8 +213,8 @@ pub struct PciMatcher {
 }
 
 impl PciMatcher {
-    pub fn new(relpath: &str) -> Result<PciMatcher> {
-        let root_bus = create_pci_root_bus_path();
+    pub fn new(relpath: &str, root_complex: &str) -> Result<PciMatcher> {
+        let root_bus = create_pci_root_bus_path(root_complex);
         Ok(PciMatcher {
             devpath: format!("{root_bus}{relpath}"),
         })
@@ -302,11 +303,12 @@ async fn associate_ap_device(apqn: &Apqn, mkvp: &str) -> Result<()> {
 
 pub async fn wait_for_pci_device(
     sandbox: &Arc<Mutex<Sandbox>>,
+    root_complex: &str,
     pcipath: &pci::Path,
 ) -> Result<pci::Address> {
-    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path());
+    let root_bus_sysfs = format!("{}{}", SYSFS_DIR, create_pci_root_bus_path(root_complex));
     let sysfs_rel_path = pcipath_to_sysfs(&root_bus_sysfs, pcipath)?;
-    let matcher = PciMatcher::new(&sysfs_rel_path)?;
+    let matcher = PciMatcher::new(&sysfs_rel_path, root_complex)?;
 
     let uev = wait_for_uevent(sandbox, matcher).await?;
 

src/agent/src/linux_abi.rs

@@ -3,8 +3,10 @@
 // SPDX-License-Identifier: Apache-2.0
 //
 
+use crate::pci;
+use anyhow::{Context, Result};
 use cfg_if::cfg_if;
-
+use std::str::FromStr;
 // Linux ABI related constants.
 
 #[cfg(target_arch = "aarch64")]
@@ -18,19 +20,32 @@ pub const SYSFS_DIR: &str = "/sys";
     target_arch = "x86_64",
     target_arch = "x86"
 ))]
-pub fn create_pci_root_bus_path() -> String {
-    String::from("/devices/pci0000:00")
+// With NUMA, we need to make sure we use the correct root complex which is
+// defined by the pxb-pcie driver.
+pub fn create_pci_root_bus_path(root_complex: &str) -> String {
+    format!("/devices/pci0000:{root_complex}")
+}
+
+// This is used in several modules, let's create a helper function to parse the
+// qom path and switch easily once the shim sends us the full NUMA path
+pub fn pcipath_from_dev_tree_path(dev_tree_path: &str) -> Result<(&str, pci::Path)> {
+    // Placeholder until the shim send us the full NUMA path
+    // via shim in the form of root_complex/bus/device  10/00/02
+    // Currently the shim only sends us the bus/device 00/02
+    let pci_path = pci::Path::from_str(dev_tree_path)
+        .with_context(|| format!("Failed to parse PCI path from QOM path '{}'", dev_tree_path))?;
+    Ok(("00", pci_path))
 }
 
 #[cfg(target_arch = "aarch64")]
-pub fn create_pci_root_bus_path() -> String {
-    let ret = String::from("/devices/platform/4010000000.pcie/pci0000:00");
+pub fn create_pci_root_bus_path(root_complex: &str) -> String {
+    let ret = format!("/devices/platform/4010000000.pcie/pci0000:{root_complex}");
 
-    let acpi_root_bus_path = String::from("/devices/pci0000:00");
+    let acpi_root_bus_path = format!("/devices/pci0000:{root_complex}");
     let mut acpi_sysfs_dir = String::from(SYSFS_DIR);
     let mut sysfs_dir = String::from(SYSFS_DIR);
     let mut start_root_bus_path = String::from("/devices/platform/");
-    let end_root_bus_path = String::from("/pci0000:00");
+    let end_root_bus_path = format!("/pci0000:{root_complex}");
 
     // check if there is pci bus path for acpi
     acpi_sysfs_dir.push_str(&acpi_root_bus_path);

src/agent/src/rpc.rs

@@ -7,6 +7,7 @@ use async_trait::async_trait;
 use rustjail::{pipestream::PipeStream, process::StreamType};
 use tokio::io::{AsyncReadExt, AsyncWriteExt, ReadHalf};
 use tokio::sync::Mutex;
+use tokio::time::{timeout, Duration};
 
 use std::convert::TryFrom;
 use std::ffi::{CString, OsStr};
@@ -14,6 +15,7 @@ use std::fmt::Debug;
 use std::io;
 use std::os::unix::ffi::OsStrExt;
 use std::path::Path;
+#[cfg(target_arch = "s390x")]
 use std::str::FromStr;
 use std::sync::Arc;
 use ttrpc::{
@@ -95,7 +97,6 @@ use libc::{self, c_char, c_ushort, pid_t, winsize, TIOCSWINSZ};
 use std::fs;
 use std::os::unix::prelude::PermissionsExt;
 use std::process::{Command, Stdio};
-use std::time::Duration;
 
 use nix::unistd::{Gid, Uid};
 use std::fs::{File, OpenOptions};
@@ -700,25 +701,66 @@ impl AgentService {
 
         let reader = reader.ok_or_else(|| anyhow!("cannot get stream reader"))?;
 
-        tokio::select! {
-            // Poll the futures in the order they appear from top to bottom
-            // it is very important to avoid data loss. If there is still
-            // data in the buffer and read_stream branch will return
-            // Poll::Ready so that the term_exit_notifier will never polled
-            // before all data were read.
+        // Create one in-flight read future and reuse it in both branches.
+        let read_fut = read_stream(&reader, req.len as usize);
+        tokio::pin!(read_fut);
+
+        // Cancellation and polling model: Rust async is polled, not preempted.
+        // `Future::poll()` is a synchronous function call that runs to completion and
+        // returns Ready or Pending (`std::future::Future`).
+        // Readiness notifications (Waker::wake / Tokio Notify) only schedule the task
+        // to be polled again later; they do not interrupt an in-progress poll.
+        // Therefore, a Notify becoming ready while `poll_read()` is executing cannot cause
+        // the read future to be dropped mid-way; cancellation can only happen when the branch
+        // is still pending between polls (Tokio `select!` cancels by dropping non-selected futures).
+        // Detailed information, please refer to Tokio doc for more information:
+        // - Future::poll: https://doc.rust-lang.org/std/future/trait.Future.html
+        // - Waker: https://doc.rust-lang.org/std/task/struct.Waker.html
+        // - Tokio select!: https://docs.rs/tokio/latest/tokio/macro.select.html
+        let data = tokio::select! {
+            // Use `biased` to make the polling order deterministic (top-to-bottom).
+            // This ensures that *when multiple branches are ready at the same time*,
+            // we prefer reading pending output over reacting to the exit notification.
+            //
+            // Note: `biased` does NOT guarantee that we won't lose output. If the exit
+            // notification becomes ready while `read_stream` is still pending, the
+            // exit branch may be selected and we may stop reading before draining the
+            // remaining buffered data.
+            //
+            // Detailed information, please refer to Tokio doc for more information:
+            // https://docs.rs/tokio/latest/src/tokio/macros/select.rs.html#67
             biased;
-            v = read_stream(&reader, req.len as usize)  => {
-                let vector = v?;
 
-                let mut resp = ReadStreamResponse::new();
-                resp.set_data(vector);
-
-                Ok(resp)
-            }
+            v = &mut read_fut => v?,
             _ = term_exit_notifier.notified() => {
-                Err(anyhow!("eof"))
+                // Drain-after-exit rationale:
+                // The process has exited, but the data may still be buffered in the pipe/pty.
+                // We should keep waiting for the same in-flight read for a bounded window to drain the data.
+                //
+                // It enters this branch only if `term_exit_notifier.notified()` fires. It then try to "drain"
+                // any remaining buffered output for a short, bounded time window:
+                // - If non-empty data is read: return immediately.
+                // - else then return empty data as EOF.
+
+                const DRAIN_DEADLINE_MS: u64 = 500; // 500ms
+                let deadline = Duration::from_millis(DRAIN_DEADLINE_MS);
+
+                // Attempt to drain remaining buffered output after process exit
+                // Try reading with timeout
+                match timeout(deadline, &mut read_fut).await {
+                    Ok(v) => v?, // got data or EOF (empty)
+                    _ => {
+                        warn!(sl(), "exit-drain timeout, return EOF"; "container-id" => cid, "exec-id" => eid);
+                        Vec::new() // Return empty as EOF
+                    }
+                }
             }
-        }
+        };
+
+        let mut resp = ReadStreamResponse::new();
+        resp.set_data(data);
+
+        Ok(resp)
     }
 }
 
@@ -1019,10 +1061,11 @@ impl agent_ttrpc::AgentService for AgentService {
         if !interface.devicePath.is_empty() {
             #[cfg(not(target_arch = "s390x"))]
             {
-                let pcipath = pci::Path::from_str(&interface.devicePath).map_ttrpc_err(|e| {
-                    format!("Unexpected pci-path for network interface: {e:?}")
-                })?;
-                wait_for_pci_net_interface(&self.sandbox, &pcipath)
+                let (root_complex, pcipath) = pcipath_from_dev_tree_path(&interface.devicePath)
+                    .map_ttrpc_err(|e| {
+                        format!("Invalid PCI path for network interface: {:?}", e)
+                    })?;
+                wait_for_pci_net_interface(&self.sandbox, root_complex, &pcipath)
                     .await
                     .map_ttrpc_err(|e| format!("interface not available: {e:?}"))?;
             }
@@ -1773,10 +1816,6 @@ async fn read_stream(reader: &Mutex<ReadHalf<PipeStream>>, l: usize) -> Result<V
     let len = reader.read(&mut content).await?;
     content.resize(len, 0);
 
-    if len == 0 {
-        return Err(anyhow!("read meet eof"));
-    }
-
     Ok(content)
 }
 
@@ -2125,7 +2164,9 @@ async fn do_add_swap(sandbox: &Arc<Mutex<Sandbox>>, req: &AddSwapRequest) -> Res
         slots.push(pci::SlotFn::new(*slot, 0)?);
     }
     let pcipath = pci::Path::new(slots)?;
-    let dev_name = get_virtio_blk_pci_device_name(sandbox, &pcipath).await?;
+    // Default all virtio devices to root_complex 00 aka pcie.0
+    let root_complex = "00";
+    let dev_name = get_virtio_blk_pci_device_name(sandbox, root_complex, &pcipath).await?;
 
     let c_str = CString::new(dev_name)?;
     let ret = unsafe { libc::swapon(c_str.as_ptr() as *const c_char, 0) };

src/agent/src/storage/block_handler.rs

@@ -4,10 +4,10 @@
 // SPDX-License-Identifier: Apache-2.0
 //
 
+use crate::linux_abi::pcipath_from_dev_tree_path;
 use std::fs;
 use std::os::unix::fs::PermissionsExt;
 use std::path::Path;
-use std::str::FromStr;
 use std::sync::Arc;
 
 use anyhow::{anyhow, Context, Result};
@@ -29,8 +29,9 @@ use crate::device::block_device_handler::{
 };
 use crate::device::nvdimm_device_handler::wait_for_pmem_device;
 use crate::device::scsi_device_handler::get_scsi_device_name;
-use crate::pci;
 use crate::storage::{common_storage_handler, new_device, StorageContext, StorageHandler};
+#[cfg(target_arch = "s390x")]
+use std::str::FromStr;
 
 #[derive(Debug)]
 pub struct VirtioBlkMmioHandler {}
@@ -84,8 +85,9 @@ impl StorageHandler for VirtioBlkPciHandler {
                 return Err(anyhow!("Invalid device {}", &storage.source));
             }
         } else {
-            let pcipath = pci::Path::from_str(&storage.source)?;
-            let dev_path = get_virtio_blk_pci_device_name(ctx.sandbox, &pcipath).await?;
+            let (root_complex, pcipath) = pcipath_from_dev_tree_path(&storage.source)?;
+            let dev_path =
+                get_virtio_blk_pci_device_name(ctx.sandbox, root_complex, &pcipath).await?;
             storage.source = dev_path;
         }
 

src/dragonball/Cargo.toml

@@ -48,7 +48,6 @@ vmm-sys-util = { workspace = true }
 virtio-queue = { workspace = true, optional = true }
 vm-memory = { workspace = true, features = ["backend-mmap"] }
 crossbeam-channel = "0.5.6"
-fuse-backend-rs = "0.10.5"
 vfio-bindings = { workspace = true, optional = true }
 vfio-ioctls = { workspace = true, optional = true }
 
@@ -86,3 +85,6 @@ host-device = ["dep:vfio-bindings", "dep:vfio-ioctls", "dep:dbs-pci"]
 unexpected_cfgs = { level = "warn", check-cfg = [
   'cfg(feature, values("test-mock"))',
 ] }
+
+[package.metadata.cargo-machete]
+ignored = ["vfio-bindings"]

src/dragonball/README.md

@@ -40,7 +40,7 @@ You could see the [official documentation](docs/) page for more details.
 # Supported Architectures
 - x86-64
 - aarch64
- 
+
 # Supported Kernel
 [TODO](https://github.com/kata-containers/kata-containers/issues/4303)
 
@@ -51,4 +51,4 @@ Part of the code is based on the [Cloud Hypervisor](https://github.com/cloud-hyp
 
 # License
 
-`Dragonball` is licensed under [Apache License](http://www.apache.org/licenses/LICENSE-2.0), Version 2.0.
+`Dragonball` is licensed under [Apache License](http://www.apache.org/licenses/LICENSE-2.0), Version 2.0.

src/dragonball/THIRD-PARTY

@@ -24,4 +24,4 @@
 // DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 // THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

src/dragonball/dbs_acpi/Cargo.toml

@@ -11,4 +11,4 @@ keywords = ["dragonball", "acpi", "vmm", "secure-sandbox"]
 readme = "README.md"
 
 [dependencies]
-vm-memory = {workspace = true}
+vm-memory = {workspace = true}

src/dragonball/dbs_allocator/README.md

@@ -7,7 +7,7 @@ sandbox (virtual machine), such as memory-mapped I/O address space, port I/O add
 MSI/MSI-X vectors, device instance id, etc. The `dbs-allocator` crate is designed to help the resource manager
 to track and allocate these types of resources.
 
-Main components are:   
+Main components are:
 - *Constraints*: struct to declare constraints for resource allocation.
 ```rust
 #[derive(Copy, Clone, Debug)]
@@ -34,20 +34,20 @@ pub fn allocate(&mut self, constraint: &Constraint) -> Option<Range>
 pub fn free(&mut self, key: &Range) -> Option<T>
 pub fn insert(&mut self, key: Range, data: Option<T>) -> Self
 pub fn update(&mut self, key: &Range, data: T) -> Option<T>
-pub fn delete(&mut self, key: &Range) -> Option<T> 
+pub fn delete(&mut self, key: &Range) -> Option<T>
 pub fn get(&self, key: &Range) -> Option<NodeState<&T>>
 ```
 
 ## Usage
-The concept of Interval Tree may seem complicated, but using dbs-allocator to do resource allocation and release is simple and straightforward. 
+The concept of Interval Tree may seem complicated, but using dbs-allocator to do resource allocation and release is simple and straightforward.
 You can following these steps to allocate your VMM resource.
 ```rust
 // 1. To start with, we should create an interval tree for some specific resouces and give maximum address/id range as root node. The range here could be address range, id range, etc.
 ​
-let mut resources_pool = IntervalTree::new(); 
-resources_pool.insert(Range::new(MIN_RANGE, MAX_RANGE), None); 
+let mut resources_pool = IntervalTree::new();
+resources_pool.insert(Range::new(MIN_RANGE, MAX_RANGE), None);
 ​
-// 2. Next, create a constraint with the size for your resource, you could also assign the maximum, minimum and alignment for the constraint. Then we could use the constraint to allocate the resource in the range we previously decided. Interval Tree will give you the appropriate range. 
+// 2. Next, create a constraint with the size for your resource, you could also assign the maximum, minimum and alignment for the constraint. Then we could use the constraint to allocate the resource in the range we previously decided. Interval Tree will give you the appropriate range.
 let mut constraint = Constraint::new(SIZE);
 let mut resources_range = self.resources_pool.allocate(&constraint);
 ​
@@ -64,13 +64,13 @@ use dbs_allocator::{Constraint, IntervalTree, Range};
 let mut pci_device_pool = IntervalTree::new();
 ​
 // Init PCI device id pool with the range 0 to 255
-pci_device_pool.insert(Range::new(0x0u8, 0xffu8), None); 
+pci_device_pool.insert(Range::new(0x0u8, 0xffu8), None);
 ​
-// Construct a constraint with size 1 and alignment 1 to ask for an ID. 
-let mut constraint = Constraint::new(1u64).align(1u64); 
+// Construct a constraint with size 1 and alignment 1 to ask for an ID.
+let mut constraint = Constraint::new(1u64).align(1u64);
 ​
 // Get an ID from the pci_device_pool
-let mut id = pci_device_pool.allocate(&constraint).map(|e| e.min as u8); 
+let mut id = pci_device_pool.allocate(&constraint).map(|e| e.min as u8);
 ​
 // Pass the ID generated from dbs-allocator to vm-pci specified functions to create pci devices
 let mut pci_device = PciDevice::new(id as u8, ..);
@@ -84,15 +84,15 @@ use dbs_allocator::{Constraint, IntervalTree, Range};
 let mut mem_pool = IntervalTree::new();
 ​
 // Init memory address from GUEST_MEM_START to GUEST_MEM_END
-mem_pool.insert(Range::new(GUEST_MEM_START, GUEST_MEM_END), None); 
+mem_pool.insert(Range::new(GUEST_MEM_START, GUEST_MEM_END), None);
 ​
-// Construct a constraint with size, maximum addr and minimum address of memory region to ask for an memory allocation range. 
+// Construct a constraint with size, maximum addr and minimum address of memory region to ask for an memory allocation range.
 let constraint = Constraint::new(region.len())
                 .min(region.start_addr().raw_value())
                 .max(region.last_addr().raw_value());
 ​
 // Get the memory allocation range from the pci_device_pool
-let mem_range = mem_pool.allocate(&constraint).unwrap(); 
+let mem_range = mem_pool.allocate(&constraint).unwrap();
 ​
 // Update the mem_range in IntervalTree with memory region info
 mem_pool.update(&mem_range, region);
@@ -103,4 +103,4 @@ mem_pool.update(&mem_range, region);
 
 ## License
 
-This project is licensed under [Apache License](http://www.apache.org/licenses/LICENSE-2.0), Version 2.0.
+This project is licensed under [Apache License](http://www.apache.org/licenses/LICENSE-2.0), Version 2.0.

src/dragonball/dbs_arch/docs/x86_64_cpuid.md

@@ -2,7 +2,7 @@
 
 ## Design
 
-CPUID is designed as the CPUID filter for Intel and AMD CPU Identification. Through CPUID configuration, we could set CPU topology, Cache topology, PMU status and other features for the VMs. 
+CPUID is designed as the CPUID filter for Intel and AMD CPU Identification. Through CPUID configuration, we could set CPU topology, Cache topology, PMU status and other features for the VMs.
 
 CPUID is developed based on the Firecracker CPUID code while we add other extensions such as CPU Topology and VPMU features.
 
@@ -34,7 +34,7 @@ pub struct VmSpec {
 ```
 
 ## Example
-We will show examples for filtering CPUID. 
+We will show examples for filtering CPUID.
 First, you need to use KVM_GET_CPUID2 ioctl to get the original CPUID, this part is not included in the db-cpuid.
 
 ```rust

src/dragonball/dbs_device/README.md

@@ -15,8 +15,7 @@ The dbs-device crate provides:
 
 The dbs-device crate is designed to support the virtual machine's device model.
 
-The core concepts of device model are [Port I/O](https://wiki.osdev.org/I/O_Ports) and 
-[Memory-mapped I/O](https://en.wikipedia.org/wiki/Memory-mapped_I/O),
+The core concepts of device model are [Memory-mapped I/O and port-mapped I/O](https://en.wikipedia.org/wiki/Memory-mapped_I/O_and_port-mapped_I/O),
 which are two main methods of performing I/O between CPU and devices.
 
 The device model provided by the dbs-device crate works as below:
@@ -51,7 +50,7 @@ The difference of [`DeviceIo`] and [`DeviceIoMut`] is the reference type of `sel
   interior mutability and thread-safe protection itself
 - [`DeviceIoMut`] trait would pass a mutable reference `&mut self` to method, and it can give mutability to device
   which is wrapped by `Mutex` directly to simplify the difficulty of achieving interior mutability.
-  
+
 Additionally, the [`DeviceIo`] trait has an auto implement for `Mutex<T: DeviceIoMut>`
 
 Last, the device needs to be added to [`IoManager`] by using `register_device_io()`, and the function would add device

src/dragonball/dbs_legacy_devices/README.md

@@ -4,7 +4,7 @@
 
 ## Serial Devices
 
-Defined a wrapper over the Serial of [`vm-superio`](https://github.com/rust-vmm/vm-superio). 
+Defined a wrapper over the Serial of [`vm-superio`](https://github.com/rust-vmm/vm-superio).
 This wrapper is needed because [Orphan rules](https://doc.rust-lang.org/reference/items/implementations.html#orphan-rules),
 which is one crate can not implement a trait for a struct defined in
 another crate. This wrapper also contains the input field that is
@@ -12,7 +12,7 @@ missing from upstream implementation.
 
 ## i8042 Devices
 
-Defined a wrapper over the `i8042 PS/2 Controller` of [`vm-superio`](https://github.com/rust-vmm/vm-superio). 
+Defined a wrapper over the `i8042 PS/2 Controller` of [`vm-superio`](https://github.com/rust-vmm/vm-superio).
 The i8042 PS/2 controller emulates, at this point, only the CPU reset command which is needed for announcing the VMM about the guest's shutdown.
 
 ### Acknowledgement

src/dragonball/dbs_pci/Cargo.toml

@@ -23,24 +23,22 @@ dbs-interrupt = { workspace = true, features = [
     "kvm-legacy-irq",
     "kvm-msi-irq",
 ] }
-downcast-rs = "1.2.0"
 byteorder = "1.4.3"
 serde = "1.0.27"
 
-vm-memory = {workspace = true}
-kvm-ioctls = {workspace = true}
-kvm-bindings = {workspace = true}
-vfio-ioctls = {workspace = true}
-vfio-bindings = {workspace = true}
+vm-memory = { workspace = true }
+kvm-ioctls = { workspace = true }
+kvm-bindings = { workspace = true }
+vfio-ioctls = { workspace = true }
+vfio-bindings = { workspace = true }
 libc = "0.2.39"
-vmm-sys-util = {workspace = true}
-virtio-queue = {workspace = true}
-dbs-utils = {workspace = true}
+virtio-queue = { workspace = true }
+dbs-utils = { workspace = true }
 
 
 [dev-dependencies]
 dbs-arch = { workspace = true }
-kvm-ioctls = {workspace = true}
+kvm-ioctls = { workspace = true }
 test-utils = { workspace = true }
 nix = { workspace = true }
 

src/dragonball/dbs_pci/README.md

@@ -22,6 +22,6 @@ There are several components in `dbs-pci` crate building together to emulate PCI
 
 8. `vfio` mod: `vfio` mod collects lots of information related to the `vfio` operations.
     a. `vfio` `msi` and `msix` capability and state
-    b. `vfio` interrupt information 
+    b. `vfio` interrupt information
     c. PCI region information
-    d. `vfio` PCI device information and state
+    d. `vfio` PCI device information and state

src/dragonball/dbs_upcall/Cargo.toml

@@ -11,7 +11,6 @@ keywords = ["dragonball", "secure-sandbox", "devices", "upcall", "virtio"]
 readme = "README.md"
 
 [dependencies]
-anyhow = "1"
 log = "0.4.14"
 thiserror = "1"
 timerfd = "1.2.0"

src/dragonball/dbs_upcall/README.md

@@ -2,7 +2,7 @@
 
 `dbs-upcall` is a direct communication tool between VMM and guest developed upon VSOCK. 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 after the kernel starts. 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 machines overhead. And there could be many other usage through this direct communication channel. 
+We have accomplished device hotplug / hot-unplug directly through upcall in order to avoid virtualization of ACPI to minimize virtual machines overhead. And there could be many other usage through this direct communication channel.
 
 ## Design
 
@@ -33,7 +33,7 @@ If request is sent in step 3, upcall state will change to `ServiceBusy` and upca
 There are two parts for the upcall request message : message header and message load.
 And there are three parts for the upcall reply message: message header, result and message load.
 
-Message Header contains following information and it remains the same for the request and the reply : 
+Message Header contains following information and it remains the same for the request and the reply :
 1. magic_version(u32): magic version for identifying upcall and the service type
 2. msg_size(u32): size of the message load
 3. msg_type(u32): type for the message to identify its usage  (e.g. ADD_CPU)
@@ -49,7 +49,7 @@ msg_load type 2: `cpu_dev_info`` - for CPU hotplug / hot-unplug request:
 1. count
 2. `apic_ver`
 3. `apic_ids[256]`
-   
+
 For the upcall reply message, reply contains result and two kinds of msg_load.
 If result is 0, the operation is successful.
 If result is not 0, result refers to the error code.
@@ -66,4 +66,4 @@ Kernel patches are needed for dbs-upcall. You could go to [Upcall Kernel Patches
 
 ## License
 
-This project is licensed under [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0).
+This project is licensed under [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0).

src/dragonball/dbs_virtio_devices/Cargo.toml

@@ -24,8 +24,8 @@ dbs-boot = { workspace = true }
 epoll = ">=4.3.1, <4.3.2"
 io-uring = "0.5.2"
 fuse-backend-rs = { version = "0.10.5", optional = true }
-kvm-bindings = { workspace = true}
-kvm-ioctls = {workspace = true}
+kvm-bindings = { workspace = true }
+kvm-ioctls = { workspace = true }
 libc = "0.2.119"
 log = "0.4.14"
 nix = "0.24.3"
@@ -37,19 +37,16 @@ serde = "1.0.27"
 serde_json = "1.0.9"
 thiserror = "1"
 threadpool = "1"
-virtio-bindings = {workspace = true}
-virtio-queue = {workspace = true}
-vmm-sys-util = {workspace = true}
+virtio-bindings = { workspace = true }
+virtio-queue = { workspace = true }
+vmm-sys-util = { workspace = true }
 vm-memory = { workspace = true, features = ["backend-mmap"] }
 sendfd = "0.4.3"
 vhost-rs = { version = "0.6.1", package = "vhost", optional = true }
 timerfd = "1.0"
 
 [dev-dependencies]
-vm-memory = { workspace = true, features = [
-    "backend-mmap",
-    "backend-atomic",
-] }
+vm-memory = { workspace = true, features = ["backend-mmap", "backend-atomic"] }
 test-utils = { workspace = true }
 
 [features]

src/dragonball/dbs_virtio_devices/src/lib.rs

@@ -439,19 +439,19 @@ pub mod tests {
             VirtqDesc { desc }
         }
 
-        pub fn addr(&self) -> VolatileRef<u64> {
+        pub fn addr(&self) -> VolatileRef<'_, u64> {
             self.desc.get_ref(offset_of!(DescriptorTmp, addr)).unwrap()
         }
 
-        pub fn len(&self) -> VolatileRef<u32> {
+        pub fn len(&self) -> VolatileRef<'_, u32> {
             self.desc.get_ref(offset_of!(DescriptorTmp, len)).unwrap()
         }
 
-        pub fn flags(&self) -> VolatileRef<u16> {
+        pub fn flags(&self) -> VolatileRef<'_, u16> {
             self.desc.get_ref(offset_of!(DescriptorTmp, flags)).unwrap()
         }
 
-        pub fn next(&self) -> VolatileRef<u16> {
+        pub fn next(&self) -> VolatileRef<'_, u16> {
             self.desc.get_ref(offset_of!(DescriptorTmp, next)).unwrap()
         }
 
@@ -513,11 +513,11 @@ pub mod tests {
             self.start.unchecked_add(self.ring.len() as GuestUsize)
         }
 
-        pub fn flags(&self) -> VolatileRef<u16> {
+        pub fn flags(&self) -> VolatileRef<'_, u16> {
             self.ring.get_ref(0).unwrap()
         }
 
-        pub fn idx(&self) -> VolatileRef<u16> {
+        pub fn idx(&self) -> VolatileRef<'_, u16> {
             self.ring.get_ref(2).unwrap()
         }
 
@@ -525,12 +525,12 @@ pub mod tests {
             4 + mem::size_of::<T>() * (i as usize)
         }
 
-        pub fn ring(&self, i: u16) -> VolatileRef<T> {
+        pub fn ring(&self, i: u16) -> VolatileRef<'_, T> {
             assert!(i < self.qsize);
             self.ring.get_ref(Self::ring_offset(i)).unwrap()
         }
 
-        pub fn event(&self) -> VolatileRef<u16> {
+        pub fn event(&self) -> VolatileRef<'_, u16> {
             self.ring.get_ref(Self::ring_offset(self.qsize)).unwrap()
         }
 
@@ -602,7 +602,7 @@ pub mod tests {
             (self.dtable.len() / VirtqDesc::dtable_len(1)) as u16
         }
 
-        pub fn dtable(&self, i: u16) -> VirtqDesc {
+        pub fn dtable(&self, i: u16) -> VirtqDesc<'_> {
             VirtqDesc::new(&self.dtable, i)
         }
 

src/dragonball/dbs_virtio_devices/src/vhost/vhost_user/fs.rs

@@ -865,11 +865,11 @@ mod tests {
             0
         );
         let config: [u8; 8] = [0; 8];
-        VirtioDevice::<Arc<GuestMemoryMmap<()>>, QueueSync, GuestRegionMmap>::write_config(
+        let _ = VirtioDevice::<Arc<GuestMemoryMmap<()>>, QueueSync, GuestRegionMmap>::write_config(
             &mut dev, 0, &config,
         );
         let mut data: [u8; 8] = [1; 8];
-        VirtioDevice::<Arc<GuestMemoryMmap<()>>, QueueSync, GuestRegionMmap>::read_config(
+        let _ = VirtioDevice::<Arc<GuestMemoryMmap<()>>, QueueSync, GuestRegionMmap>::read_config(
             &mut dev, 0, &mut data,
         );
         assert_eq!(config, data);

src/dragonball/dbs_virtio_devices/src/vsock/mod.rs

@@ -339,7 +339,7 @@ mod tests {
             }
         }
 
-        pub fn create_event_handler_context(&self) -> EventHandlerContext {
+        pub fn create_event_handler_context(&self) -> EventHandlerContext<'_> {
             const QSIZE: u16 = 256;
 
             let guest_rxvq = GuestQ::new(GuestAddress(0x0010_0000), &self.mem, QSIZE);

src/dragonball/docs/device.md

@@ -3,14 +3,14 @@
 ## Device Manager
 
 Currently we have following device manager:
-| Name | Description | 
+| Name | Description |
 | --- | --- |
 | [address space manager](../src/address_space_manager.rs) | abstracts virtual machine's physical management and provide mapping for guest virtual memory and MMIO ranges of emulated virtual devices, pass-through devices and vCPU |
-| [config manager](../src/config_manager.rs) | provides abstractions for configuration information | 
-| [console manager](../src/device_manager/console_manager.rs) | provides management for all console devices | 
-| [resource manager](../src/resource_manager.rs) |provides resource management for `legacy_irq_pool`, `msi_irq_pool`, `pio_pool`, `mmio_pool`, `mem_pool`, `kvm_mem_slot_pool` with builder `ResourceManagerBuilder` | 
-| [VSOCK device manager](../src/device_manager/vsock_dev_mgr.rs) | provides configuration info for `VIRTIO-VSOCK` and management for all VSOCK devices | 
-   
+| [config manager](../src/config_manager.rs) | provides abstractions for configuration information |
+| [console manager](../src/device_manager/console_manager.rs) | provides management for all console devices |
+| [resource manager](../src/resource_manager.rs) |provides resource management for `legacy_irq_pool`, `msi_irq_pool`, `pio_pool`, `mmio_pool`, `mem_pool`, `kvm_mem_slot_pool` with builder `ResourceManagerBuilder` |
+| [VSOCK device manager](../src/device_manager/vsock_dev_mgr.rs) | provides configuration info for `VIRTIO-VSOCK` and management for all VSOCK devices |
+
 
 ## Device supported
 `VIRTIO-VSOCK`

src/dragonball/docs/upcall.md

@@ -27,4 +27,4 @@ You could use following command to download the upstream kernel (currently Drago
 
 After this command, the kernel code with `upcall` and related `.config` file are all set up in the directory `kata-linux-dragonball-experimental-5.10.25-[config version]`. You can either manually compile the kernel with `make` command or following [Document for build-kernel.sh](../../../tools/packaging/kernel/README.md) to build and use this guest kernel.
 
-Also, a client-side is also needed in VMM. Dragonball has already open-source the way to implement `upcall` client and Dragonball compiled with `dbs-upcall` feature will enable Dragonball client side.
+Also, a client-side is also needed in VMM. Dragonball has already open-source the way to implement `upcall` client and Dragonball compiled with `dbs-upcall` feature will enable Dragonball client side.

src/dragonball/docs/vcpu.md

@@ -27,11 +27,11 @@ When the vCPU is created, it'll turn to `paused` state. After vCPU resource is r
 
 During the `running` state, VMM will catch vCPU exit and execute different logic according to the exit reason.
 
-If the VMM catch some exit reasons that it cannot handle, the state will change to `waiting_exit` and VMM will stop the virtual machine. 
+If the VMM catch some exit reasons that it cannot handle, the state will change to `waiting_exit` and VMM will stop the virtual machine.
 When the state switches to `waiting_exit`, an exit event will be sent to vCPU `exit_evt`, event manager will detect the change in `exit_evt` and set VMM `exit_evt_flag` as 1. A thread serving for VMM event loop will check `exit_evt_flag` and if the flag is 1, it'll stop the VMM.
 
 When the VMM is stopped / destroyed, the state will change to `exited`.
-   
+
 ## vCPU Hot plug
 Since `Dragonball Sandbox` doesn't support virtualization of ACPI system, we use [`upcall`](https://github.com/openanolis/dragonball-sandbox/tree/main/crates/dbs-upcall) to establish a direct communication channel between `Dragonball` and Guest in order to trigger vCPU hotplug.
 

src/dragonball/src/device_manager/fs_dev_mgr.rs

@@ -389,7 +389,7 @@ impl FsDeviceMgr {
         };
 
         let vm_as = ctx.get_vm_as().map_err(|e| {
-            error!(ctx.logger(), "virtio-fs get vm_as error: {:?}", e; 
+            error!(ctx.logger(), "virtio-fs get vm_as error: {:?}", e;
                 "subsystem" => "virito-fs");
             FsDeviceError::DeviceManager(e)
         })?;

src/libs/kata-sys-util/Cargo.toml

@@ -13,13 +13,10 @@ edition = "2018"
 [dependencies]
 anyhow = "1.0.31"
 byteorder = "1.4.3"
-chrono = "0.4.0"
-common-path = "=1.0.0"
 fail = "0.5.0"
 lazy_static = "1.4.0"
 libc = "0.2.100"
 nix = "0.26.4"
-once_cell = "1.9.0"
 serde = { version = "1.0.138", features = ["derive"] }
 serde_json = "1.0.73"
 slog = "2.5.2"
@@ -34,10 +31,7 @@ mockall = "0.13.1"
 kata-types = { path = "../kata-types" }
 oci-spec = { version = "0.8.1", features = ["runtime"] }
 runtime-spec = { path = "../runtime-spec" }
-safe-path = { path = "../safe-path" }
 
 [dev-dependencies]
-num_cpus = "1.13.1"
-serial_test = "0.5.1"
 tempfile = "3.19.1"
 test-utils = { path = "../test-utils" }

src/libs/kata-sys-util/README.md

@@ -1,6 +1,6 @@
 # `kata-sys-util`
 
-This crate is a collection of utilities and helpers for 
+This crate is a collection of utilities and helpers for
 [Kata Containers](https://github.com/kata-containers/kata-containers/) components to access system services.
 
 It provides safe wrappers over system services, such as:

src/libs/kata-types/Cargo.toml

@@ -29,12 +29,14 @@ serde-enum-str = "0.4"
 sysinfo = "0.34.2"
 sha2 = "0.10.8"
 flate2 = "1.1"
-hex = "0.4"
-
+nix = "0.26.4"
 oci-spec = { version = "0.8.1", features = ["runtime"] }
 
 safe-path = { path = "../safe-path", optional = true }
 
+[target.'cfg(target_os = "macos")'.dependencies]
+sysctl = "0.7.1"
+
 [dev-dependencies]
 tempfile = "3.19.1"
 test-utils = { path = "../test-utils" }