Re-read the QEMU integration test work #31

Headed for the OCP demo on light review. Listed worst-first by how much
it would cost to have got wrong. All of it is additive and test-only
except OpenPRoT#541, which changes
services/orchestrator/driver and is merged to ocp-global-demo-wip as
bd062c9.

Merged to ocp-global-demo-wip on 2026-10-08, in this order: the harness
seed as d5fcaf5, OpenPRoT#533 as 8ba0756,
OpenPRoT#536 as 6f11f2f, OpenPRoT#537 as ca7e35f and
OpenPRoT#538 as 81da269. The rest still sit on
cq-demo-integration.

Read first, these are not test directories:

• services/mctp: Add the loopback transport OpenPRoT/openprot#537 services/mctp/transport-loopback, merged as
  ca7e35f. Lives beside the shipped MCTP code and will be read as a
  library, not as a test fixture. About 150 lines. Check the queue
  ownership: the router takes the sender by value, so the caller
  holds the queue and lends it. Its lib.rs was split into queue.rs
  and sender.rs before the merge, so the 150 lines are three files
  now.
• target/ast10x0/harness/qemu_runner.py and defs.bzl. Every QEMU
  test in the tree runs through this file. About 40 lines. Check
  that seeding from a file cannot truncate: oversize is an error,
  not a silent cut. This was harness: Seed a CS image from a file OpenPRoT/openprot#532, which was merged to demo-wip and
  taken back out; it went in again on 2026-10-08 as d5fcaf5,
  underneath tools: Add the flash image builder OpenPRoT/openprot#533, with no PR of its own.

Read after, test-only:

• tools: Add the flash image builder OpenPRoT/openprot#533 tools/flash_image, merged as 8ba0756. Host
  build tool. The layout goes through the real
  Region/Slot/ImageLayout constructors on purpose, so a test image
  cannot describe a layout the orchestrator would refuse.

• services/test: Add the mock BMC boot model OpenPRoT/openprot#536 services/test/mock-bmc, merged as 6f11f2f.
  The boot model. Two behaviours only: a late boot is Boots with a
  long delay, so lateness is a property of the deadline rather than
  of the device.

• target/ast10x0: Add the mock BMC integration test OpenPRoT/openprot#538 target/ast10x0/tests/integration/mock_bmc,
  merged as 81da269. The first scenario. The negative case is
  automated now, as mock_bmc/device_hangs.

• target/ast10x0/tests/integration/pldm_update. A full DSP0267
  update between an agent and a firmware device, three apps in one
  image. No PR yet; it is commit 331321c on cq-demo-integration.
  The firmware device stages into RAM and the agent's bytes are
  checked against a known pattern, so the check to make is whether
  anything here could pass without the whole sequence running.

• The boot scenario's RoT app now calls bring_up, so the state
  machine, the platform driver, the device table and CheckpointWalk
  are the shipped code rather than a hand-rolled sequence. No PR
  yet; it is commit ef645ea on cq-demo-integration. Read the board
  stubs: the verifier authenticates everything, and that is a
  decision about the demo, not an oversight.

• The PLDM scenario's firmware device now reports to a real
  orchestrator in a fourth app and waits for its answer. No PR yet;
  it is commit 9bb3b7e on cq-demo-integration. Two gaps are in the
  commit message on purpose: the driver's Updatable stages nothing,
  and a refusal is recorded rather than enforced. Check that the
  three-message protocol cannot let a step run before its answer.

• Wiring the two test boards to the verifier seam
  driver: Wire IncrementalVerifier into the update pump OpenPRoT/openprot#541 added is 980d4de. It leaves two verdicts on
  the same candidate, the device's and the RoT's, and the update
  needs both.

• The PLDM update test failed about six runs in ten before dc7cc19.
  The agent could reach the bus before the device claimed its
  endpoint id, so discovery is retried now. Twenty consecutive suite
  runs pass. Worth a look at whether the retry hides anything else.

• target/ast10x0/tests/integration/README.md says how to run each
  scenario and how to make it fail. Read it first: it is the
  shortest path into the rest of this list.

• The three negative checks are test targets now, not hand edits. No
  PR yet; it is commit bf43011 on cq-demo-integration, and
  scenario.bzl plus SCENARIO_CFGS is the part worth reading. Check
  the claim each negative makes: it has to name the failure it
  arranged, not just observe that the run did not finish.

• The firmware device stages into SPI NOR on CS1 now, and the runner
  reads the backing file back after QEMU exits. No PR yet; commits
  28c2063 and ea245b6 on cq-demo-integration. ea245b6 touches
  qemu_runner.py and defs.bzl, so it is not test-only: every QEMU
  test in the tree runs through that file. The claim to check is
  that a guest printing PASS still fails the test when the flash
  does not match, which was verified by flipping a byte.

