issues: what the shipped OS takes from QEMU, and the track to run in any open-source hypervisor

[Japabu]

An audit, issues only: every place the shipped OS — kernel/, loader/, system/, lib/, sdk/ — depends on QEMU rather than on UEFI, ACPI, PCIe and virtio 1.2, and what each other target hypervisor (Cloud Hypervisor, crosvm, VirtualBox, bhyve) offers it. No code changes.

What landed

Eight new files under issues/, nothing else touched (8 files, 488 insertions; no production or test lines).

File	Kind	What the shipped OS takes from QEMU
issues/toyos-runs-in-any-open-source-hypervisor.md	track	lists everything below, the earlier issues on the same path, the harness options that hide three of them, each hypervisor's devices, and what is unsupported
issues/diskserver-claims-qemus-nvme-by-its-pci-id.md	defect	diskserver's row names pci:1b36:0010, QEMU's NVMe id; the standard identity is class 01:08:02. The configs the T14 boots stay out of the exit until its NVMe holds no Ubuntu
issues/the-virtio-drivers-match-only-a-non-transitional-device-id.md	defect	netstack and the kernel's console match only the 0x1040-based id, against virtio 1.2 §4.1.2.2
issues/a-virtio-function-that-offers-no-access-platform-is-handed-over-as-translated.md	defect	a virtio function that bypasses the unit is handed over, against virtio 1.2 §6.1; the supervisor is to refuse it before it moves the claim in, the kernel staying without virtio
issues/the-x86-clock-calibrates-against-an-hpet-or-the-boot-panics.md	defect	expect("ACPI: HPET not found"); Cloud Hypervisor, crosvm and a default VirtualBox publish no HPET
issues/a-hardware-reduced-x86-machine-has-no-power-off-and-no-power-button.md	defect	power-off and the power button need PM1 fixed hardware; Cloud Hypervisor's FADT is hardware-reduced
issues/no-claim-gets-an-address-space-under-virtio-iommu.md	defect	the kernel programs VT-d and SMMUv3 (AMD-Vi it finds and programs not); Cloud Hypervisor offers virtio-iommu, per device and off by default, and crosvm only for a passed-through host device. Programming one puts virtio in the kernel on both architectures, and that and x86's unremapped messages are the owner's to rule
issues/the-ap-trampoline-is-written-at-0x8000-whatever-the-memory-map-says-is-there.md	defect	a fixed low page checked against nothing, which q35's edk2 happens to leave free

Classification, as the track records it:

• Harmless, the launcher's and the harness's alone: the xHCI models, the USB boot stick, -vga std, ramfb under AArch64's edk2, intel-iommu,caching-mode=on, amd-iommu, kernel-irqchip, iommu-testdev, QMP, slirp. No shipped code drives fw_cfg, ramfb, pvpanic, isa-debug-exit, debugcon or a Bochs display, and none tests a hypervisor signature; the one hypervisor read is toyos-cpuvuln's of CPUID.1:ECX[31], which Intel's SDM Vol. 1 Table 21-9 allocates "for use by software emulation".
• QEMU-only dependencies of the shipped OS: the seven above, plus five already filed and named in the track.
• Adaptations that degrade nothing: the TCO table's q35 row, netstack's 82574L row, the PMU-less hard-lockup path, the loader's PI GCD read.
• Harness options that hide a dependency: -non-transitional, iommu_platform=on, msix-exclusive-bar=on.
• Unsupported, not owed: bhyve's HDA, which raises INTx alone; ToyOS arms MSI-X or MSI only (the orchestrator's ruling 3).

Review round 1 (issuecomment-6131184845), answered through the orchestrator's rulings (issuecomment-6131213771)

