A Linux Bus for SVSM Services: Build New, Reuse VIRTIO, or Both?
summary
Proposal compares three architectures for exposing SVSM services to guests: a new minimalist kernel bus, reusing VIRTIO, or a hybrid. Key specifics: SVSM already hosts TPM plus planned observability and secure console devices, device discovery requires device discovery and enumeration that may clash with host VIRTIO, and drivers need platform-specific transport ops (AMD/Intel/ARM) with choices of callbacks vs static APIs. VIRTIO’s queue model is questionable because SVSM has no async queuing for SVSM; PCI/MMIO emulation forces hypervisor redirects and breaks trust provenance.
AI-written summary · about
chapters (8)
- 0:00Introduction to SVSM bus
- 2:54Current Linux driver limitations
- 6:06Why multiple SVSM devices
- 8:15SVSM bus concept explained
- 10:23Device identification approaches
- 12:49VIRTIO vs custom bus discussion
- 15:01Platform abstraction goals
- 16:27Discovery and DSDT challenges
related talks
36mShared Virtual Addressing for High Performance Arm Infrastructure Platforms
28mVirtio on Type-1 hypervisors
30mVirtio for PCI Endpoint Subsystem in Linux Kernel
23mHyper-V's Virtual Secure Mode in KVM project update
27mWhat's in Virtio 1.2 - And What Isn't There
55mSecure IO BoF
50mLinux Virtualization Based Security (LVBS)
21mVirtio Devices Emulation in SPDK Based on Vfio-User Protocol