• full_update, the whole demo script in one image: five apps, an
  update over PLDM followed by the device being reset into it and
  reporting ready a second time. Commit 632122b on
  cq-demo-integration, which is pushed to the 9elements fork. Two
  things to check. The RoT owns the sentinel here rather than the
  firmware device, through the rot_owns_verdict flag, which should
  appear in exactly one BUILD file and leave the other scenarios'
  verdicts where they were. And the claim is the ordering, so look
  at whether a stale ready report could stand in for the second
  boot: the reset path clears the latch, and the run requires the
  reset count to go up across the activation.

• full_update's own negatives, commit 74220c6 on
  cq-demo-integration, pushed to the fork. device_hangs keeps the
  device from coming up at all; device_stays_down lets the update
  succeed and then keeps the device from returning. The claim to
  check is that each passes on its own outcome and nothing else: a
  run that commits has to fail both, and device_stays_down's pass
  has to show the update accepted and activating in the log before
  the checkpoint failure, or it is passing on a broken update rather
  than on a device that never came back.

• Discovery, transfer error, cancel and offer-before-supervising scenarios OpenPRoT/openprot#557, merged as f604054.
  Type 0 terminus discovery before offering an update,
  transfer_error (agent errors on one data request),
  cancel_mid_transfer (agent withdraws two chunks in), and
  offer_before_supervising (offer arrives before supervision,
  refused as Busy). The discovery moves the start-order retry to
  GetPLDMTypes. The scenario RoT's accept_update returns
  Option<RejectReason> instead of bool, so the reason is decided
  where the cause is known. Eleven scenarios, twenty-two targets,
  all green.

• Rename mock BMC to mock downstream device OpenPRoT/openprot#559, merged as 0e2ff6c.
  Renames mock-bmc to mock-downstream-device: crate, type and
  scenario. The mock models the device on the other end of the reset
  and ready lines, not the BMC. pldm/firmware_update keeps the old
  name, where card B really is the update agent.

• ast10x0: Ask for one chunk twice in the update scenario OpenPRoT/openprot#560, merged as 4519639.
  A twelfth scenario, pldm_update/retry_chunk. The agent answers one
  RequestFirmwareData with RetryRequestFwData, the device waits out
  FD_T2, asks for the same window again and the update completes.
  Nothing else makes the device request a window twice, so the
  re-delivery branch in its download callback had no caller. The test
  device reads the kernel clock now; with FdOps::now returning a
  constant its FD_T1 and FD_T2 windows never elapsed and no retry
  could fire. Checked against the failure it exists for: with 08763db
  reverted the run ends at "FD: the retry was asked for and the update
  did not complete". The second commit drops the commit timeout from
  the gap list, since Arm the commit watchdog from the machine's window OpenPRoT/openprot#554 was closed and nothing arms a deadline on
  BootConfirmed.

• orchestrator: Confirm the eRoT's own update trial at the next boot OpenPRoT/openprot#565, merged as bffec2c.
  mock_downstream_device/self_trial. The board gets a session and the
  eRoT's own floor, the session starts at TrialPending with the trial
  image running, and the run passes when the chain coming up has moved
  it to Committed. What Ready proves is only that the chain under the
  eRoT came up, which is the bar the 2026-10-12 decision settled on.
  Checked against the failure it exists for: with the ConfirmSelfTrial
  emit removed from Ready entry the run ends at "the chain came up and
  the self trial was not confirmed". Only this scenario settles;
  pldm_update and full_update still wire self_image: None.

• orchestrator: Move the SVN floor advance to the update agent's ask OpenPRoT/openprot#568, merged as 33b0e3e.
  The SVN floor advance moves off the confirmed boot onto
  Event::SvnCommitRequest, which the event loop injects when the update
  agent sends UpdateSecurityRevision. No firmware device parks at
  SvnCommitPending yet, so full_update and pldm_update dispatch that
  event themselves, the way they already dispatch BootConfirmed.
  GAPS.md says what a green run therefore does not say: the 0x22
  callback is not in the pinned pldm-lib, and the event-loop glue that
  reads the status and answers is unwritten.

What to look for rather than reading line by line: each test's green has
to mean something. For every scenario, ask what would still be true if
the test were lying, and whether something rules that out.

Merge commits go here as they land, since rebase merging rewrites the
SHAs and the PR numbers alone get harder to follow later.

Not a re-read, a change to make:

• services/orchestrator/driver, the update pump's verifier state.
  update_verifier is an Option only so the session can be moved
  out to poll it and moved back. The hole that leaves is real: a
  bail-out between the two has to hand the verifier back by hand
  (drop_session), and a path that forgets would leave the driver
  unable to verify anything ever again. Putting the session in the
  phase (UpdatePhase::Authenticating(V::Session)) removes the
  Option and the last defensive arm with it. The cost is that
  UpdateJob becomes generic over the board, which threads through
  pending_update and every method that touches it.
  driver: Wire IncrementalVerifier into the update pump OpenPRoT/openprot#541 went as far as collapsing Authenticating
  into Staged, so the phase and the verifier can no longer
  disagree; nothing is wrong today.