The KVM maintainers will present an update of the last 14 months in KVM and the Linux kernel. We will go over new features, the (positive and negative) impact on security of AI code review, and KVM's position in the Linux kernel and the virtualization landscape.

An NVIDIA Grace-Hopper or Grace-Blackwell Superchip is not "a server with a PCI GPU."  It is a CPU+GPU coherent complex: GPU memory is cache-coherent system RAM, the CPU is ARM64, the IOMMU is an SMMUv3, and devices DMA directly to one another.  Making one assignable to a guest reaches into nearly every corner of the virtualization stack. Yet the work arrives upstream not as one headline feature but as dozens of small, self-contained patch series, spread across different lists and maintainers, almost none naming the platform it serves.

This talk reassembles those trees into the forest. Across the kernel, QEMU, and libvirt, we trace how seemingly-isolated series (a vfio-pci variant driver, a KVM/ARM64 cacheability flag, an iommufd virtual IOMMU, an SMMUv3 nesting rework, a dma-buf MMIO exporter) compose into a single capability: hardware-accelerated, coherent GPU passthrough.

Following that thread also reveals a quieter trend: with each generation, from Grace-Hopper to Grace-Blackwell to the next, upstream enablement is arriving earlier in the product cycle.  Taken together, these isolated series are less a scatter of features than a sustained effort to make coherent accelerators first-class citizens of the virtualization stack.

guest_memfd was originally introduced to provide a secure/isolated memory allocator in the kernel through which private memory for confidential VMs could be managed in a way that limits its exposure to other kernel/userspace accesses on the host. In this model, non-private guest memory would be allocated from outside of guest_memfd in the same manner as a non-confidential VM, and guest-requested conversions between private/non-private states would be handled by re-allocating memory from the appropriate allocator.

This has worked well in providing adequate isolation mechanisms for private memory across different confidential compute architectures, but the need to switch between separate memory allocations depending on whether it is private/non-private brings about various complications when considering upcoming features like hugepage support and allowing private memory to be made accessible for secure device passthrough. Additionally, guest_memfd is being increasingly considered as a way to provide additional isolation/features even for non-confidential guests.

This talk will provide an overview of in-place conversion support for guest_memfd, some of the related work around it, and go into more detail on how it addresses future use-cases for guest_memfd.

Building on the upstream NVIDIA vGPU architecture previously presented at KVM Forum, this talk focuses on the next phase of the work: turning the proposed host-side model into an upstreamable driver stack.

We will begin with a concise recap of the vGPU lifecycle and architecture, covering how vGPU instances are discovered, created, configured, assigned to guests, run, and torn down. This recap will re-establish the roles of the core GPU driver, firmware-facing paths, VFIO integration, and userspace without repeating the full introductory material.

The main part of the talk will cover current upstreaming progress. We will discuss the bring-up path for enabling vGPU in the Nova-Core stack, including GSP/FSP interaction, SR-IOV and vGPU mode setup, runtime lifecycle plumbing, resource handling, and VFIO variant driver integration.

We will then describe the new building blocks introduced as the implementation evolved, including NVKV, simplified GSP initialization, Plugin RPC handling, vGPU bootload flow, debug/log plumbing, and guest-memory hygiene support. These pieces are important not only as implementation details, but also as the foundation for making the host stack maintainable and reviewable upstream.

Finally, we will outline the next milestones, remaining integration work, and the areas where feedback from the KVM/VFIO community is most useful.

Session Outline

1. Recap: vGPU Lifecycle

vGPU discovery, type selection, instance creation, assignment, runtime operation, teardown, and reset/recovery.

1. Recap: Host-Side Architecture

The division of responsibilities between Nova-Core, firmware-facing paths, VFIO, and userspace.

1. Current Upstreaming Progress

GSP/FSP enablement, SR-IOV and vGPU mode setup, runtime lifecycle work, resource management, and VFIO variant driver integration.

1. New Building Blocks

NVKV, simplified GSP initialization, Plugin RPC, vGPU bootload flow, debug/log plumbing, and guest-memory hygiene.

1. Roadmap/Next Milestones

Patchset decomposition, review priorities, remaining integration work, and the path toward an upstreamable NVIDIA vGPU host stack.

Audience Takeaways

Attendees will get an update on how NVIDIA vGPU upstreaming has evolved beyond the initial architecture, what parts of the host stack are now taking shape, and which interfaces and implementation areas need community review next.

In-place conversion is the latest core change to guest_memfd (hopefully merged by the time of KVM Forum 2026) [1].

With in-place conversion, the shared/private state of memory can now be toggled (converted) without requiring copying memory contents, and conversion can even be non-destructive. This opens doors for pKVM to maintain high performance from not having to copy back-and-forth (bounce the data).

This change upholds the core purpose of guest_memfd, which is that the host must not be able to access guest private memory.

This talk will give an overview of how in-place conversion works, how the shared/private state is tracked, and some intricacies of conversion that would be good to note if you are developing features for guest_memfd. I'd also like to talk about next steps for guest_memfd and get feedback on how state tracking can be extended to other memory providers [2].

[1] https://lore.kernel.org/all/20260728-gmem-inplace-conversion-v9-0-35f9aec2aed2@google.com/
[2] https://lore.kernel.org/all/CAEvNRgEWOnZqiXMijZqggEi1hm14HxZ++9GpDRXUHqoE4UD6Bg@mail.gmail.com/

Abstract