• BLOCKER, ACCESS_PLATFORM in the kernel: ruling 1. The check is the supervisor's, before it moves the claim in; the exit reads the supervisor's refusal line, its negative control (netstack endowed with the check deleted), and git grep -i virtio kernel/src/pcidev kernel/src/iommu still empty (empty at this head).
• BLOCKER, virtio-iommu stated as ordinary work on AArch64: ruling 2. The file names the conflict with "virtio does not appear anywhere in the kernel" for both architectures; the track lists it under Blocked on.
• NOTE, AMD-Vi: the kernel programs VT-d and SMMUv3 only; the file and the track cite issues/an-amd-vi-machine-isolates-no-device.md.
• NOTE, Cloud Hypervisor's virtio-iommu off by default: said, in the file, the table and the no-IOMMU list. crosvm read too: its virtio-iommu takes only a --vfio …,iommu=viommu host device, never an emulated one.
• NOTE, Cloud Hypervisor's PM timer: removed as a source; the file quotes ACPI §5.2.9's note and §4.1, and Cloud Hypervisor states leaf 0x40000010 alone.
• NOTE, "fail gracefully": §4.1.5.1.1.1, read in the CS01 text.
• NOTE, Linux citation: the cpuvuln clause cites Intel's definition of CPUID.1:ECX[31] (SDM Vol. 1, 253665-093US, Table 21-9); AMD's APM timed out twice and is unread.
• NOTE, NVMe by class on the T14: ruling 4, the T14's configs stay out of the exit.
• NOTE, INTx: ruling 3, listed as unsupported, not as work.
• NOTE, "once the harness boots one": the exit names Cloud Hypervisor, booted by hand, powering off on shutdown and on /vm.power-button.
• Cloud Hypervisor's I/O APIC, which the review read in its MADT always: the table says both what its MADT lists and what its documentation says.

