Repository navigation
A claimed function's message is its claim slot's LPI through the GICv3 ITS, no generic signature carries an x86 vector, and the kernel copies and reports through no user leaf of a device's registers - #846
Conversation
…3 ITS, and no generic signature carries an x86 vector AArch64 gains the ITS (kernel/src/arch/aarch64/irqchip/its.rs), brought up from the MADT on the boot CPU's redistributor with toyos-its's encodings: the LPI configuration and pending tables, a flat device table of 2^16 DeviceIDs, the collection table, one command queue, and collection 0 on the boot CPU. A claim maps its function's DeviceID, which the IORT gives behind the SMMUv3, to a translation table of its own whose one event is its slot's LPI (MAPD, MAPTI, SYNC); a release discards and unmaps it. A DeviceID another claim holds, one past the table, or a function the IORT gives no DeviceID behind the unit is refused by name. A driver in this kernel is given no LPI. QEMU's SMMUv3 translates a function's MSI as any write it makes, measured: without a mapping, edu's first message is a DMA FAULT at 0x8090040, F_TRANSLATION, and the claim answers Io. So every domain maps the doorbell's 4 KiB page at its own address, as toyos-smmu's Leaf::Doorbell plans it. irq() holds the preempt count across every device arm, as x86-64's device_irq_entry does: the claim's arm posts a watch, whose release at depth zero would run a scheduler pass inside the handler before its end of interrupt. pcidev::isr asserts the count is raised. The seam: iommu::claim_msi takes no vector and may refuse; the kernel drivers' arming names an arch::DriverIrq, and the architecture makes its message (x86-64: the compatibility format with no unit, a remapping entry with one). VECTORS moves into idt/user_dev.rs, MSG_DEST into apic.rs, the pin's remapping into ioapic.rs, and each architecture states its own refusals. arch::msi_message, iommu::Delivery, PinRedirect, remap_pin and the SMMU's interrupt stub are deleted. virt_claim_lpi boots virt under HVF with its=on,kernel-irqchip=off (HVF's own GIC refuses an ITS), the SMMUv3 and QEMU's edu, on one CPU, and the suite's claim_lpi job reads 16 messages as 16 interrupts of its claim. Closes issues/msi-and-pin-routing-take-an-x86-vector-and-apic-id.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
|
M1: six HVF virt tests on QEMU's emulated GIC with the ITS, the harness patched, main's kernel (f72d53d), part 1 of 1 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 1 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 2 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 3 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 4 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 5 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 6 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 7 of 8 |
|
Gate: cargo run -- --ci host at 2c744d4, EXIT=0, part 8 of 8 |
|
Gate: cargo test --test toyos-build (the default guest suite, x86-64 under TCG and virt under HVF) at 2c744d4, EXIT=0, part 1 of 1 |
|
Gate: cargo run -- --build-only at 2c744d4, EXIT=0, part 1 of 1 |
|
Gate: cargo run -- --build-only --arch aarch64 at 2c744d4, EXIT=0, part 1 of 1 |
|
Negative control: the change's production half reverted onto f72d53d, virt_claim_lpi kept, EXIT=1, part 1 of 2 |
|
Negative control: the change's production half reverted onto f72d53d, virt_claim_lpi kept, EXIT=1, part 2 of 2 |
|
Mutation irq-no-preempt-count at 2c744d4, virt_claim_lpi, EXIT=1, part 1 of 1 |
|
Mutation no-doorbell-leaf at 2c744d4, virt_claim_lpi, EXIT=1, part 1 of 1 |
|
Mutation wrong-slot-lpi at 2c744d4, virt_claim_lpi, EXIT=1, part 1 of 1 |
|
Mutation wrong-event at 2c744d4, virt_claim_lpi, EXIT=1, part 1 of 1 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 1 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 2 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 3 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 4 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 5 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 6 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 7 of 8 |
|
Earlier host run at d719cc9d4 (the same tree but issues/), EXIT=1 on the toyos SDK's lane proof, filed as issues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.md, part 8 of 8 |
|
Review of #846 at 2c744d4, round 1, against Lines: The x86 question (KVM run, T14 reading): neither is owed. Every value the x86 diff moves is the same at this head as on main: BLOCKER
NOTE
SEND BACK |
… tables outlive a late refusal; a claim's DeviceID is the SMMUv3's own route Review round 1 of #846. AArch64 paging: `AddressSpace::walk`, and so `translate` and `leaf`, and `read_user_word` answer nothing for a user leaf of Device type. A claimed function's BAR is mapped into its holder that way, and the kernel reached it through the direct map for a syscall's copy and for the crash report's backtrace and memory dump. `map_window_if_absent` asks the tables for presence directly, since a translation now refuses a leaf that is present. Closes issues/an-aarch64-crash-report-reads-through-any-user-leaf.md; its rule moves to paging.rs's module header. ITS bring-up: a failure found after the redistributor's EnableLPIs panics, rather than dropping pages GICR_PROPBASER and GICR_PENDBASER still name. GITS_CBASER, GICR_PROPBASER and GICR_PENDBASER are each read back whole (PENDBASER without its write-only PTZ, now `toyos_its::lpi::PENDBASER_PTZ`) and refused on a mismatch. A claim's DeviceID comes from the SMMUv3's routes, which now carry the ITS mapping of each routed stream, instead of a second read of the IORT: a function the unit would not put on a domain is refused before `attach`. Measured on QEMU 11.1.1: a function behind a plain pcie-root-port is routed through the unit; one behind a root port of a pxb-pcie with bypass_iommu=on is `Untranslated`. `virt_claim_lpi`'s machine gains such an e1000e; `claim_unrouted` is refused it and claims edu after, and `claim_bar_fault` faults twice in edu's BAR and names it as a read's and a write's buffer. Issues: the storm issue names each architecture's slot interrupt; the ARM track says what stops a released function's doorbell write and what test is owed for the ITS half. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
|
Mutation m2-backtrace-reads-device (patch as posted for b26a9cd): virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation m3-walk-answers-device (patch as posted for b26a9cd): virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation m4-any-route-a-deviceid (patch as posted for b26a9cd): virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation patch r1-irq-no-preempt-count, part 1 of 1 |
|
Mutation r1-irq-no-preempt-count: virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation patch r1-no-doorbell-leaf, part 1 of 1 |
|
Mutation r1-no-doorbell-leaf: virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation patch r1-wrong-slot-lpi, part 1 of 1 |
|
Mutation r1-wrong-slot-lpi: virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Mutation patch r1-wrong-event, part 1 of 1 |
|
Mutation r1-wrong-event: virt_claim_lpi at 0de25fd, EXIT=1, part 1 of 1 |
|
Review of #846 at 0de25fd, round 2, against Earlier BLOCKERs
Earlier NOTEs: all closed.
Evidence at 0de25fd: Lines: BLOCKER NOTE LAND |
Keeps both sides of #846's VirtIts and virt_claim_lpi beside this branch's VirtLowEcam and virt_low_ecam in tests/common/qemu.rs and tests/toyos.rs. The merge also returns issues/the-loader-does-only-what-must-precede-the-handover.md to main's text: a pull request edits only the issue it takes up. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
…unit goes through the dispatch #846 named VT-d's interrupt unit `message_unit` beside `pub use vtd as iommu_unit`. This branch makes `iommu_unit` the dispatch between VT-d and AMD-Vi, so `message_unit` is now `iommu_unit::interrupt`: the dispatch stays the one place that says which backend serves the machine. On an AMD-Vi machine VT-d holds no unit, so `is_armed` is false, `remapping` is `NotRemapped` and a driver's message is the compatibility one, as before. The module doc of tests/common/iommu.rs keeps both sides' sentences. The branch no longer edits issues/a-counters-read-under-host-load-can-go-silent-for-15-s.md: it takes none of that issue up, and the red it recorded stays in the pull request's checks table. issues/an-amd-vi-machine-isolates-no-device.md names its holder, the AMD laptop track's stages 5 and 6, and is assigned. The --ci host abort at d242c7f is filed as issues/the-host-gate-aborts-with-no-message-when-a-destructor-panics-during-unwinding.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
…c::narrow_destination's #846 moved MSG_DEST to apic.rs, made msi_message take only a vector and shift MSG_DEST unbounded, and brought back the I/O APIC's `>= 0xFF`. The resolution folds both onto narrow_destination: the I/O APIC's direct entry narrows through it, and MSG_DEST's eight bits are a const that fails the build where narrow_destination refuses it, which msi_message shifts. VT-d's const assert of the same fact goes, since that const states it. The review's rule that a branch edits no issue it does not take up drops this branch's hunk in x2apic-is-enabled-without-reading-firmwares-opt-out.md. The untested `x2apic &&` term in vtd::remappable moves to an issue of its own, and the xAPIC ICR's unpolled Delivery Status, which the laptop's log does not reach, gets one with the laptop's shootdown line as its exit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
#846, #843, #849, #850, #840, #839, #837) into the batch: the icons' and wallpaper's digests hash with toyos-sha2-hw, and the loader's wall clock reads through its own UEFI bindings The batch's merge of main at f72d53d moved #813's wallpaper and #814's icon digest tests onto `toyos_sha2`. #833, already on main, had replaced the root package's `toyos-sha2` dependency with `toyos-sha2-hw`, so CI's merge of the two compiled no `toyos-build` lib test and both the build system's tests and clippy went red with E0432. Both tests now hash through `toyos_sha2_hw`, as every other SHA-256 the build takes does. #842's `bootloader/src/wallclock.rs` was written on the `uefi` crate, which #815 removes; it now calls `efi`'s `RuntimeServices::get_time`, whose `Time` fields are plain and whose error is the `Status` itself. `start_kernel` takes main's `wall_clock` and the batch's `SystemTable`; the batch's `armed_at` goes, as main replaced it with `wallclock::now`. Cargo.lock takes main's `ntapi`; `nonempty` goes with `gix`, which the batch removed and which was its only user (`cargo metadata --offline`). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C
Stage G3 of the ARM desktop, on
issues/toyos-runs-on-arm64.md's stage 6: the GICv3 ITS, LPIs, a claimed PCI function's message on AArch64, and the device arm ofirq(). It builds on G1'stoyos-itsandtoyos-acpiIORT decode and G2's SMMUv3 (#825). Round 2 also closesissues/an-aarch64-crash-report-reads-through-any-user-leaf.md, which this stage made live.Measured first
virtmachinegic-version=3,its=on,kernel-irqchip=offand main's kernel,virt_smmu,virt_irq_storm,virt_timer_preempts,virt_failed_ap_leaves_no_hole,virt_user_modeandvirt_random_differspassed, EXIT=0: part 1. Its cost against HVF's own GIC is not measured.iommu: DMA FAULT owner=slot0 unit0 stream=00:03.0 addr=0x0000000008090040 access=write ... F_TRANSLATIONand the claim answeredIo. Theno-doorbell-leafmutation below reproduces it at this head.virt_claim_lpi).GITS_BASER0reads itsTypeandEntry_Sizeback with a 64 KiB page; the ITS is id 0 at0x8080000, its doorbell at0x8090040.2c744d434with the machine changed). Apci-testdevbehind a plainpcie-root-portenumerates at01:00.0, and the unit is armed with all 6 functions' streams: a function on bus 1 is routed through the unit like any other, EXIT=0, part 1. Ane1000ebehind a root port of apxb-pciewithbypass_iommu=onenumerates at09:00.0and isIOMMU: 09:00.0 is not routed through the SMMUv3: Untranslated(ItsDevice { its: 0, device: 2304 }), EXIT=0, part 1. So round 1's body was wrong to say the refusal "covers bus 1 and up onvirt". The test below uses the bypasspxb-pcie.What changed, by decision
The ITS (
kernel/src/arch/aarch64/irqchip/its.rs, new).irqchip::initcollects the MADT's ITS entries and brings the one ITS up after the boot CPU's redistributor. The order:GITS_BASERasks for one, and a one-page command queue.EnableLPIs, so noINVis owed.MAPCcollection 0 to the boot CPU.Each
GITS_BASER,GITS_CBASER,GICR_PROPBASERandGICR_PENDBASERwrite is read back whole.PENDBASERis compared withoutPTZ, which is write-only (toyos_its::lpi::PENDBASER_PTZ). A mismatch, or any other refusal beforeEnableLPIs, leaves the ITS disabled and every claim refused (NotRemapped). FromEnableLPIson, a refusal panics: the redistributor may use the LPI tables for the machine's life, and whetherEnableLPIscan be cleared again is IMPLEMENTATION DEFINED, so their pages are never given back. A command the ITS stalls on, or does not consume within a second, also panics: it is a kernel defect. Two ITSs, or none, are refused by name.A claim's message.
claimtakes the function's DeviceID from the SMMUv3's own routes (smmu::its_device). Each route now carries the ITS mapping the IORT gives its stream, from the same read thatdomain::attachtakes the StreamID from, so the claim andattachcannot disagree. A function the unit does not route is refused before its claim reachesattach. The claim then maps the slot's own translation table to the DeviceID (MAPD) and its one event, 0, to the slot's LPI, 8192 + slot (MAPTI), andSYNCs. The message isGITS_TRANSLATER's address and event 0. A releaseDISCARDs the event and unmaps the DeviceID. Refused by name:The doorbell page in every domain (
smmu/domain.rs). Each domain maps the 4 KiB page that holdsGITS_TRANSLATERat its own address, withtoyos-smmu'sLeaf::Doorbell, asserted below the addresses a domain hands out. A 2 MiB block there would hand the device the distributor and the redistributors.A user leaf of a device's registers is no address the kernel copies or reports through (
arch/aarch64/paging.rs; closes the crash-report issue).AddressSpace::walk, and through ittranslateandleaf, answers nothing for a Device leaf, and nor doesread_user_word. Before, a claim holder could put a syscall's buffer or itsx29in its BAR. The kernel then reached the BAR through the direct map, which holds that window as Device-nGnRE becausepcidev's placement probe mapped it. That read and wrote the device's registers, and amemcpypair access there is one HVF cannot emulate, so the whole machine dies (below). Soread(fd, bar, n)andwrite(fd, bar, n)now answerBadAddress, and the crash report's backtrace and memory dump stop at the BAR.map_window_if_absentasks the tables for presence directly, since a translation now refuses a leaf that is present. The issue's rule moves to the module header.irq()holds the preempt count across every device arm, as x86-64'sdevice_irq_entrydoes. The kick, the IOMMU's event SPI, the claim slots' LPIs and an unclaimed interrupt now share one bracket, and the end of interrupt follows it. This is the first of the two remedies the track records as owed before the claim's arm.pcidev::israsserts that the count is raised, and that assertion is what makes the obligation fail a test (below).No generic signature carries an x86 vector or APIC id (the exit of
issues/msi-and-pin-routing-take-an-x86-vector-and-apic-id.md, deleted here):iommu::claim_msi(remapping, slot, function)takes no vector and returnsResult. The architecture'smessage_unitclaims, releases and states its ownRefused:vtd::interrupton x86-64,irqchip::itson AArch64.arch::DriverIrq(PciDevice::enable_msix,enable_msi), andiommu::driver_msiasks the architecture for its message.pcidev::VECTORSintoidt/user_dev.rs, built from the IDT's ownUserDevrows;MSG_DESTintoapic.rs;XHCI_VECTORout of the generic xHCI driver intoidt;ioapic.rs.arch::msi_messageon both architectures (x86-64's becomesapic's private compatibility encoder),iommu::Delivery,PinRedirect,remap_pin, and the SMMU'sinterruptstub.handed over on slot N, vector 0x28,took its first message on vector 0x28,xHCI: ... enabled (vector 0x21).Past the row's fence, each forced by the brief's deletion of the generic
vector: u8, by the doorbell the measurement showed, or by a review finding:arch/x86_64/{apic,ioapic,pio,mod}.rs,vtd/interrupt.rsandidt/mod.rsfollow the signatures above.drivers/xhci/names its interrupt by the arch type.smmu/domain.rsmaps the doorbell.smmu/mod.rsloses its interrupt stub, and its routes carry the ITS mapping.toyos-itsgainsPENDBASER_PTZ.kernel/Cargo.tomltakestoyos-its, the in-tree G1 crate. Nothing new is fetched.Issues.
issues/a-claimed-function-can-storm-its-cpu.mdnames each architecture's slot interrupt and its lever, now thatpcidev::VECTORSis gone.smmu/domain.rshas no detach).smmu-selftestarm that has aniommu-testdevwrite event 0 toGITS_TRANSLATERafter its DeviceID is unmapped, and is red if the slot's LPI is raised.Not done:
MAX_FUNCTIONSstays 4. The plan lists 8 among the gate's seam changes. The desktop needs six claims, and nothing in G3 does.The checks of this high-risk code
Interrupt delivery to a claim is an isolation boundary and a concurrency primitive. The kernel's copies through a user mapping are the user/kernel boundary.
The guest test.
virt_claim_lpibootsvirtunder HVF on one CPU,iommu=smmuv3,its=on,kernel-irqchip=off, with QEMU'sedu, and ane1000ebehind a root port of apxb-pciewithbypass_iommu=on. Its case,tests/virtclaimcase, runs three jobs:claim_lpiclaims edu, maps BAR 0 and takes one grant, because QEMU sends an MSI only from a function that masters the bus. It asks for 16 messages and reads each as exactly one interrupt of its claim, with none before or after. The harness holds the kernel's lines to it:0x8080000;claim_unroutedis refused the e1000e (NotSupported) and then claims edu, so the kernel that refused it is still alive and claiming. The harness holds the kernel to the refusal's name:NOT HANDED OVER — no message of its own could be made for it — the IORT gives it no DeviceID at this kernel's ITS behind the SMMUv3.claim_bar_faultworks on edu's DMA source and destination registers (0x80,0x88), which keep what is written to them across claims.read's buffer and as awrite's, and each is refusedBadAddresswith the registers unchanged.framefaults withx29there (an undefined instruction).jumpbranches there, an instruction abort at a BAR mapped never executable. Each ends with the kernel's fault exit, -1.DMA FAULT.Negative control. The change's production half (
kernel/,Cargo.lock,toyos-its/) is reverted onto819b308d4, this head's main, with the tests kept: red, EXIT=1, onNOT HANDED OVER — its interrupts would not be remapped on this machine: patch part 1 part 2, log part 1.Mutations. Each is a checked patch, built, run and restored by
mutate.sh, all at this head (0de25fd5e), onvirt_claim_lpi:m1-paging-revertedpaging.rschange reverted: the negative control of the crash-report fixAssertion failed: (isv), function hvf_handle_exception, file hvf.c, line 2437, and the harness sees the guest go quiet; EXIT=1m2-backtrace-reads-deviceread_user_wordanswers a Device leaf0xbad1c0de00005eed, in edu's BAR, is on the console: a crash report read through it; EXIT=1m3-walk-answers-devicewalkanswers a Device leafm1; EXIT=1m4-any-route-a-deviceidr1-irq-no-preempt-countirq()'s bracket removedpcidev: slot 0's interrupt arrived with the preempt count at zero, a kernel panic; EXIT=1r1-no-doorbell-leafDMA FAULT ... addr=0x0000000008090040 ... F_TRANSLATION, and the job ends 101; EXIT=1r1-wrong-slot-lpiMAPTIto the next slot's LPIr1-wrong-eventWhat the reds say, and what they do not:
m1andm3. I found where they die by runningm3again with a register dump added at the stall (patch part 1, log part 1). The dump itself was refused, because the machine has no QMP socket. QEMU's own assertion is the evidence: the kernel accessed the BAR through the direct map with an instruction whose syndrome HVF cannot emulate. On hardware the same access reads or writes the device's registers.m4. It does not reachattach's panic. The claim maps DeviceID0x900and arms the e1000e's MSI-X, and thenplace_barsrefuses every BAR placement, because no window firmware declares is routed to thepxb-pcie. So the red is the refusal's name, not the panic.EnableLPIspanics and the four base-register read-backs. No test reaches them: QEMU takes every value written. A reader can check them inits.rs'sbring_up.Independent oracle.
toyos-its's, held to the specification's field positions by G1's host tests.its.rscites it atGITS_CTLR.Quiescent(§12.19.4),GITS_BASER's read-only fields (§12.19.1), the ITT alignment (§5.3.10),SYNC(§5.3.15) and the LPI tables (§5.1.1).eduregisters, whose values the kernel cannot produce, are the oracle for whether a crash report read the BAR.Why a QEMU guest test
toyos-its, and what is new here is three emulated devices agreeing with this kernel.The review's findings
claim_bar_fault's two children and itsread; it also coverswrite. Negative controlm1, red.EnableLPIs. Every failure fromEnableLPIson is now anassert!, so noErrdropsmemory.pageswhile the redistributor may still use them.pcie-root-port's function is routed through the unit on QEMU 11.1.1, so it is not refused, and claiming it does not reachattach's panic. Apxb-pciewithbypass_iommu=onis what QEMU routes past the unit, and the test claims an e1000e behind a root port there. The refusal now comes from the unit's own routes, as the review preferred. The review's mutation goes red (m4); why it reds on the name rather than the panic is above.GITS_CBASERandGICR_PENDBASER. Both are read back and refused on a mismatch, and so isGICR_PROPBASER, whole.Gates, at 0de25fd
cargo run -- --ci hostcargo test --test toyos-build, the default suite: 56 tests, x86-64 under TCG (this host has no KVM) andvirtunder HVF,virt_claim_lpiamong themcargo run -- --build-onlycargo run -- --build-only --arch aarch64The same four gates were green at
b26a9cddb, before the merge of1079e854a: host part 1 part 2 part 3 part 4 part 5 part 6 part 7 part 8 part 9, suite part 1, x86-64 build part 1, aarch64 build part 1. So were the first runs of the mutations there:m1part 1,m2part 1,m3part 1,m4part 1.The first round's host run at
d719cc9d4went red, EXIT=1, ontoyos/src/log/proof.rs'sa_lane_gives_its_reader_every_record_in_order_or_counts_it_refused, at a load average of 44 on 14 cores. That is filed asissues/a-lane-reader-counted-one-refusal-fewer-than-its-writer-made.mdand was not re-run: part 1 part 2 part 3 part 4 part 5 part 6 part 7 part 8The merge of main
1079e854a(#822) landed while this round ran. Five conflicts, each resolved by accounting for both sides:drivers/virtio_sound.rs. Main deletes the driver, and this branch had only moved its vector, so it is deleted, and with itDriverIrq's virtio-sound arm on both architectures.Intid::Hda. Main keeps it, and anHDA_VECTORof it, forarch::msi_message, which this branch deletes.idt/mod.rs. Main drops the virtio-sound vector.pcidev::isr. This branch's preempt-count assertion beside main'stookwith the landing time.virtis refused with the kernel's drivers, which the ITS here makes false.After the merge, the harness waits for the claim's last line (
8817182d5).virt_claim_lpiwaited for the ITS'sunmapped from slotline and then read pcidev'sreleased from slotline, which the kernel logs after it. A drain that ended between the two left the harness reading a line that was not there yet. The review's mutation, run at the intermediate head40d4dd4e6, went red on exactly that:the kernel never said "pcidev: PCI 00:03.0 [1234:11e8] released from slot 0", with the line absent from the capture. It now waits for the release line. The logs of that run were overwritten by the rerun at this head and are not posted. After that fix,819b308d4(#844, prompt files only) was merged.2262cb2ce(#842, the AArch64 wall clock) landed after this head. It is not merged here:git merge-tree --write-treeof this head and it exits 0, and it touches no file this branch changes buttests/toyos.rsandtests/common/qemu.rs, at other sites. That merge is not built or run.What I am unsure of
guest / suitecheck runs it. Nor is a T14 run requested. The row's table names one, but the brief named no metal directory, and the claim path on x86-64 changed only in where its vector and destination are named.virtmachine butvirt_claim_lpi's still boots HVF's own GIC.claim_bar_fault's accesses kills the machine underm1andm3is not measured. The crash report's reads in the two fault cases are aligned loads, andm2shows one of them reading the register rather than faulting: the direct map holds the BAR's window as Device-nGnRE. So those two cases go red on the marker, and only a syscall's copy is a candidate for the access HVF cannot emulate.slot_interruptformats a string on AArch64 for the two claim log lines.Lines
git diff --shortstat origin/main...0de25fd5e: 36 files, +1289 −376. Production (kernel/,Cargo.lock,toyos-its/) +810 −289, of which the ITS driver is 466; tests and the harness +416 −1; issues +63 −86.🤖 Generated with Claude Code
https://claude.ai/code/session_017cSFvbD35xJ2kGANVdm23C