PCI passthrough works for a lot of accelerators today: bind vfio-pci, map BARs
and MSIs, run the guest driver. CXL Type-2 devices still show up as PCI
functions, but the guest also expects coherent device memory and a few extra
discovery surfaces that stock vfio-pci does not provide.

In short, passing a CXL.mem-capable GPU (or similar Type-2 device) to a VM
needs three things at once: a guest-mappable view of the firmware-committed
coherent memory range, a spec-consistent view of the CXL config and component
registers the guest driver reads at probe, and a guarantee that the guest
cannot reprogram the host's physical HDM mapping. This talk walks through
those three requirements from the guest's point of view, then shows how Linux,
QEMU, and libvirt split the work so the guest sees a normal CXL endpoint
without getting control of the real decoder.

The goal is a cross-layer contracts discussion and open questions about how
resource ownership, assignment, guest memory and ACPI fit together when the
device has memory, not just MMIO. That cuts across KVM, QEMU, VFIO, CXL-Core,
iommufd, firmware, and management tools.

I will build one mental model for the CXL type-2 device passthrough stack:

• Host kernel owns the physical map and register policy.
• QEMU wires guest physical memory and ACPI topology.
• Guest runs its usual driver against shadows and overlays.

Audience takeaways

• Attendees should be able to explain the problem associated with CXL type-2
  device passthrough to someone who only knows PCI passthrough. Why Type-2 is
  not "vfio-pci as today": coherent device memory plus CXL config/component
  surfaces, not just BARs and MSIs.

• The three virtualization requirements: mmapable HDM-backed memory,
  spec-consistent register view, host-protected physical decoder.

• Who provides each piece: cxl-core policy, vfio-pci regions, VMM memory
  layout and overlays.

Out of scope

• CXL Type-3 memory expander product path.
• CXL.cache mediation and switched topologies.
• Nested virt test harness.

VM live migration lives in host userspace and leans on established patterns: dirty page tracking, KVM_GET/SET_* for VM and vCPU state, and copying guest memory straight out of its userspace mapping.

These patterns don't transfer directly to confidential VMs. Hardware-based encryption and isolation put guest memory and CPU state beyond the host's reach by design — the very state that needs to be migrated. To make live migration possible, the standard KVM/QEMU flows must route through technology-specific migration interfaces that expose guest state only in the controlled ways the architecture permits.

This talk presents the status of our in-progress KVM/QEMU changes to support TDX's migration interfaces — augmenting the familiar flow where new steps are required, and adapting it where existing steps cannot function as-is. The result enables live migration of TDX guests.

On x86, live migration across heterogeneous hosts has been a solved problem
for years: named CPU models and fine-grained feature control let a guest
move between machines with different silicon while keeping a stable guest
ABI. On ARM64, none of that exists yet, and QEMU/KVM only offers the
so-called host passthrough vCPU model, which mostly inherits its features
from the host CPU and, with only a few exceptions, cannot be tuned. As a
consequence, migration on ARM can only happen between strictly identical
hosts. As ARM establishes itself in the server and cloud market, this gap
is quickly becoming a blocker for real deployments.

We present a joint Red Hat and Nutanix end-to-end solution built from two
complementary layers. The lower layer leverages the KVM/ARM capability to
write a subset of the vCPU ID registers: ID-register descriptions are
extracted from ARM's machine-readable specification, and a property is
generated for each ID-register field. The upper layer provides hierarchical
named CPU models (for example, grace-v1, neoverse-v2-v1,
arm-v9_0-a-v1) that acts as a strict, forward-compatible migration
contract, using parent/child inheritance to keep the growing model set
maintainable.

This talk mostly addresses the new upper layer. It especially covers QMP
introspection of valid property values and valid vCPU models, which
management tools badly need; several strategies will be presented. We will
also explain the integration challenges with the existing host-passthrough
CPU model: coexistence with the existing legacy composite options, cpreg
values derived from a scratch vCPU that may be a superset of the actual
vCPU model, and option ordering during both introspection and the actual
run. We will also look at how these named models stay forward compatible,
so that a model defined today keeps resolving to the same guest-visible CPU
on future hardware, QEMU, and kernel versions.

A draft libvirt integration will be presented, and the talk will be
illustrated by real heterogeneous migration cases.

For several reasons, Google is interested in running its VMM in a VM without running nested VMs. One way to do this: create a paravirtual device that the L1 kernel can use to provide a near-indentical UAPI as KVM/VFIO, and proxy the UAPI calls to a VMM in L0 that executes them on behalf of the VMM in L1.

We go over the mechanics of proxying the KVM and VFIO UAPI (notably how to handle memory, proxying eventfds, and how to pass through physical devices to sibling VMs), and the mechanics of process separation in L0 for different “L2” VMs.

There are numerous downsides with proxying the KVM and VFIO API directly. For that reason, we explore how the direct UAPI-proxy model can be morphed into a higher-level model.

At Blacksmith we run CI jobs in ephemeral Firecracker microVMs (around 2.5 million per-job volumes created and destroyed a day, peaking at a thousand new VMs a minute), each attached to persistent "sticky disks" that carry build caches between jobs. Our first architecture served these disks the obvious way: a Ceph RBD clone per job, mapped into the host through rbd-nbd with librbd's persistent write log on local NVMe. It worked, but at fleet scale the per-job clone/snapshot/flatten churn dominated our Ceph load, chain depth had to be policed with background flattening, and the kernel NBD path added failure modes we could neither observe nor control well.

