Who is this for?
This is an advanced topic for developers who want to understand how Arm CCA Realms interact with I/O devices using VirtIO, bounce buffers, and secure device attach mechanisms.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- Define device attach and distinguish VirtIO paravirtualized attach from secure physical device attach
- Summarize what a Realm is and how RME isolates Realm memory
- Describe how VirtIO enables paravirtualized I/O without full device emulation
- Explain when and why SWIOTLB bounce buffers are used in Realms
- Describe how PCIe‑TDISP and PCIe‑IDE support secure physical device attach and attestation
Prerequisites
Before starting, you will need the following:
Summary
AI-assisted
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication.
Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
You’ll examine how Arm CCA Realms attach to I/O devices through two models: paravirtualized VirtIO and secure physical device attach. First, you’ll learn about Realm isolation with RME, how VirtIO enables mediated device access, and why SWIOTLB bounce buffers are used when devices can’t DMA directly to Realm memory. You’ll also explore how PCIe‑TDISP and PCIe‑IDE provide secure device attach with attestation. Then, you’ll run a pre-built Key Broker demo inside a Realm and use kernel tracing to observe SWIOTLB activity during VirtIO network I/O. By the end, you’ll recognize when data paths rely on bounce buffers and how this relates to the chosen device attach method.
Frequently asked questions
AI-assisted
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication.
Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
Use kernel tracing during the exercise to observe activity indicating SWIOTLB usage while the Key Broker demo generates network I/O through VirtIO. Seeing trace output associated with SWIOTLB during traffic confirms that data is bouncing through DMA-capable buffers.
What should I expect after starting the Key Broker container image?The container runs a pre-built Key Broker demo used in the exercise. After it starts, list network interfaces to confirm connectivity before proceeding to kernel tracing.
When is VirtIO the right choice versus secure physical device attach?VirtIO is the first level of device attach, mediated by the hypervisor with paravirtualized drivers, and is sufficient for many Realm I/O needs. Secure physical device attach using PCIe‑TDISP and PCIe‑IDE applies when hardware-backed isolation and attestation for the device are required.
Why do Realms rely on SWIOTLB bounce buffers for I/O?Bounce buffers are used when a device cannot DMA to the original buffer, including when memory is not accessible to the device or does not meet alignment or contiguity constraints. In Realms, SWIOTLB enables data transfer between Realm-protected memory and devices during VirtIO I/O.
Will I learn to perform attestation of a physically attached device?You’ll learn how PCIe‑TDISP and PCIe‑IDE support secure physical device attach and attestation. The hands-on exercise focuses on VirtIO and observing SWIOTLB behavior, not on performing a physical device attestation workflow.