How to Abstract Hardware Accelerator
At the 2017 Xen Developer Summit I presented on abstracting hardware acceleration devices in cloud environments — covering accelerators in general, then drilling into what virtualization and multi-tenancy actually demand from the hardware and driver stack.
The slide deck is the real content here. The original Xen Summit link is long dead so the PDF is embedded directly below.
Slides
Context
Xen’s main audience in 2017 was still x86 server virtualisation for data centres, but there was a visible pull from embedded and ARM — people reaching for a Type 1 hypervisor not for cloud density but for isolation guarantees.
From a systems perspective Xen is also a platform, and as cloud adoption accelerated, the mindset was shifting from “buy better hardware” to “rent the right instance type.” I grew up in an era when every server had a name and its own personality, so the shift felt like a loss — but the flexibility argument is hard to argue with.
The practical thread through the talk was Intel QuickAssist Technology (QAT) and what it took to make it work properly in a virtualised environment: SR-IOV assignment, QoS under shared throughput, and the places where the existing abstractions just did not fit.
Two things that hold up from the key notes:
- Werner Vogels’ AWS Summit that year was an early public signal of where instance specialisation was heading — custom NIC, SSD, and FPGA instance types were already on the menu. That trend only accelerated.
- Hardware accelerator QoS is still an unsolved problem. Throughput variance depending on algorithm, workload mix, and hardware design makes SLA guarantees genuinely hard. Not much has changed.