This talk covers the design and production experience of our replacement: a per-VM storage proxy running in host userspace, speaking vhost-user-blk to Firecracker's vhost-user block device. The proxy fronts each disk with a local NVMe overlay that absorbs guest writes at local speed and destages settled blocks to Ceph in the background, paced to ship each block at most once.

We will walk through the implementation structure and the design decisions we think generalize beyond our use case:

• how the proxy is built: a sans-io core in Rust (pure state machines producing I/O plans, driven by a single-threaded epoll event loop with no async runtime) and why that style pays off in testability and in reasoning about a storage data path;
• how it talks to everything around it: the vhost-user protocol socket and shared guest memory mappings on the Firecracker side, virtqueue processing for guest I/O, librbd to Ceph, and a control socket through which our host agent orchestrates disk attach and queries commit progress;
• flow control: a bounded dirty budget with time-since-last-write destage ordering, applying backpressure through the virtqueue only under sustained overload;
• building our own minimal backend instead of adopting SPDK, and what that cost/saved us;
• a per-VM proxy process versus a multi-tenant backend inside our host agent: why the per-I/O hot path is identical and address-space isolation decided it;
• reliability without recovery machinery: our CI jobs are non-retryable, so the proxy shares the VM's fate. Instead of building vhost-user reconnection and crash-recovery logic, we invest in making the proxy simple and stable, and let it serve as the authoritative, queryable holder of commit state.

We will close with production results comparing the two architectures: Ceph cluster load, guest-visible write latency, and per-host VM density.

The Microsoft Hypervisor (mshv) driver in Linux enables QEMU to leverage Microsoft’s hypervisor directly on Linux hosts. While initial enablement focused on x86_64, expanding AArch64 support is essential for modern ARM-based enterprise workloads.

In this talk, we present our work bringing full ARM64 support to QEMU's mshv accelerator (currently posted on qemu-devel https://lore.kernel.org/qemu-devel/20260717-mshv_accel_arm64_supp-v5-0-ef07d4c6b337@linux.microsoft.com/). We will detail the MSHV kernel/user space interface on AArch64, covering key execution components such as vCPU setup, register synchronization, GIC interrupt handling, and MMIO emulation. We will also present our live-migration implementation (with the patch series scheduled to be posted ahead of the conference) and share performance benchmarks comparing MSHV against KVM on identical AArch64 hardware.

Talk Outline:

1. Introduction & Architecture
   • Overview of the mshv Linux kernel module and Microsoft Hypervisor partition management on AArch64.
2. QEMU Accelerator Enablement
   • -cpu host configuration.
   • MMIO emulation.
   • Virtual GIC.
3. Live Migration
   • Saving/restoring MSHV specific states.
   • Patch series will be ready before the conference.
4. Performance Benchmark: MSHV vs. KVM
   • Head-to-head performance breakdown on identical ARM64 hardware.
     • virtio device performance (latency, throughput of virtio-blk, virtio-net)
     • save/restore latency
   • Insights into structural performance differences between KVM and MSHV.
5. Upstream Status & Next Steps
   • Current status of the patch series on qemu-devel.

The number of disk IO threads in a QEMU instance is fixed at start time, which is rarely the right choice for the lifetime of a VM. A workload that is idle most of the day but bursts at night, a VM that migrates between hosts of different sizes, or a guest whose disk IO pattern simply changes over time will all pay a price for that static decision: either too few threads, which caps throughput and increases latency, or too many threads, which wastes CPU, inflates the CPU-per-IO cost, and even hurts performance in certain cases.

In this talk we present the io-thread-controller, a daemon that continuously monitors the CPU utilisation of all QEMU processes on a host and dynamically adjusts each VM's disk IO thread count at runtime. The controller is built around a modular decision engine driven by a set of configurable parameters, so users can plug in different policies, for example, optimising for peak per-VM IO performance, for minimum CPU-per-IO across the host, or for a balance between the two, without changing the core service.

We will walk through the architecture of the controller, the QEMU/QMP interactions used to add and remove IO threads safely on a live guest, and the heuristics and signals that drive the decision engine. We will then present benchmark results showing how dynamic thread scaling can either increase VM disk IO performance or reduce CPU consumption per IO, depending on the configured goal, and discuss the trade-offs, pitfalls, and future directions for the project.

An independent guest virtual machine (IGVM) file encapsulates all the information required to start a guest on any virtualisation stack with a deterministic launch measurement. IGVM support in QEMU for the SEV-SNP platform was added by Roy. Gerd added extensive tooling support for IGVM including bundling an OVMF firmware image within it. Ani’s recent work added capability for QEMU SEV-SNP and TDX confidential guests to be reset[1]. Unfortunately, the same IGVM file that was initially used by the guest at start is again used after the guest reset. Therefore, the guest cannot change the launch state using its own IGVM file for deterministic and attestable boot measurements. In KVM Forum 2024, we proposed the idea of “Bring Your Own Firmware” (BYOF) [2] that aims to add capability for confidential guests to specify their initial launch state, including their own firmware for deterministic and trustworthy measurements. BYOF involves a new hypervisor interface that guests can use to load a different IGVM file with the help of the hypervisor. This sets a new launch state and firmware for the guest upon reset. In this talk, we describe how we have incrementally worked towards implementing BYOF on the QEMU/KVM stack. We will give a broad overview of all the different pieces of work. We will describe our current work towards implementing the hypervisor BYOF interface [3] [4] and the proposed patch set that builds on top of the previous work. Finally, we will discuss how IGVM files can be distributed by various OS vendors using UKIs and Ani’s work in this respect.

