A cloud server runs eight virtual machines for eight different customers. They share the processor cores, the caches, the memory, the network card and the accelerator. Each customer expects that no other can read their data, change it, slow them down noticeably, or learn anything about what they are doing. Every mechanism in this part has to work at once for that promise to hold.
What does it take to isolate tenants who share one chip?
The obvious answer is that the hypervisor's page tables keep virtual machines apart. They keep processor accesses apart. Devices issue their own requests (lesson 14.3); shared queues and memory bandwidth let one tenant slow another (lesson 14.5); and shared caches and fabrics leak timing information, letting one tenant infer another's activity without ever reading its memory. Isolation is a property of the whole system, layer by layer.
Resource | Threat | Mechanism |
|---|---|---|
Memory, from CPUs | Reading or writing another tenant's memory | Hypervisor-controlled second-stage page tables |
Memory, from devices | DMA into another tenant's memory | IOMMU with per-function tables (lesson 14.3) |
Devices | Sharing one device's registers and queues | Virtual functions: one physical device presents separate functions, each assigned to one tenant |
Bandwidth and queues | Slowing other tenants by volume | Fair arbitration, limits and regulators (lesson 14.5) |
Caches | Evicting another tenant's data; observing its accesses through timing | Cache partitioning; flushing on switches |
Links | Interception between chips | Link encryption and integrity (lesson 14.4) |
Timing channels: if one tenant's accesses change how long another's take (shared cache sets, shared queues, row buffers in DRAM), the second can infer the first's activity.
Partitioning reduces them: separate cache ways or sets, separate queues, fixed bandwidth shares make one tenant's behaviour less visible to another.
At a cost: partitioning leaves capacity idle that sharing would have used. Each system chooses how much interference, and how much observability, to accept.
Mechanism | Example |
|---|---|
Virtual functions | PCI Express SR-IOV: one device presents virtual functions assigned to different virtual machines (fact P35) |
Per-tenant device translation | Arm SMMU, Intel VT-d; PCIe PASID for address spaces within a function (facts A28, P35) |
Cache and bandwidth partitioning | Arm MPAM, Intel RDT (fact A28) |
Link protection | PCIe IDE (fact P35) |
A multi-tenant accelerator (illustrative) gave each tenant its own virtual function and IOMMU tables, but all tenants' work shared one command queue inside the device. A tenant submitting very long jobs delayed every other tenant's jobs by seconds. Per-function queues with a time-sliced scheduler inside the device restored predictable service: isolation must extend inside shared devices, not stop at their boundary.
One tenant can delay the other's jobs: performance isolation is missing inside the device.
It stops one tenant's accesses from evicting the other's lines, which removes a timing channel that reveals activity.
Isolating tenants means isolating every shared resource, not only processor memory accesses.
Identities (virtual functions, stream IDs) key IOMMU tables, queues, regulators and partitions.
Partitioning reduces interference and timing leakage at the cost of idle capacity; decide how much of each is acceptable.