---
title: "Tdx Host Profile Status"
method: POST
path: "/servers/tdx/host_profiles/status"
tags: ["Servers"]
---

# Tdx Host Profile Status

`POST /servers/tdx/host_profiles/status`

Is this host class known, and which VM images cover it? The check `chutes-cvm host verify` runs.

Deliberately version-free: a miner verifies a host BEFORE downloading any image, so this asks
only about the topology -- "can this host run anything at all, and if so what". Whether one
specific image can boot is POST /servers/tdx/preflight, which the launch path runs against the
version it actually holds.

  * `measurements` non-empty -> the class is attestable; those are the images it can launch.
  * empty, `status: pending`  -> registered, awaiting measurement generation. Nothing to do but
    retry later; re-submitting will not speed it up.
  * empty, `status: unknown`  -> never submitted. Register it with
    POST /servers/tdx/host_profiles.

A POST because the API owns the fingerprint: a caller cannot ask about "my topology" without
handing over the profile to be fingerprinted. Stores nothing -- the read-only counterpart to the
submission route. Signed by the miner hotkey, so the signature covers the request body.

## Headers

- `X-Chutes-Hotkey` string, nullable
- `X-Chutes-Signature` string, nullable
- `X-Chutes-Nonce` string, nullable
- `Authorization` string, nullable

## Request body

- HostProfile — The document sek8s ``discover-profile.sh`` emits for one machine -- the whole submitted body, and what gets stored. Every key the script emits is modeled and every block forbids extras, so compatibility is one-way: an older script still validates (defaults fill in), but a script that adds a key 422s until the API models it. Add the field here, deploy, then roll out the script.
  - `hostname` string, nullable
  - `timestamp` string, nullable
  - `host` HostProfilePlatform — DMI/SMBIOS identity (board, BIOS, chassis) plus OS release. Recorded, not fingerprinted -- BIOS revisions move independently of the host class.
    - `product_name` string
    - `board_vendor` string
    - `board_name` string
    - `bios_vendor` string
    - `bios_version` string
    - `bios_date` string
    - `os_version_id` string
  - `launch_determinism` HostProfileQemu, required — QEMU build and the ``-cpu`` string it launches with -- both RTMR0 determinants. Wire key is ``launch_determinism``. Its last three members restate ``numa`` and ``cpu``; they are declared so real submissions validate, but nothing reads them (``fingerprint`` takes those values from their canonical block, so a disagreeing copy cannot shift it).
    - `qemu_version` string, required
    - `qemu_version_full` string
    - `cpu_args` string
    - `numa_node_count` integer
    - `numa_topology_eligible` boolean
    - `host_cpu_topology` string
  - `gpu` HostProfileGpu, required — Passthrough GPU inventory: PCI ids and addresses, count, BAR/VRAM sizing, VBIOS.
    - `pci_device_ids` string[]
    - `bdfs` string[]
    - `count` integer, required
    - `vram_gb` number, nullable
    - `bar_size_mb` integer
    - `numa_nodes` integer[]
    - `vbios` string[]
    - `pci_class` string
    - `pci_bars` HostProfilePciBar[]
      - `index` integer, required
      - `size_mb` integer, required
      - `kind` string, required
  - `pci_topology` string, nullable
  - `cpu` HostProfileCpu, required — Host CPU topology and the identity fields RTMR0 depends on.
    - `total` integer, required
    - `sockets` integer, required
    - `cores_per_socket` integer, required
    - `threads_per_core` integer, required
    - `cpu_vendor` string
    - `cpu_processor_id` string, nullable
  - `memory` HostProfileMemory, required — Host RAM, which some profiles (e.g. B200) derive guest RAM from. The ``suggested_*`` fields are the script's own sizing advice, recorded but unused.
    - `total_gb` number, required
    - `suggested_ram_per_gpu_gb` integer
    - `suggested_total_vm_ram_gb` integer
  - `numa` HostProfileNuma, required — NUMA layout: node count, node indices, per-node cpulists.
    - `node_count` integer, required
    - `nodes` integer[]
    - `cpus_per_node` object
  - `nic` HostProfileNic — InfiniBand / Ethernet inventory, including passthrough-eligible NICs.
    - `ib_class_count` integer
    - `eth_class_count` integer
    - `ib_devices` string[]
    - `bridge_pfs` string[]
    - `passthrough_candidates` string[]
    - `passthrough_numa_nodes` integer[]
  - `nvswitch` HostProfileNvswitch — NVSwitch inventory (passthrough stubs are reproduced offline per switch).
    - `present` boolean
    - `count` integer
    - `devices` string[]
    - `numa_nodes` integer[]

## Response `200`

Successful Response

- HostProfileStatusResponse — Response for POST /servers/tdx/host_profiles/status: is this host class known, and for which images? The read-only counterpart to the submission response, and the gate `chutes-cvm host verify` runs. Deliberately version-free -- a host is verified before it has downloaded any image, so nothing here depends on what the caller happens to have on disk. Whether one SPECIFIC image can boot is POST /servers/tdx/preflight.
  - `fingerprint` string, required
  - `status` 'accepted' | 'pending' | 'unknown', required — Retention lifecycle of a submitted host class -- monotonic, only ever advances (unknown -> pending -> accepted) and never regresses. ``accepted`` is class-level and version-agnostic: a measurement was generated for this fingerprint at some point, so the class is on the attestable set and retained (its profile is kept for RTMR0 regeneration). It is NOT the answer to "can version X launch here" -- that is POST /servers/tdx/preflight, which joins the caller's (version, rc) to the class's measurements. Submission only reports which of the three the class is in; POST /servers/tdx/host_profiles/status reports the same lifecycle without storing anything.
  - `measurements` HostProfileMeasurement[], required
    - `version` string, required
    - `rc` boolean, required
  - `detail` string, required

## Other responses

- `422` — Validation Error

## Changes

- **2026-09-15** `fe1de11b2a0e` — 2 info
  - added the new optional request property `gpu/pci_bars`
  - added the new optional request property `gpu/pci_class`
- **2026-09-02** `37e3c562aa28` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/chutes/apis/fastapi/changes/servers/tdx/host_profiles/status/post.md)

---

[API](https://skmtc.dev/chutes/apis/fastapi.md) · [All operations](https://skmtc.dev/chutes/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc.dev/chutes/apis/fastapi/revisions/fe1de11b2a0e?raw)