References:

1. https://www.redhat.com/en/blog/confidential-guest-reset-qemu-hypervisor-design-choices-and-approach
2. https://gitlab.com/qemu-project/kvm-forum/-/raw/main/attachments/2024/BYOF-_KVM_Forum_2024_iWTioIP.pdf
3. v3 patchset: https://lists.gnu.org/archive/html/qemu-devel/2026-07/msg08290.html
4. https://people.redhat.com/~anisinha/vmlaunchupdate
5. https://www.qemu.org/docs/master/system/igvm.html

The virglrenderer library handles the heavy lifting of GPU paravirtualization, while QEMU provides a mature virtualization framework. Although the core functionality is already in place, integrating the two presents unique challenges.

QEMU models computers with diverse configurations, and a GPU is essentially another computer with massive hardware variation. Bringing these two diverse ecosystems together can sometimes lead to surprising consequences—such as accidentally breaking Alpha CPU emulation.

In this talk, I will describe how GPU paravirtualization in QEMU has evolved and the problems that emerged along the way. I will then characterize the common causes of these issues and share key insights.

This talk will cover:

• Interactions among foundational concepts: paravirtualization, direct rendering, and address translation.
• The ecosystem: virtio capability sets, virglrenderer, the macOS Paravirtualized Graphics framework, Rutabaga, and DMA-BUF.
• Pre-existing QEMU components facing new challenges: display backends, guest memory management, and RCU.
• Potential features that may be implemented in the future.

This talk focuses primarily on the intersection of GPU paravirtualization and QEMU, but several insights are useful independently. For example, some takeaways may help improve QEMU's general architecture or benefit GPU paravirtualization in other VMMs.

AWS Nitro Enclaves enable an EC2 instance to spawn an isolated, confidential virtual machine out of its own CPU and memory resources. QEMU has gained support to emulate the Enclave virtual machine target machine and as of version 11.0 is able to launch such an Enclave as the supervising process that manages its lifecycle and limited I/O.

Walk me through a detailed overview of how Nitro Enclaves work and how all its components play together. Then follow me on an outlook of the latest evolution in the technology, how it works and how it interacts with QEMU.

There is a growing class of software that has many of the requirements associated with embedded systems but need the computational clout of a thoroughly modern computer. This class of software poses a significant challenge when simulations are being used to examine the system of which the software is a part; that is, when attempting to simulate the system of systems. Simulation techniques for smaller computer systems are impractical when the target computer is as computationally capable as the computer hosting the simulation.

In this talk, we describe our experience building a simulation virtual machine, the main aim of which is to host unmodified software in a non-real time simulated environment. In particular, we discuss some of the challenges encountered when applying QEMU and KVM to this problem, some of the distinctions between simulation and virtualization that underlay those challenges, and novel solutions to at least some of the problems encountered. These include the problems of time keeping in simulated vs. real time environments and the problems of incorporating a simulated computer system into a federated simulation environment.

In 2019 at KVM Forum, we presented the state of virtio-vsock in QEMU, Firecracker, and Linux. At that time, AF_VSOCK only supported SOCK_STREAM, had no namespace awareness, and reached about 40 Gbps in microbenchmarks. A lot has changed since then.

In this talk, we provide a comprehensive update on the evolution of the vsock subsystem across the Linux kernel, QEMU, rust-vmm, and the broader virtualization ecosystem over the last seven years.

We will cover key kernel features that have landed, including multi-transport support for nested VMs and local communication, network namespace support for containerized VM environments, and performance and API extensions: SOCK_SEQPACKET for record-boundary messaging, MSG_ZEROCOPY for high-throughput send paths, sockmap/BPF integration for programmable kernel redirection, and new socket address flags and IOCTLs (VMADDR_FLAG_TO_HOST, SIOCOUTQ/SIOCINQ, SO_LINGER).

In userspace, we discuss the vhost-user-vsock frontend introduced in QEMU 5.1 and the backend implementation in rust-vmm. We look at how eliminating the kernel vhost module reduces the attack surface while enabling sibling VM communication. Furthermore, we examine how the broader Linux ecosystem, such as systemd, is adopting AF_VSOCK to enhance VM communication.

Finally, we highlight ongoing efforts, including guest-side namespace support and SOCK_DGRAM, concluding with a roadmap of remaining challenges and future directions.

The explosive growth of AI-Agent workloads are leding to severe shortage of CPU resources in cloud computing infrastructure, making CPU overcommit and CPU schedule efficiency much more critical than ever. In this talk, we present two complementary KVM techniques that safely raise CPU overcommit by tackling two kinds of wasted capacity: stranded idle CPU in dedicated VMs, and the per-thread scheduling tax in shared VMs.

1. Reclaiming idle capacity — runtime MONITOR/MWAIT switching. For dedicated VMs using MONITOR/MWAIT passthrough, idle CPU time is invisible to the host. We introduce runtime switching between passthrough and interception, using C0-state residency of pinned physical CPUs as the host-side guest-load signal. Busy guests keep passthrough for native performance; idle guests switch to interception so their stranded capacity becomes reclaimable. To keep wakeups correct after interception, a PageTracker watches writes to MONITOR-armed memory and resumes the vCPU when the guest's wakeup condition fires up, delivering wakeup latency comparable to the classic HLT idle path.
2. Cutting the per-vCPU tax — coroutine vCPUs. For shared VMs, the one-thread-per-vCPU model amplifies wakeup and inter-vCPU switching overhead at high overcommit density. We replace heavy per-vCPU threads with a coroutine-based execution model, reducing vCPU wakeup latency by 1.7 µs and inter-vCPU switch latency by 1.6 µs.