Clean-room (#902 landed meanwhile). Hypervisor source is read clean-room: the issues state facts and cite only specifications, vendors' documents, hypervisors' documentation and the tree; every source file and commit read is provenance in sources.md, which the track links. Linux is named only as a host platform.

Evidence

Read, never booted, at the commits sources.md names; it also records what was read for this round and what could not be.

• cargo run -- --ci host at d0b5ae1149a48d65cccd06366c6e5cfe13ed6815 (origin/main b680a973b merged): EXIT=0, Host: 76 step(s), all green — log, exit, head and load.
• No guest test or image build: the branch changes no source, manifest or test.

Unsure

• ACPI 6.5 is still unread: uefi.org answers a JavaScript challenge (403) to this tree's User-Agent and the Internet Archive was offline. Every ACPI section cited (§4.1, §4.1.1.1, §4.8.3.3, §4.8.3.7, §5.2.9) is as a third-party text copy of ACPI 6.6 numbers it, and each file says so.
• crosvm's UEFI path (--bios) and bhyve-on-arm64's tables were not read; the track says so.
• Every "stops at" and "still lacks" in the track is on paper until each hypervisor boots the image.

🤖 Generated with Claude Code

https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy

[Japabu]

Review, round 1, head 689e4e792b70b4fc75d70b2a45b17f7a7f09e69b, against .claude/agents/reviewer.md at origin/main 97f07c381.

Net (git diff --shortstat origin/main...689e4e792): 8 files, +446 −0, all of it new files in issues/. Production 0, tests 0. Since the merge base ab655a115, main has changed only .claude/agents/orchestrator.md.

Checked, no finding

• Host gate. ToyOSOrg/evidence 8ea1e528c has a verified signature, and its commit message names this head. ci-host.txt reads EXIT=0 at 689e4e792, and ci-host.log ends Host: 76 step(s), all green. Its FAILED lines are the loom models that are meant to fail. No guest test is reached.
• Citations into the tree. Every path the eight files cite exists at this head, and the sites match what the files say of them, with the one exception in the NOTEs (AMD-Vi). The sites checked: .expect("ACPI: HPET not found") (kernel/src/arch/x86_64/boot.rs:108), TRAMPOLINE_PAGE, kernel_main's withheld-region check, Offer::accept, pcidev::claim's Ambiguous, both pci:1b36:0010 rows, Controller::open's class check, and the -non-transitional, iommu_platform=on and msix-exclusive-bar=on arguments in build/qemu.rs and tests/common/qemu.rs.
• Overlaps. No existing issue covers any of the seven. The loader's HPET half is cited, not refiled.
• Frontmatter and owners. Each file follows issues/README.md's form. Every owner the files name exists: the hypervisor track names the orchestrator, and the ACPI-mode track is an open track, which issues: an image's GUIDs are drawn from the host's random source #881 accepted as an owner.
• ACPI section numbers.
  • §4.8.3.3 is "Power Management Timer (PM_TMR)" and states 3.579545 MHz. §4.8.3.7 is "Sleep Control and Status Registers", "for system sleep state entry on HW-Reduced ACPI systems". Both read so in ACPI 6.6 (a third-party text copy, matotubol/svmvisor b93b652, docs/ACPI_Spec_6.6/page_154.txt and page_157.txt).
  • QEMU cites "ACPI 5.0: 4.8.3.7 Sleep Control and Status Registers" (hw/i386/acpi-microvm.c:162 at 615ece3c).
  • 6.5 itself is unread. uefi.org answers 403 to the tree's User-Agent, and the Internet Archive was offline.
• Hypervisor facts, re-read at the commits sources.md names.
  • Cloud Hypervisor 47ea5d92:
    • No HPET table.
    • The FADT sets HW_REDUCED_ACPI|RESET_REG_SUP|TMR_VAL_EXT, puts SLEEP_CONTROL_REG at 244 and SLEEP_STATUS_REG at 256, and writes PM1a only under legacy_acpi_pm1a (vmm/src/acpi.rs:320-423).
    • The GED is ACPI0013, and its _EVT notifies \_SB_.PWRB (devices/src/acpi.rs:197-222).
    • Leaf 0x4000_0010 EAX is the TSC rate in kHz where the TSC is invariant (arch/src/x86_64/mod.rs:1126-1135).
    • The MSI-X table and PBA share the virtio capability BAR, and the device id is 0x1040 + type (virtio-devices/src/transport/pci_device.rs:281-300,461).
    • The tables include a VIOT (acpi.rs:1093).
  • crosvm 098250cd: the FADT has no HW_REDUCED_ACPI and its PM timer is "not supported" (x86_64/src/acpi.rs:238-300). Leaf 15H is present only when required or forced (x86_64/src/cpuid.rs:108,251-254). devices/src has no HPET.
  • VirtualBox 32f5f1de:
    • NVMe is 80ee:4e56, class 01:08:02, with MSI-X in BAR 5 (DevNVMe.cpp:117-123,7358-7394).
    • virtio-net is 0x1000 at transitional revision 0 (DevVirtioNet.cpp:211, VirtioCore.cpp:3074-3081).
    • VIRTIO_F_ACCESS_PLATFORM is "VirtIO 1.1 NYI" (VirtioCore.h:232).
    • HpetEnabled defaults to false (DevACPI.cpp:4408).
    • The Intel IOMMU remaps interrupts with SVT checks (DevIommuIntel.cpp:242-251).
    • The tablet interfaces are subclass 0 (UsbMouse.cpp:1035).
  • bhyve 39d6e222:
    • virtio uses an I/O BAR (virtio.c:136).
    • NVMe is fb5d:0a0a with MSI-X in BAR 4 (pci_nvme.c:91,3325-3326).
    • The NIC is the 82545EM.
    • HDA uses INTx alone (pci_hda.c:400-407,1270).
    • The FADT has SMI_CMD, PM1 and the PM timer, and an HPET table is built (acpi.c:508-530,582).
    • The USB mouse is boot subclass, mouse protocol (usb_mouse.c:183-184).
  • QEMU 615ece3c:
    • A transitional device refuses iommu_platform (hw/virtio/virtio-pci.c:2060).
    • disable-legacy=auto resolves by pcie_port (:2204,2255-2256).
    • The hpet machine property is hw/i386/pc.c:1747.
• Still owed a measurement, because nothing was booted:
  • every "stops at" and "still lacks" in the track's :80-95;
  • that no console carries the HPET panic on Cloud Hypervisor without --serial;
  • Cloud Hypervisor's I/O APIC. docs/device_model.md:72 disables it without a serial port, as the track says, but create_madt lists one unconditionally (vmm/src/cpu.rs:1836), so what the kernel's ioapic::init meets there is unread;
  • whether an emulated device's DMA into 0xFEE00000..0xFEEFFFFF raises an interrupt under each hypervisor's virtio-iommu (below);
  • crosvm's --bios UEFI and whether bhyve-arm64 publishes an RSDP;
  • how the T14's map types page 0x8000. That one is metal, so it is the orchestrator's.

MSI under virtio-iommu on x86-64, for the ruling (from the virtio specification, the hypervisors' own documentation and source, and Intel VT-d; Linux not used)

• Virtio defines no interrupt remapping.
  • Virtio 1.2 CS01 §5.13.6 defines five requests: ATTACH, DETACH, MAP, UNMAP and PROBE. None carries an interrupt, and the device holds no table a message is checked against. 1.3 CSD01 §5.13.6 has the same five.
  • §5.13.6.8.1: a RESV_MEM_T_MSI region "is a doorbell for Message Signaled Interrupts" that "the driver cannot map". Where an endpoint has no such region, "the driver creates an MMIO mapping to the doorbell" (VIRTIO_IOMMU_MAP_F_MMIO, §5.13.6.5).
  • §5.13.6.8.1.2 bounds the device only by a SHOULD: an endpoint's access to the region must not "affect any other component than the endpoint and the driver". The driver is the guest's own, so the spec checks no requester and does not confine a vector to the endpoint.
• Every target declares x86's interrupt window as that bypass.
  • QEMU q35 declares 0xfee00000:0xfeefffff as T_MSI (hw/i386/pc.c:1330-1337). virtio_iommu_translate passes any access inside the window, at the permission asked, to system memory at the same address (hw/virtio/virtio-iommu.c:1226-1230).
  • Cloud Hypervisor uses the same window (vmm/src/device_manager.rs:1651-1652). Its translate_msi passes an address inside the window untranslated and the data word unchanged (virtio-devices/src/iommu.rs:1113-1129).
  • crosvm uses the same window (devices/src/virtio/iommu.rs:527-540).
  • Cloud Hypervisor's own docs/iommu.md, "Nested usage", boots its guest with the switch that accepts unremapped interrupts before it assigns a device behind its virtio-iommu onward.
• What VT-d adds that virtio-iommu lacks. VT-d Rev. 4.1 (D51397-016):
  • §3.15: single-DWORD writes without PASID to FEEx_xxxxh "are treated as interrupt requests and are not subjected to DMA remapping (even if translation structures specify a mapping for this range)". So translation alone never bounds a device's interrupts.
  • §5.1.4: with remapping on and CFIS clear, compatibility-format requests "are blocked". A remappable request is checked against its IRTE's SVT, SID and SQ (§9.9), and it "is blocked" if the source-id check fails.
  • AMD IOMMU 48882 is unread: amd.com timed out for this User-Agent.
• What is left under virtio-iommu on x86:
  • Two guards in the tree still hold. pcidev never maps the BAR holding the MSI-X table, and MSI lives in config space.
  • Nothing in the virtio specification bounds a DMA write the holder aims at 0xFEExxxxx.
  • On QEMU, such a write reaches system memory at that address untranslated. This was read, not booted.
  • On Cloud Hypervisor and crosvm, whether an emulated device's DMA into the window raises an interrupt was not read.
  • That measurement is what a ruling either way rests on. The file's present wording of the x86 half is accurate.

BLOCKER

• issues/a-virtio-function-that-offers-no-access-platform-is-handed-over-as-translated.md:37-38,42-46
  • What: the exit makes the kernel read a virtio feature word in its claim path, as a pcidev Refusal.
  • Why it sends the branch back: git grep -i virtio over kernel/src/pcidev and kernel/src/iommu finds nothing today. The owner's recorded target is that "virtio does not appear anywhere in the kernel" (issues/every-driver-is-still-in-the-kernel.md:9), and the file never names the conflict. ":37-38" rules out only the holder. The supervisor, which mints the claim and is trusted, could read the word before it moves the claim in.
  • Fix: name the conflict and leave where the check lives to the owner, adding that to the track's :119-122. Or write an exit that a check outside the kernel meets.
• issues/no-claim-gets-an-address-space-under-virtio-iommu.md:25-30,45-47
  • What: the AArch64 half is presented as ordinary work, and only x86's interrupts are put to the owner.
  • Why it sends the branch back: the unit is the kernel's (pcidev's header), so either half needs a virtio PCI transport and virtqueues in the kernel. That breaches the same recorded target (every-driver-is-still-in-the-kernel.md:9). The file states the owner's open question more narrowly than the record makes it.
  • Fix: name the conflict as the owner's for both halves, and add it to the track's :119-122.

NOTE

• issues/no-claim-gets-an-address-space-under-virtio-iommu.md:12-15
  • What: "The units this kernel programs are VT-d (DMAR), AMD-Vi (IVRS) and SMMUv3" is false of the tree.
  • Why: AMD-Vi "programs no unit" (kernel/src/arch/x86_64/iommu_unit.rs:4-7, amdvi/mod.rs:7-9). So VirtualBox's --iommu amd is refused like a machine with no unit, until issues/an-amd-vi-machine-isolates-no-device.md lands. The track cites neither.
  • The PR body's "the kernel programs VT-d, AMD-Vi and SMMUv3" repeats it.
• issues/toyos-runs-in-any-open-source-hypervisor.md:75,38-39 and issues/no-claim-gets-an-address-space-under-virtio-iommu.md:15-22
  • What: Cloud Hypervisor puts a device behind virtio-iommu only when the device is tagged iommu=virtio, and "the default value will always be off" (its docs/iommu.md).
  • Why: so by default Cloud Hypervisor is the no-unit case of issues/a-machine-without-an-iommu-refuses-every-claim.md. The IOMMU cell and the no-IOMMU list (:38-39) should say so, as the VirtualBox row does. crosvm's default was not read.
• issues/the-x86-clock-calibrates-against-an-hpet-or-the-boot-panics.md:23,31-33
  • What: the file counts Cloud Hypervisor's PM timer as a source.
  • Why: its FADT sets HW_REDUCED_ACPI, and ACPI's FADT note (§5.2.9) has OSPM "ignore fields related to the ACPI HW register interface: Fields at offsets 46 through 108 and 148 through 232". X_PM_TMR_BLK is offset 208, so a conforming reading of Cloud Hypervisor states only leaf 0x40000010. §4.1 agrees: under HW-reduced, "the ACPI Fixed Hardware interface is not implemented". The tree's own toyos_acpi::fixed_hardware refuses that FADT whole.
• issues/the-virtio-drivers-match-only-a-non-transitional-device-id.md:13-14
  • What: "fail gracefully" is virtio 1.2 §4.1.5.1.1.1, not §4.1.4.
• issues/toyos-runs-in-any-open-source-hypervisor.md:65-67 and the PR body's Classification
  • What: a Linux citation. toyos-cpuvuln's reading of the hypervisor bit is justified "as Linux reads it".
  • Fix: cite the vendors' CPUID definition of CPUID.1:ECX[31], or drop the clause.
  • The line repeats kernel/cpuvuln/src/counters.rs:5-8's own framing, which this branch did not write.
  • :19 ("run on Linux hosts") and the diskserver file's "holds Ubuntu" state where things run, and cite no Linux behaviour.
• issues/diskserver-claims-qemus-nvme-by-its-pci-id.md:38-42,46-48
  • What: the exit has "both shipped configs" claim NVMe by class. On the T14, that hands diskserver the controller holding the Ubuntu the metal workflow reboots through.
  • Why: the file records this as a constraint, but nobody with the authority has accepted it.
  • Fix: leave the T14's row out of the exit, or name the owner's word on it.
• issues/toyos-runs-in-any-open-source-hypervisor.md:88-93
  • What: "an interrupt for its HDA, which raises INTx alone" is listed as work. Line-based interrupts are a path the tree arms for no device (pcidev: MSI-X or MSI), and root CLAUDE.md says "no fallbacks".
  • Fix: list it under "Blocked on" as the owner's call rather than as a missing driver.
• issues/a-hardware-reduced-x86-machine-has-no-power-off-and-no-power-button.md:40-42
  • What: "once the harness boots one" makes half the exit conditional on something nothing commits to.
  • Fix: name the machine. Cloud Hypervisor, by hand as the track's exit does, is one.

SEND BACK

[Japabu]

Rulings on round 1 (#896 (comment)).

1. ACCESS_PLATFORM (BLOCKER 1): the check lives outside the kernel. The supervisor mints the claim and is trusted, so it reads the function's offered features before it moves the claim in, and refuses a virtio function that does not offer ACCESS_PLATFORM on a machine whose functions are translated. The kernel stays virtio-free, as issues/every-driver-is-still-in-the-kernel.md records. How the supervisor reads the word is the stage's design.
2. virtio-iommu (BLOCKER 2): both halves need a virtio transport in the kernel. That conflicts with the same recorded target, and the owner will rule on it. The file names the conflict for both architectures, and the track lists it under "Blocked on". Cloud Hypervisor's virtio-iommu is off by default, so by default it is the no-unit case. Say so (NOTE 2).
3. INTx (NOTE 6): ToyOS arms MSI or MSI-X only, and line-based interrupts are not taken up. A device that raises INTx alone, like bhyve's HDA, is unsupported, and the track lists it as such, not as work.
4. NVMe by class on the T14 (NOTE 5): the T14's row stays out of the exit until the T14's Ubuntu is gone.
5. The other NOTEs are taken as written. The toyos-cpuvuln clause cites the vendors' CPUID definition of CPUID.1:ECX[31], or goes.

[Japabu]

Review, round 2, head d0b5ae1149a48d65cccd06366c6e5cfe13ed6815, against .claude/agents/reviewer.md at origin/main b680a973b (#902's clean-room rule included). Round 1: issuecomment-6131184845. Rulings: issuecomment-6131213771.

Net (git diff --shortstat origin/main...d0b5ae114): 8 files, +488 −0. All of it is new files in issues/. Production 0, tests 0. The merges c1d0db288 and 385d4f3a0 bring in only main. Since round 1, the branch has touched nothing outside its own eight files.

Round 1's findings

• BLOCKER, the ACCESS_PLATFORM check in the kernel: CLOSED by ruling 1.
  • issues/a-virtio-function-that-offers-no-access-platform-is-handed-over-as-translated.md:37-45 rules out the holder and the kernel, citing issues/every-driver-is-still-in-the-kernel.md. It gives the check to the supervisor before the claim moves, on a translated machine, and leaves how it reads the word to the stage's design. That is ruling 1 as given.
  • The exit (:49-54) reads the supervisor's refusal and netstack's no NIC on this machine (system/netstack/src/main.rs:312), with the check deleted as the negative control.
  • The git grep -i virtio kernel/src/pcidev kernel/src/iommu the exit names is empty at this head (run for this review).
• BLOCKER, virtio-iommu stated as ordinary work on AArch64: CLOSED by ruling 2.
  • issues/no-claim-gets-an-address-space-under-virtio-iommu.md:36-42 names the conflict with "virtio does not appear anywhere in the kernel" (every-driver-is-still-in-the-kernel.md:9) for both architectures.
  • :53-56 puts x86's unremapped messages to the owner, quoting :17's "interrupt remapping included".
  • The exit (:65-70) waits on both rulings, and the track lists both under "Blocked on" (:128-131).
• NOTE, AMD-Vi: CLOSED.
  • no-claim…:12-17 says the kernel finds AMD-Vi units and programs none, which matches kernel/src/arch/x86_64/iommu_unit.rs:4, and cites issues/an-amd-vi-machine-isolates-no-device.md.
  • Track :56-58 says no target's default asks for AMD-Vi.
• NOTE, Cloud Hypervisor's virtio-iommu off by default: CLOSED.
  • Said in no-claim…:25-34, in the track's IOMMU cell (:82) and in its no-unit list (:41-43).
  • crosvm's default is now read: sources.md "Read for review round 1" has cmdline.rs, sys/linux.rs, device_helpers.rs and supports_iommu. It is stated without a citation.
• NOTE, Cloud Hypervisor's PM timer counted as a source: CLOSED.
  • the-x86-clock-…:22,36-42 now says "none", quotes §5.2.9's note and §4.1, and leaves leaf 0x40000010 as Cloud Hypervisor's only source.
• NOTE, "fail gracefully" section: CLOSED. the-virtio-drivers-…:13-14 cites §4.1.5.1.1.1.
• NOTE, Linux citation for the CPUID.1:ECX[31] reading: CLOSED by ruling 5.
  • Track :71-74 cites Intel SDM Vol. 1, 253665-093US, Table 21-9, quoted, and says AMD's APM is unread.
  • sources.md records the Intel document's URL and both AMD timeouts.
• NOTE, NVMe by class on the T14: CLOSED by ruling 4.
  • diskserver-claims-…:49-53 keeps the T14's configs out of the exit until its NVMe holds no Ubuntu, and cites the ruling.
  • Those configs are the tests/images/*case.toml rows the metal loop derives from (tests/metal/src/image.rs:143-147). Every one of them still names pci:1b36:0010, so the exit's scope is coherent: it moves only images/system.toml:232 and images/console.toml:87.
• NOTE, INTx as work: CLOSED by ruling 3.
  • Track :101-104 lists bhyve's HDA as unsupported and not owed, and cites ruling 3.
  • It cites arm_interrupt, which arms MSI-X or MSI and otherwise refuses (kernel/src/drivers/hda.rs:579-592).
  • It is no longer in the work list (:94-99).
• NOTE, "once the harness boots one": CLOSED.
  • a-hardware-reduced-…:38-44 names a Cloud Hypervisor x86-64 boot by hand, logged under its version and command line.
  • The FADT and DSDT fixture is "recorded by ToyOS", alongside lib/acpi/fixtures/. It is not a capture under another OS, which meets main's new Tests oracle rule.

Checked, no finding

• Clean-room (Another implementation's source is read only clean-room, and the tree names Linux only as a host platform or a libc interface #902).
  • No file cites another implementation's source. Every hypervisor fact is stated without a file, function or line.
  • The citations that remain are specifications (virtio 1.2 CS01, ACPI, Intel SDM, UEFI 2.10, PCI-SIG), the hypervisors' own documentation (Cloud Hypervisor's docs/iommu.md, docs/api.md and docs/device_model.md, VBoxManage modifyvm, bhyve(8)) and the tree.
  • The source files read are provenance in ToyOSOrg/evidence 0b2719328 sources.md, which the track links (:19-22).
  • Linux appears only as a host platform (track :22-23). "Ubuntu" names what the T14's disk holds, not an authority.
• Unread and unmeasured, said where it is.
  • Nothing booted: track :16-18, and "First stop, on paper" (:87).
  • ACPI 6.5 unread, sections numbered by a third-party 6.6 copy: a-hardware-reduced-…:24-25 and the-x86-clock-…:41-42.
  • AMD's APM: track :73-74.
  • The T14's map type at 0x8000, and every other hypervisor's map: the-ap-trampoline-…:19,22-23.
  • VirtualBox's and bhyve's stated TSC rate: the-x86-clock-…:24-25.
  • crosvm's --bios UEFI: track :83. bhyve-arm64's RSDP and crosvm on AArch64: track :115-117.
  • Cloud Hypervisor's I/O APIC cell (:82) gives both what is read in its MADT and what its documentation says. Which one the kernel's ioapic::init meets falls under :16-18's "not measured".
• Rulings stated as given. Each of rulings 1–4 is cited by number at its site, neither wider nor narrower than issuecomment-6131213771. The track's aim (:9) is attributed to the orchestrator's brief, not presented as the owner's words.
• Tree citations.
  • Every path the eight files name exists at this head.
  • Every string an exit reads exists: DMA FAULT (kernel/src/iommu/fault.rs:240), no ACPI server supplied S5 (kernel/src/arch/x86_64/power.rs:141), diskserver's no NVMe controller this row names… (system/diskserver/src/main.rs:606), TSC: (kernel/src/arch/x86_64/hpet.rs:73), and iommu_virtio_platform (tests/common/iommu.rs:38).
  • So do toyos_tsc::stated_hz, the signed-driver design a-machine-without-an-iommu-refuses-every-claim.md:19 owes, and lib/acpi/fixtures/.
• Form. Each file follows issues/README.md's frontmatter, with kind/status pairs it allows. Every owner named exists. Every exit is something a build, a boot or a grep can read. No existing issue is edited.
• Host gate.
  • ToyOSOrg/evidence 479912146 is verified, and its message names d0b5ae1149a4…. ci-host.txt reads EXIT=0 at that head, at load 17.89.
  • ci-host.log ends Host: 76 step(s), all green. Its FAILED lines are the loom mutation models, which are meant to fail.
  • No guest test is reached.

BLOCKER

None.

NOTE

None.

LAND