dstack-mr diagnose lists RTMR0 ACPI inputs the generator does not consume (hpet, host_share_mode) and omits two it does

Start with dstack-mr/cli/src/main.rs:218-221 and compare its RTMR0 label with MachineConfig in crates/qemu-acpi/src/topology.rs:7-22 and the construction in dstack-mr/src/acpi.rs:31-45. Check the related PCI slot accounting in vmm/src/app/qemu.rs:822-861, then confirm the diagnostic names only inputs consumed by the generator and records why host_share_mode is dropped; coordinate with PR #679.

Label: DESIGN. Operator-facing diagnostic accuracy. The measurement code is correct; the label next to it is not.

Base: origin/next @ 030fbb2183.

What the design currently is

dstack-mr/cli/src/main.rs:218-221 tells an operator that the three RTMR0 ACPI events vary with:

"varies-with: cpu_count, pic, smm, hpet, hotplug_off, pci_hole64, root_verity,
 host_share_mode, num_gpus, num_nvswitches, hugepages, qemu_version"

MachineConfig — the sole input to qemu_acpi::build — is crates/qemu-acpi/src/topology.rs:7-22:

pub struct MachineConfig {
    pub qemu_version: QemuVersion,
    pub cpu_count: u32,
    pub memory_size: u64,
    pub pic: bool,
    pub smm: bool,
    pub hugepages: bool,
    pub num_gpus: u32,
    pub num_nvswitches: u32,
    pub num_nics: u32,
    pub num_verity_volumes: u32,
    pub hotplug_off: bool,
    pub root_verity: bool,
    pub pci_hole64_size: Option<u64>,
}

There is no hpet field. There is no host_share_mode field. host_share_mode is validated and then dropped — dstack-mr/src/acpi.rs:27-30:

match self.host_share_mode.as_str() {
    "" | "9p" | "vvfat" | "vhd" => {}
    value => bail!("invalid shared disk mode: {value}"),
}

and it does not appear in the MachineConfig built four lines later (acpi.rs:31-45).

Conversely the label omits memory_size and num_nics, both of which are consumed (acpi.rs:35, :40).

Why the drop is correct (this took checking, and is worth recording)

All three host-share modes attach exactly one PCI function on the root bus — vmm/src/app/qemu.rs:822-861: -virtfs …,id=virtfs0 for 9p, virtio-blk-pci,drive=vvfat0 for vvfat, virtio-blk-pci,drive=hd2 for vhd. The DSDT slot accounting is fixed_slots = 4 + root_verity; regular_slots = fixed_slots + num_nics + num_verity_volumes (crates/qemu-acpi/src/dsdt/mod.rs:44-45), with the host-share device inside the fixed four. So the mode does not move the generated tables, and the generator is right to ignore it.

That reasoning is currently written down nowhere, which is part of why the label drifted.

Reachability

Not a security boundary — no attacker, no credential, no rate. The cost is entirely operator time.

What it costs

dstack-mr diagnose exists for exactly one situation: an operator staring at an RTMR0 mismatch and asking what could have caused it. Two of the twelve fields it offers as explanations cannot produce one, and one of them — host_share_mode — is a real, host-settable knob (vmm/vmm.toml, VmConfig) that an operator can change and will therefore suspect. It is a plausible-looking dead end handed to someone already debugging. Meanwhile memory_size, which genuinely does move RTMR0 (through the TD HOB at dstack-mr/src/tdvf.rs:492-501 as well as through ACPI), is not listed against the ACPI events at all.

Steelman

The list is a human-readable hint in a diagnostic subcommand, maintained by hand beside a table that changes rarely. Being generous about what "varies with" means costs nothing in the common case, and host_share_mode is plausibly there because it is validated in build_tables — someone reading acpi.rs from the top would reasonably conclude it participates.

Improvement directions

1. Cheap and self-maintaining. Derive the varies-with list from MachineConfig's field names rather than writing it out, so a field added to or removed from the struct cannot drift from the label. This also picks up memory_size and num_nics for free.
2. Cheapest. Delete hpet and host_share_mode from the string, add memory_size and num_nics, and put a one-line comment at dstack-mr/src/acpi.rs:27-30 recording why host_share_mode is validated and dropped — the single-PCI-function argument above — so the next reader does not have to re-derive it from qemu.rs.

Both are small. (1) is strictly better if the diagnose output is expected to keep growing.

Note: #679 is the open PR that owns this subcommand; this probably belongs there or on top of it rather than as an independent change.