Beyond overcommit scaling, a novel sched_ext-based vCPU scheduler is also introduced to mitigate preemption-induced jitters once host CPUs are fully sold.

The multi-process model is increasingly popular for device backends as it provides many advantages, including an ability to decouple device implementation from the core hypervisor, clear resource partitioning, and a strong security model. Dedicated hardware offloading has also become popular as a way to lower overheads and exits. There are some good standards that have emerged in these areas (e.g. vhost-user, DPDK/SPDK), but building a data plane is still a challenging endeavor. We will discuss our experience building a rust-native framework for PCI-based device offloads, enabling both vfio-user multi-process backends but also DPUs and specialized hardware devices. It incorporates a async runtime to enable a simple programming model while preserving the poll-based, shared nothing architecture that is critical for high-performance I/O backends.

As memory is getting much more expensive nowadays due to AI deployments, we have been looking into how to save RAM without sacrificing VM performance. One way to achieve it is to leverage a tiered memory approach, with the help of relatively cheaper but still fast storages like SSDs or CXL memories.

Since Linux provides very reliable and efficient two-tiered memory hierarchy over tens of years with swap system, one way to achieve it is to leverage Linux kernel's tiering capability. We can also easily achieve per-VM tiering by leveraging functions like memcg. It means QEMU can fully offlload the whole tiering logic to Linux meanwhile benefit from whatever new coming to Linux too (like, MGLRU).
However, since QEMU hypervisor isn't tier-aware, some operations (like live migration) can cause severe performance issues. Some numbers will be shared to demonstrate this issue. We will explore solutions, one of which may involve new system calls introduced to Linux for userspace tier-aware memory accesses.

Another option is to teach QEMU to do the tiering on its own. Linux has APIs to allow either page hotness tracking (e.g. idle page tracking) or page access managements (userfaultfd). With the facilities, QEMU can do full tiering management. However OTOH there will be challenges on duplicated efforts, less efficiency (both userapp and kernel will need to track page hotness, or when resolving page faults), and conflictions (e.g. MGLRU may not yet work with page idle tracking functionality).

We will compare different approaches, comments will be more than welcomed. It is still an open question on how QEMU should implement its tiering functionality.

The last year has been pretty consequential for a lot of FLOSS projects with the rise of the code slopocalypse as well as dramatic up-ticks in security reports generated by Large Language Models (LLMs). The QEMU project has not been immune from these effects as it continues its development journey. In this talk Alex will review the developments of the last year, try and glean wisdom from the data and hopefully include a pretty graph or two.

Over the last few years, KVM Forum featured many presentations about the implementation of both Microsoft VBS and SEV-SNP VMPLs, two technologies to provide virtual machines with a trusted base inside the VM itself. However, neither feature has been merged as of this writing—certainly not in the shapes that were presented. In this talk I will present a new path towards merging VBS support in upstream KVM, show how it can be composed from small parts, and which additional features could be enabled along the way.

VFIO and IOMMUFD enable safe, secure, and performant assignment of peripheral
devices to user-space applications and virtual machines. As the complexity of
device passthrough has evolved, so has the need for a dedicated testing
infrastructure. In this talk, we introduce VFIO selftests, a newly integrated
test suite located in tools/testing/selftests/vfio. We will explore the initial
motivation behind its creation: specifically, the need for standardized, low-
level validation of VFIO and IOMMUFD UAPIs with real devices, real DMA
activity, and real interrupts.

A key feature of VFIO selftests is its built-in driver framework that enables
tests to trigger DMA and interrupts from a range of different devices in a
generic way. We will dive into the architecture of this driver framework and
explore how it simplifies interacting with PCI endpoints, abstracting away
complex setup tasks so developers can focus on testing the kernel, not dealing
with devices.

Finally, we will discuss the interaction between VFIO and KVM selftests. Beyond
testing VFIO in isolation, the entirety of the VFIO selftests routines are
packaged into a reusable library: libvfio. While KVM selftests already provide
a comprehensive environment for testing KVM behavior, testing KVM and VFIO
interactions (e.g. irqbypass) has historically been challenging. By linking
against libvfio, KVM selftests can easily use all the low-level VFIO setup
routines and the driver framework itself.

We would like to discuss various design choices in the context of Virtual Secure Mode on KVM Planes. Virtual Secure Mode has been implemented in Microsoft Windows originally. In light of the rising
popularity of Linux and in order to improve the security of workloads on Linux, especially in the context of code integrity and confidentiality which has become more important in the current age of
AI, we see value in VSM on KVM Planes.

VM Planes on KVM provides isolated memory areas with adequate protection, which is part of Host Virtualization, we also need to design the interaction from the perspective of the Guest OS, in QEMU
and other Virtual Machine Monitors. The orchestration of the tenants within these memory areas and related performance is critical while upholding security guarantees. We would like to discuss the challenges in implementing Linux and Windows with VSM as guests on KVM.

