Speaker
Description
Automotive hardware architectures are consolidating standalone Electronic Control Units (ECUs) into centralized compute platforms. A major challenge in this architecture is safely and efficiently sharing a single GPU across multiple isolated virtual machines. For example, systems must run critical instrument clusters, infotainment setups, and ADAS pipelines simultaneously without risking cross-domain interference.
This presentation tackles this challenge by introducing an architecture that combines libkrun, a process-based KVM virtualization library, with the vhost-user protocol to split device emulation into separate processes. By executing the virtio-gpu backend independently via virglrenderer, this approach achieves fault isolation, zero-copy transfers, and a reduced attack surface compared with traditional Type-1 hypervisors. We have implemented headless GPU compute acceleration, verified using AMD Radeon graphics via virgl, allowing offscreen rendering and ADAS sensor preprocessing. We have also implemented software scanout display output using the gfxstream backend, with DMABUF zero-copy scanout for virglrenderer in progress.
However, productizing this architecture has revealed concrete specification gaps, where the virtio-gpu specification and Linux kernel implementation diverge. During our ongoing implementation of display output paths, such as UPDATE and cursor paths, we encountered some blockers where the written specification and the kernel driver handle headless state and display configurations differently.
This talk focuses on two concrete topics from our implementation experience:
- Spec vs. Kernel Reality on Headless Operation: The Virtio-GPU Spec (v1.4 §5.7.4) requires a minimum of 1 scanout, yet the Linux kernel (virtgpu_kms.c) gracefully accepts and handles 0. We will discuss how to reconcile the specification to natively support headless, compute-only automotive workloads without forcing VMMs to waste resources on dummy display allocations.
- Display Output & Device Infrastructure in libkrun: We will present the two GPU display scanout paths we are implementing: Software scanout via gfxstream (pixel copy in message payload) and DMABUF zero-copy scanout via virglrenderer and also covering their tradeoffs in latency, memory usage, and backend compatibility. We will discuss how implementing GPU display support required adding generic SHMEM region mapping and BACKEND_REQ protocol features to libkrun's vhost-user framework, and how this infrastructure then enabled support for other vhost-user devices like virtio-media (camera/decoder passthrough) with minimal additional effort.
Eventually, we want to engage kernel maintainers, virtio specification editors, and VMM developers to discuss how the specification and its implementation can be improved to build a way forward for automotive virtualized graphics.
Session Timeline & Core Discussion Points (45 Minutes)
- Architecture & Status (10 mins): High-level overview of the libkrun + vhost-user-gpu stack, where it stands relative to Type-1 hypervisors, and a status update on PR #717 (working headless compute vs. pending display paths).
- Spec vs. Kernel: num_scanouts Divergence (20 mins): Open discussion on the conflict where the kernel accepts num_scanouts == 0 while the spec forbids it. Questions: Should the spec be amended to support headless operation? Should the kernel enforce spec compliance? When spec and implementation conflict, which is authoritative? What are the implications for VMM developers and automotive use cases?
- Display Output & Device Infrastructure in libkrun (10 mins): The two GPU scanout paths: Software scanout (gfxstream, full-frame pixel copy) vs DMABUF zero-copy (virglrenderer, FD passing via SCM_RIGHTS), their tradeoffs and current status. How implementing GPU display required adding generic SHMEM region and BACKEND_REQ protocol support to libkrun, which then enabled vhost-user support for virtio-media with minimal additional work.
- Q&A and Upstream Planning (5 mins)