Repository navigation
Conversation
The interactive AArch64 machine enabled SMMUv3 without an ITS, so NVMe, network and sound claims were refused before their drivers could start. Use QEMU's emulated GICv3 with its ITS under HVF. That exposes a second defect: the placement survey omitted MCFG windows. Firmware's free MMIO includes configuration space, so all eight attempted BAR addresses could land in ECAM instead of PCI memory. Exclude the ECAM ranges enumerated by the PCI layer, with the same saturated endpoint form used for other decoded extents. A shipping ARM image with the old machine reproduces refused claims. Adding ITS alone arms LPIs but exhausts BAR placement in configuration space. With both changes, NVMe initializes and the NIC acquires DHCP; the sound function is claimed. Keyboard and mouse delivery remain absent, and the compositor still exits at its keyboard endowment. Record that remaining ARM desktop defect without weakening isolation. Extend the existing virt_low_ecam guest to reject an allocator free run overlapping its actual MCFG window. This needs the live kernel's assembly of firmware and PCI extents; the pure allocator excludes what it is given. Removing both production changes builds and fails that check, exit 1; restoring them passes, exit 0. virt_smmu and x86 bar_map_again also pass. The ARM shipping image builds, exit 0. No timing or audio-quality claim.
Collaborator
Author
|
Complete ARM claim evidence, part 1 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 2 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 3 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 4 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 5 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 6 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 7 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 8 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 9 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 10 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 11 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 12 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 13 of 14. Each file begins with |
Collaborator
Author
|
Complete ARM claim evidence, part 14 of 14. Each file begins with |
Collaborator
Author
|
Design review: #869 at Net lines ( BLOCKER
NOTE
DESIGN NEEDS CHANGES: (1) turn off the in-kernel GIC under HVF alone, chosen per accelerator in one declaration that |
Collaborator
Author
Revised design for #869 — acceptance requested, no rebuild yetThe review of Design
RoastThis is larger than the original patch because the original premise was false. Putting exclusions only in the kernel fixes one reader and leaves another reader holding a false declaration. Putting discovery in acpiserver would keep AML solely in userland, but PCI claims and DMA isolation currently need the declaration before the supervisor can endow those programs; introducing a privileged late aperture update and changing startup order is a separate architecture change. The loader already owns firmware discovery and can reuse the same pure interpreter without teaching the kernel AML. The cost is another bounded AML evaluation during boot, loader image growth, temporary heap and a dedicated stack. A data-only boundary can refuse a real machine whose root resources require register access; that remains an explicit boot/claim limitation, never a reason to restore guessed apertures. The shipped x86 machine must remain usable; a refusal found there blocks this design's implementation from landing and must be resolved through review. HVF loses its hardware vGIC for shapes requiring an ITS and pays userspace interrupt handling. No speed claim is made. That cost is preferable to admitting DMA-capable drivers without interrupt isolation; CPU execution still uses HVF. KVM retains its hardware controller because GICv3 with Verification before landing
Sources: ACPI 6.5, QEMU virt controller selection, QEMU ARM ACPI declarations, EDK2 GCD construction, EDK2 Configuration implementation. This is a revised proposal, not an accepted design or a tested implementation. Existing evidence belongs to |
Collaborator
Author
|
Design review: #869, second round. Reviewed: the revised design in comment 6120354174. Branch head unchanged: Earlier BLOCKERs (comment 6120042162)
Net lines at the head are unchanged: +56 −2 in all. Production is +9 −1, tests +17 −1, and the issue file +30. The design deletes BLOCKER
NOTE
DESIGN NEEDS CHANGES: (1) before acceptance, measure with M1's harness:
(2) put the loader as AML's second home to the owner, with his bound on the loader and the loader's update path named, or move the evaluation out of the loader; (3) specify the boundary per address space and memory type, as one declaration shared with #875's S2, including how |
Collaborator
Author
|
Owner's ruling, recorded by the orchestrator. He was shown the second design review (#869 (comment)). That covered his earlier bound that the loader does only what must precede the hand-over; that the loader's copy of the interpreter is never updated on installed machines; that M1 measured the data-only boundary refusing both x86 benches' tables; and that a refused declaration fails open for the IOMMU. Asked where PCI aperture discovery should live, he ruled not the loader:
|
Collaborator
Author
|
Review: #869 at Net lines ( Earlier BLOCKERsRound 1 (comment 6120042162):
Round 2 (comment 6120666200):
BLOCKER
NOTE
SEND BACK |
Collaborator
Author
|
Closed on the owner's ruling, to be redone as two PRs on today's main, as the review (#869 (comment)) recommends. One sets the ITS choice for HVF alone. The other places device windows on #875's root walk. This PR's boot logs and findings stay here as evidence. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Blocked by design review. The code at
6fb2ba893is not ready to land.Revised design for #869 — acceptance requested, no rebuild yet
The review of
6fb2ba893is correct: the accelerator choice is too broad, and reserving only served ECAM windows does not make the loader's aperture declaration true. The captured boot also labels flash at0x04000000..0x08000000as root-bridge memory. Subtracting two known QEMU ranges would leave the premise wrong.Design
Put the ARM GIC/ITS choice beside
Arch::cpu(accel), in one declaration read by the interactive launcher and guest harness. A shape requiring remapped PCI interrupts uses GICv3/ITS. Under HVF alone it selects QEMU's userspace GIC withkernel-irqchip=off; KVM keeps its in-kernel GIC, and TCG uses its emulated GIC. Shapes that do not request that facility retain their declared controller. This makes the interactive SMMUv3 machine andVirtSmmuagree without changing the EL2 profiles into HVF guests.Replace the GCD-to-aperture shortcut at the loader handoff with the root bridges' positive ACPI resource declarations. Reuse the existing bounded,
no_stdtoyos-amlinterpreter to load the DSDT and SSDTs, identify enabled PCI roots by their standard IDs and segment/bus declarations, and evaluate their_CRS. No fixed namespace path, emulator address, devicetree, or second AML implementation. Add a data-only evaluation boundary: hardware access and side effects are refused by name; a declaration that needs them supplies no aperture. The loader uses a dedicated stack satisfying the interpreter's existing stack contract, and frees the interpreter and its stack before ExitBootServices.Decode the root resource buffers in
toyos-acpi, including Word, DWord and QWord address descriptors. Keep memory forwarding windows and translated I/O windows distinct, compute CPU extents with checked arithmetic, and refuse unsupported translation forms, malformed lists or insufficient output room as a whole declaration. Subtract physical PCI I/O windows and every raw MCFG allocation from the memory apertures before fillingKernelArgs::root_bridge_windows. Reservation decoding must preserve valid extents regardless of segment number or the kernel's mapping grain; it must not use the segment-zero enumeration iterator as its oracle. A malformed reservation declaration prevents admission of the affected aperture rather than silently omitting an exclusion. Every 2 MiB BAR cut must fit wholly in the resulting memory aperture.Delete the GCD aperture producer and the production kernel exclusion added by this branch; the truthful loader handoff is shared by placement and IOMMU initialization. The UEFI Configuration path is not a replacement for full apertures: its allocated ranges can be smaller than the bridge decodes. Do not retain it as a fallback. Keep the input failure in the ARM track's existing record; remove this branch's duplicate issue instead of retaining the incorrectly dated file. Input ownership remains the separate design in Design: one userland input owner for the ARM desktop #868.
Roast
This is larger than the original patch because the original premise was false. Putting exclusions only in the kernel fixes one reader and leaves another reader holding a false declaration. Putting discovery in acpiserver would keep AML solely in userland, but PCI claims and DMA isolation currently need the declaration before the supervisor can endow those programs; introducing a privileged late aperture update and changing startup order is a separate architecture change. The loader already owns firmware discovery and can reuse the same pure interpreter without teaching the kernel AML.
The cost is another bounded AML evaluation during boot, loader image growth, temporary heap and a dedicated stack. A data-only boundary can refuse a real machine whose root resources require register access; that remains an explicit boot/claim limitation, never a reason to restore guessed apertures. The shipped x86 machine must remain usable; a refusal found there blocks this design's implementation from landing and must be resolved through review.
HVF loses its hardware vGIC for shapes requiring an ITS and pays userspace interrupt handling. No speed claim is made. That cost is preferable to admitting DMA-capable drivers without interrupt isolation; CPU execution still uses HVF. KVM retains its hardware controller because GICv3 with
kernel-irqchip=offcannot launch there. TCG already emulates the controller and gets no hardware-quality verdict. A future HVF ITS implementation can remove this launch choice when its actual support is verified.Verification before landing
cargo run -- --ci hostand the complete guest suite for both architectures at the rebuilt head, plus the ARM shipping-image boot. Name and preserve any failure; do not rerun a red away.Sources: ACPI 6.5, QEMU virt controller selection, QEMU ARM ACPI declarations, EDK2 GCD construction, EDK2 Configuration implementation.
This is a revised proposal, not an accepted design or a tested implementation. Existing evidence belongs to
6fb2ba893and does not establish this proposal.Current implementation and historical evidence at 6fb2ba8 (review found blockers)
The interactive ARM boot refused NVMe, network and sound claims because its QEMU machine had SMMUv3 without an ITS. Enabling the emulated GICv3/ITS exposed a second defect: BAR placement could exhaust all eight candidates inside ECAM configuration space. The machine now supplies ITS interrupts, and the placement survey reserves every MCFG window before allocating BAR addresses. A shipping ARM boot initializes NVMe, obtains DHCP and hands the sound function to its server.
The compositor still exits because it has no keyboard or mouse source. That remaining defect is recorded without relaxing isolation; its userland input design is proposed separately in #868.
Design and tradeoff
Use the interrupt remapper the virtual platform actually provides, with QEMU's GIC selected because HVF's GIC exposes no ITS. The launch choice configures QEMU's virtual interrupt controller; the kernel keeps its existing interrupt-remapping contract. Account for ECAM at the survey that already collects occupied memory, BARs and forwarded windows, using the PCI layer's validated MCFG extents. This adds no alternate placement path or wider retry budget. The existing
virt_low_ecamguest checks that its real configuration-space window appears in no allocator free run; a pure allocator test cannot catch an extent its live kernel caller omitted.Validation
Head:
6fb2ba893c15ee41591d83adf29dd91295b11f43.cargo run -- --ci host: exit 0; all 73 host steps green, including the expected failures of the deliberate negative controls.cargo test --test toyos-build -- virt_low_ecam virt_smmu bar_map_again: exit 0; all three guests pass, covering ARM ECAM/isolation and x86 BAR mapping.virt_low_ecamcheck built and failed with the complete final-head production patch reverted onto177e72a9e, exit 1, naming0x10001000..0x40000000as a free run overlapping ECAM. The EXIT trap restored both production files and the tree is clean. The green guest arm above was measured on the same merged base.No timing or audio-quality result is claimed. The firmware-stall issue for the removed
virt_claim_lpitest remains open.Net growth: production +8 lines (9 added, 1 removed), tests +16 (17 added, 1 removed), one 30-line issue recording the remaining input failure.
Complete evidence
All log lines are preserved. Development-user paths and the host's temporary-directory identifier are replaced; ANSI display escapes are removed. The diagnostic harness intentionally expects the unresolved missing-keyboard panic. It uses fresh firmware variables, a blank NVMe disk, a snapshot of the boot image, and captures registers before ending only its own QEMU child.
Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 6 · Part 7 · Part 8 · Part 9 · Part 10 · Part 11 · Part 12 · Part 13 · Part 14
Parts 1–10 hold the full host run and its exit. Part 10 begins the guest run and mutation log; part 11 finishes the mutation log, gives its exit and complete patch, and starts the original-machine boot. Parts 11–12 hold that boot; parts 12–13 hold ITS without the ECAM fix; parts 13–14 hold ITS with the fix. Part 14 also includes the image build, exact QEMU commands, diagnostic results and complete boot harness.