Some concepts from VSM have been adopted in the recent advancements made in confidential computing hardware such as AMD SEV-SNP, Intel TDX and ARM CCA. We would also like to discuss how we can implement a generic function switch to hide the implementation details from consumers of the technology such that virtualization-based security can work regardless of the underlying implementing technology. We are planning to discuss this with the community at the Linux Plumbers Conference 2026.

VFIO selftests enable testing of device virtualization features like DMA and interrupt generation. Unfortunately, users can't run these tests without a supported DMA device. To enable hardware-agnostic testing, we introduced a new driver into VFIO's selftest driver framework for the Intel 82576 (igb) network controller, which is emulated in QEMU.

This talk will cover the challenges in repurposing a network controller into a DMA engine, and some changes we made to QEMU's emulation of IGB to support testing for the Live Update feature in the kernel.

COCONUT-SVSM relies on virtual machine privilege separation to provide secure services for confidential virtual machines. Enabling this model on open-source virtualization stacks requires hypervisor support for technologies such as AMD SEV-SNP VMPLs and TDX Partitioning.

At KVM Forum 2024, the community discussed an architecture-independent approach to supporting these privilege separation mechanisms, leading to the KVM Planes proposal and subsequent development work.

This talk presents the current state of the KVM Planes work, with a focus on the practical challenges of making the interface generic across architectures while still addressing AMD SEV-SNP VMPL-specific requirements. It will cover implementation considerations, integration details, patch status, and the open design questions that remain.

The session will also outline future enhancements needed to support Para-visor workloads and invite discussion on whether KVM Planes has reached the point where COCONUT-SVSM can confidently come aboard.

Hardware implementations of VIRTIO devices have emerged as a way to offload I/O functionality for both bare metal and VMs. What does it take to create your own hardware VIRTIO device? Let's find out by building a virtio-serial FPGA device.

This talk covers the design of an open source virtio-serial-mmio device for the PicoRV32 RISC-V CPU. Starting from the basics of the FPGA development process, we will look at implementing memory mapped registers and DMA, the VIRTIO device lifecycle, virtqueue processing, a UART transceiver, and PicoRV32 firmware to use the device.

Finally, we touch on options for going further with actual ASIC implementation or more advanced hybrid hardware/software devices. If you are interested in exploring FPGAs or implementing VIRTIO devices in hardware, then this talk will get you started.

The memory management for KVM/s390 grew up in weird ways, due to some architecture quirks, and due to the lack of advanced features in the early days of KVM.
As both KVM and the s390 architecture grew more features, they were tacked on, creating a complex system partially spread across KVM and normal Linux/s390 memory management.

Thus a decision was taken to completely rewrite the memory management for KVM/s390, removing almost all KVM-related memory management from the non-KVM part of the kernel, and using as much KVM common code as realistically possible.

This talk will show an overview of how the rewrite has been done, which is also a recipe for writing a KVM memory management from scratch. It will also highlight the challenges, especially related to nested virtualization, and the advantages in terms of newly supported features.

Abstract

VFIO based device migration on KVM is widely used to live-migrate stateful PCIe devices such as NVIDIA vGPUs. It involves moving device state between hardware, a vendor implementation, the kernel VFIO migration interface, and QEMU. In NVIDIA vGPU migration on KVM, GPU state has traditionally been DMAed into a vendor user-space staging buffer, copied into a nvidia-vgpu-vfio kernel buffer, and then read by QEMU through the VFIO save file descriptor. Resume follows the reverse path. With multi-gigabyte vGPU state, the extra copy and strictly serial hand-off between user space and kernel slow down QEMU reads and writes, directly extending the stop-and-copy window and increasing VM downtime.

This talk presents a zero-copy live migration optimization in the NVIDIA vGPU driver. The kernel driver owns a pool of DMA-mapped migration buffers and exposes an ownership-transfer interface to the vendor user-space vGPU manager. The user-space manager programs GPU DMA directly into and out of these kernel-owned buffers, while QEMU continues to use the standard VFIO migration save/resume file descriptors. By replacing the single staging-buffer hand-off with a buffer pool, the design allows vendor DMA and QEMU I/O to overlap in a pipeline, leading to significant improvements in vendor VFIO save/resume bandwidth and VM downtime.

We will describe how the zero-copy interface is integrated into the vendor driver's VFIO migration state machine, and present measured performance improvements in save/resume bandwidth and VM downtime.

Finally, we will discuss how this optimization can be extended beyond the NVIDIA vGPU driver into VFIO/QEMU to move toward true zero-copy device migration.

Audience takeaways

Attendees will get an overview of the NVIDIA vGPU live migration architecture, the zero-copy optimization and its impact on performance, and how the zero-copy interface could be extended to VFIO/QEMU to achieve zero-copy data movement across the vendor VFIO driver and QEMU.

The AMD Root Guest (ARG) is a new trusted firmware component for x86 that extends AMD SNP capabilities to support additional platform services. This presentation describes the motivations for ARG, the design and lifecycle of the component and the initial Live Migration feature developed to enable secure live migration of SNP-protected guests. It will cover the ARG initialization and runtime model and the interfaces used for firmware and hypervisor communication. The talk will conclude with an outline of how ARG initialization and usage can be integrated into Linux/KVM, including proposed control flows and required kernel/hypervisor changes.

Most live migrations just work: pre-copy converges, QEMU hits its downtime target, and nobody notices. The painful ones are growing more common — write-heavy databases, AI inference servers, and large in-memory caches where remaining bytes plateau and oscillate instead of falling. During a node drain, failover, or maintenance window, that means wasted bandwidth, extended migration time, and switchover pauses that can break application SLOs.

