LAB / QEMU
QEMU in your browser
A real QEMU, compiled to WebAssembly, boots a small Linux guest inside this page and
gives you a shell. Nothing is installed. Pick the x86,
Arm or RISC-V machine; in each, dmakit list and
dmakit run program its IOMMU by hand with what dmakit's model produced.
dmakit run edu --pages=3 --fault=unmapped does it with your own options
(--pages, --iova, --fault, and on x86
--range for a row of AMD Table 3, --levels for 3 to 6 host
table levels and --guest for 4 or 5 guest table levels with a PASID), the
same words in all three (or the "Run dmakit with options" fields in the exercises
panel): the page builds the run from dmakit's model of that machine's IOMMU and checks
the real QEMU against it.
Each lab downloads about 40 to 55 MB and needs a
browser with WebAssembly Memory64: it is tested in Playwright's Chromium (Chrome and
Edge share its engine); Firefox has Memory64 but is untested, and Safari had not shipped
it when this was written.
Each guest has a network that runs inside this page, with nothing to start on your
computer: curl and apk reach the web through your browser's
own fetch, so they get what a page may read (this site, and sites that allow
other sites to read them, such as jsDelivr) and no more. There is no ssh,
ping or other raw connection: a browser opens none. Alpine's own mirrors
allow no other site, so apk add installs from a mirror of a chosen
set of packages on this site (python3, gcc, git,
pciutils and more; others fail to download; the big ones may not fit in the
Arm and RISC-V guests' 256 and 384 MB of RAM). What the guest fetches does
leave your machine, as any page's requests do, and it can reach a service on your own
machine or network that allows other sites to read it. For HTTPS the page's network
program signs each connection with a certificate it makes anew every time the lab
starts, which only the guest trusts.
What claims does this page make? 3 points
- Teaching model: the x86 browser build is upstream QEMU compiled to WebAssembly (wasm64, JIT) with the AMD IOMMU patch, booting a busybox shell; see the IOMMU lab.
-
Checked: the Arm and RISC-V browser labs'
dmakit run eduoutput matches dmakit's model, as their native checks do. - The launch buttons turn on only when the browser bundle can be reached.
-
x86-64
Checking the browser build…
The
q35machine with an AMD IOMMU and theedutest device, plus a busybox shell. Once it is open, its DOOM link opens a second page whose Start runs the game on the GPU build (about 67 MB more, WebGL 2), its frames passing the IOMMU. -
Arm (AArch64)
Checking the browser build…
The
virtmachine with an Arm SMMUv3, itsdmakit run educhecked natively against dmakit's model (the SMMUv3 chapter explains it). -
RISC-V (riscv64)
Checking the browser build…
The
virtmachine with the RISC-V IOMMU, itsdmakit run educhecked natively against dmakit's model (the RISC-V IOMMU chapter explains it).
DMA replay on three systems
Capture edu's DMA in the x86-64 terminal above (its Capture the DMA panel downloads the trace), then replay it here on the AMD IOMMU, the Arm SMMUv3 and the RISC-V IOMMU models, or replay the sample. The models agree when they end with the same memory and report the same faults; the replay maps every page it sees and adds three faults of its own, so a fault in the capture itself replays as an ordinary DMA. The digest is a short FNV hash of the replay's memory, not the frame checksum in the Doom write-up. The Doom sample also runs on real QEMU Arm and RISC-V in the project's native checks.
Pick the sample or a capture.
| Model | DMAs | Faults | Wrong | Memory digest |
|---|