Today's convergence policies — static timeouts, stepwise downtime ramps, iteration-counter schedules, and naive remaining-bytes heuristics — all treat stall as binary: keep waiting or force switchover now. None ask the question that actually matters: pre-copy has converged as far as it can, so when is the best moment to switch?

Li et al. ("Efficient Live VM Migration for Memory Write-Intensive Workloads") showed that deferring switchover to a local minimum of remaining dirty pages can substantially cut downtime, but assumed static workloads and left phase shifts as future work.

Recently merged into KubeVirt (PR #17544), this talk presents the first production-grade implementation of that policy that we know of. It hooks libvirt migration-iteration callbacks and domain job statistics (remaining bytes, transfer bandwidth) to detect convergence stall and trigger switchover through libvirt max-downtime adjustment or post-copy entry. Three extensions were needed to make the academic idea survive real workloads: a stall margin that avoids chasing marginal gains; an iterative relaxation schedule for when workload or bandwidth shifts make the original minimum unreachable (an acknowledged open problem in the paper); and a wall-clock sliding window that self-adjusts sample density to iteration length. On write-heavy Redis workloads we see up to ~5× lower switchover downtime with less variance; gains are workload-dependent and we discuss where the policy helps most.

What attendees will learn: why remaining-bytes oscillation breaks common stall heuristics; how to time switchover using local minima without over-waiting; the path from research idea to production policy (guardrails, relaxation, network-degradation safety); and a reusable libvirt/QEMU integration pattern for any QEMU-based management layer.

KVM is a mature and widely trusted codebase, but recent industry-wide security events, often referred to as the "VulnPocalypse", highlight the need for continuous scrutiny. In this talk, we approach KVM security from the threat model of a cloud provider, where guest isolation and host stability are critical concerns.

To evaluate the hypervisor, we conducted an AI-assisted audit of the KVM codebase. During this process, we were able to identify several impactful issues, including denial-of-service (DoS) triggers and exploit primitives that could facilitate guest escapes. This talk will share our approach for using AI to augment traditional vulnerability research.

Memory is the dominant bottleneck for oversubscription in agentic sandboxes. To alleviate this pressure, we aim to reuse memory of sandbox in inference scenario through incremental snapshots. This approach also reduces both storage footprint and restore cost substantially by persisting snapshot delta only in the training scenario. In the meantime, vhost-user devices are crucial for persistent agentic session, by which sandboxes access object storage and block storage.
However, there are two fundamental gaps in the current virtualization infrastructure:

• Vhost-user devices, which require shared memory between processes, forbids the kernel's built-in CoW mechanism. Essentially, we need the CoW mechanism of a group of processes to accomplish snapshot.
• To keep snapshot checkpoints free of transient page cache and to offload page cache to the host for more efficient cache reclamation, we rely on virtio-pmem DAX. Yet DAX today lacks support for a writable overlay block device backed by lazy-loaded remote storage.

To close these gaps, we design and implement a CoW framework inside KVM that leverages the EPT to compose multiple read-only file descriptors together with a single writable descriptor into one unified guest physical address space. Building upon this substrate, we further implement an incremental snapshot protocol that uniformly covers both memory snapshots and DAX disk snapshots with remote lazyload.

COCONUT SVSM acts as the foundational privileged firmware for Confidential Virtual Machines (CVMs), providing essential secure services and device emulation. In this session, we unveil a year of progress—most notably a new UEFI variable service that enables SecureBoot.
We will highlight our technical breakthroughs, including advances in device driver support, hardened attestation mechanisms, and the groundwork for userspace task support. Finally, we look ahead to our development roadmap, focusing on critical features like persistent state, preemptive multitasking, and beyond.

In this session, I will discuss several topics related to Windows support in QEMU/KVM:

• virtio-win project news and future directions: from virtio hardware support to new Windows drivers.
• HCK-CI test framework: from driver certification to a general CI platform for Windows guests, including functional and performance testing.
• Other Windows guest topics, ranging from VBS to using AI for Windows guest debugging.

WHPX and HVF are QEMU's hardware acceleration backends for Windows and macOS hosts respectively. This talk is primarily centred around the state of those backends, improvements during the QEMU 11.x releases - which include increased performance, compatibility and nested virtualisation - and what's ongoing.

The state of macOS as a guest on Arm (vmapple) and TCG will be covered a bit but won't be central to the talk.

Virtio Villain runs as PID 1 in a minimal initramfs and drives real virtio devices over virtio PCI and MMIO. It deliberately breaks the protocol to see how the device model inside the VMM reacts. The same test suite runs against Cloud Hypervisor, QEMU and OpenVMM.

Threat model. A buggy or malicious guest drives a modern virtio device. The harness submits malformed or out of spec input and distinguishes safe rejection from incorrect behavior, a device wedge or a VMM failure. A fresh VM for each isolated test prevents one failure from affecting the next case.

What is covered. The deterministic test suite covers a number of device families. It exercises split and packed virtqueues as well as indirect descriptors. Some tests use a host side helper for device addition, snapshots and restore. A structured fuzzer explores beyond the cases written by hand.

What it found. The framework has surfaced bugs and specification violations in Cloud Hypervisor, QEMU and OpenVMM. Findings have led to upstream fixes and deterministic regression tests.

What the audience gets. The talk presents a reusable method for testing how virtio device models handle malformed guest input across VMMs. It explains how to distinguish safe rejection from loss of device progress and how to turn a finding into a permanent regression test.

Scope and status. Virtio Villain targets the modern virtio interface. It performs specification based fault injection and structured fuzzing. It is not an exploit framework. Exploitability requires separate analysis.

Can hardware-assisted virtualization be used even when host and guest architectures differ?

The s390 KVM community recently proposed a novel support of hardware-accelerated virtualization that enables arm64 guests to run on s390 hosts. To make this possible, a new common KVM infrastructure shared between the s390 and arm64 architectures was introduced. In this model, the s390 host takes advantage of a hardware functionality to run arm64 EL1/EL0 guests, creating a hybrid cross-architecture virtualization environment.

This talk will present the architectural concepts and KVM design behind this approach, including the challenges of bridging fundamentally different CPU architectures while still benefiting from hardware acceleration. We will discuss the newly introduced common KVM components, the current implementation status, managing maintainability for shared code between only two architectures and future options for extending functionality and improving arm64 guest support on s390.

Cloud operators frequently encounter Windows VM failures that are difficult or impossible to diagnose from inside the guest, especially when the VM fails to boot, becomes unresponsive, or crashes before diagnostic tools can run. In large-scale cloud environments, these issues are especially challenging because the guest may provide little or no useful evidence, while manual troubleshooting is expensive and slow.

In this talk, we present a backend-assisted observability approach for diagnosing Windows VM failures without modifying QEMU. Our workflow combines virtual device topology and status, vring activity, and runtime introspection through existing libvirtd/HMP interfaces to infer failure stages and narrow down likely root causes. We will share the design of the workflow, the backend signals we collect, and real-world case studies from Alibaba Cloud.

Last year, we presented our work in progress on single-binary. It's now
available upstream (or should be soon) as 'qemu-system' and supports
architectures [arm, aarch64, microblaze]. Now we showed this approach could work,
we have new challenges lying ahead of us with Heterogeneous emulation.

In this presentation, we'll first come back on what we implemented with
the single-binary, and which value it brings to the QEMU project. Then,
we'll present what is heterogeneous emulation and the new problems we
need to solve. Finally, we'll present our vision for solving them in the
future.

VMMs like QEMU operate in host userspace, where they handle untrusted inputs from guests during I/O emulation, device management, and VM-exit processing. Because the VMM's address space maps guest physical memory alongside host-side structures, an untrusted guest can exploit speculative execution vulnerabilities within the VMM to mount guest-to-host attacks and exfiltrate sensitive host or cross-VM data.

Existing mitigations often fall short in this context. Issuing an Indirect Branch Predictor Barrier (IBPB) on every guest-to-host transition incurs unacceptable performance overhead due to microarchitectural state flushing. Alternatively, memory-isolation features like guest_memfd are insufficient: if a guest can force the VMM to constantly keep arbitrary guest memory mapped, guest_memfd cannot prevent the leakage of that memory under speculative attacks.

In this session, we present a practical, hardware-assisted defense to complete the Address Space Isolation ecosystem by protecting host userspace. Malicious guests can taint CPU microarchitectural state (such as the BTB, BHB, and RSB) to hijack the VMM's speculative execution after a VM-exit, forcing it to access and exfiltrate sensitive secrets in host userspace. By leveraging x86 Protection Keys for Userspace (PKRU), we implement a userspace address space isolation mechanism. We tag both guest memory regions and sensitive VMM data with a dedicated protection key, dynamically revoking access permissions at the hardware level during general VMM execution. Because CPU pipelines natively enforce PKRU restrictions even during out-of-order execution, any speculative gadgets hijacked by the tainted state are blocked in hardware before they can access or leak these secrets.

We will discuss:

• The Guest-to-Host Threat Model: Why VMM userspace execution handling untrusted guest inputs remains a critical attack surface for speculative execution.
• Limitations of Existing Defenses: Why frequent IBPB flushing is too costly, and why guest_memfd leaves gaps when guest memory must remain mapped.
• The PKRU Defense Paradigm: How unprivileged, low-latency protection key switching can isolate access boundaries and neutralize speculative gadgets on the fly.
• Deployment & Practical Impact: Hardening KVM/QEMU infrastructure against guest-originated attacks with minimum runtime overhead, noting how exclusive vCPU-to-pCPU pinning—standard in public cloud "slice of hardware" offerings—naturally completes this mitigation strategy.

Under QEMU user-mode, every C/C++ library an x86_64 program uses is emulated along with it. We want those libraries to run natively on the host, while the guest executable stays unchanged.

Box64 and FEX established library pass-through for the C ABI, and QEMU-X64Echo takes it a step further, to C++. The C++ object model (vtables, exceptions, bidirectional callbacks, multiple and virtual inheritance) has not crossed the emulation boundary before, and X64Echo crosses all of it transparently, over a single unified heap, with both the guest and host dynamic linker unchanged.

QEMU-X64Echo builds on our Lorelei work from last year, whose dlcall plugin interface and plugin are already upstream in QEMU.

The payoff is large and broad. Sixteen real-world C++ libraries pass through unmodified, from parsers and compressors to OpenSSL and Crypto++, and so does Qt 6.8 all the way up to QtWidgets. On an ARM host, an unmodified x86_64 program driving native aarch64 libraries reaches up to 37× the throughput of full emulation on compute-heavy library work, and 29× on a graphics-heavy QtWidgets workload.