{"$schema": "https://c3voc.de/schedule/schema.json", "generator": {"name": "pretalx", "version": "2026.3.0.dev0", "url": "https://pretalx.com"}, "schedule": {"url": "https://pretalx.com/kvm-forum-2026/schedule/", "version": "0.6", "base_url": "https://pretalx.com", "conference": {"acronym": "kvm-forum-2026", "title": "KVM Forum 2026", "start": "2026-11-12", "end": "2026-11-13", "daysCount": 2, "timeslot_duration": "00:05", "time_zone_name": "Canada/Pacific", "colors": {"primary": "#3aa57c"}, "rooms": [{"name": "2", "slug": "5884-2", "guid": "48185b8e-3553-5783-965a-585f39040910", "description": null, "capacity": null}, {"name": "1", "slug": "5883-1", "guid": "061927e4-c061-5d76-86d6-8f8ed1f4e760", "description": null, "capacity": null}], "tracks": [], "days": [{"index": 1, "date": "2026-11-12", "day_start": "2026-11-12T04:00:00-07:00", "day_end": "2026-11-13T03:59:00-07:00", "rooms": {"1": [{"guid": "f224d7e5-a951-53ab-b42c-898690dd514f", "code": "QHGCZY", "id": 104787, "logo": null, "date": "2026-11-12T08:40:00-07:00", "start": "08:40", "end": "2026-11-12T09:10:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-104787-keynote-kvm", "url": "https://pretalx.com/kvm-forum-2026/talk/QHGCZY/", "title": "Keynote: KVM", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "TBTHBS", "name": "Paolo Bonzini", "avatar": null, "biography": "Paolo Bonzini works on virtualization for Red Hat, where he is a Distinguished Engineer. He is currently the maintainer of the KVM hypervisor and a contributor and submaintainer for QEMU.", "public_name": "Paolo Bonzini", "guid": "ed550d22-e6f2-56ce-b6b8-f6fd768ab6e5", "url": "https://pretalx.com/kvm-forum-2026/speaker/TBTHBS/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/QHGCZY/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/QHGCZY/", "attachments": []}, {"guid": "6935d9f6-3212-5935-a32c-0296f0521942", "code": "JQRUKK", "id": 103767, "logo": null, "date": "2026-11-12T09:15:00-07:00", "start": "09:15", "end": "2026-11-12T09:35:00-07:00", "duration": "00:20", "room": "1", "slug": "kvm-forum-2026-103767-hidden-in-plain-sight-the-virtualization-roadmap-supporting-nvidia-superchips", "url": "https://pretalx.com/kvm-forum-2026/talk/JQRUKK/", "title": "Hidden in Plain Sight: The Virtualization Roadmap Supporting NVIDIA Superchips", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "An NVIDIA Grace-Hopper or Grace-Blackwell Superchip is not \"a server with a PCI GPU.\"\u00a0 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.\u00a0 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.\n\nThis 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.\n\nFollowing 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.\u00a0 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "RDGZYL", "name": "Alex Williamson", "avatar": "https://pretalx.com/media/avatars/WSDGHA_2mjE5DA.webp", "biography": "Alex Williamson is a longtime Linux kernel and QEMU developer working for NVIDIA from Fort Collins, Colorado.  Alex is the maintainer of the Linux VFIO subsystem, which enables IOMMU-protected access to physical devices for userspace drivers and virtual machines.  Alex also co-maintains VFIO support in QEMU and contributes to various Linux subsystems, including PCI and IOMMU.", "public_name": "Alex Williamson", "guid": "dae16fdd-ae44-5c97-8810-d81463cbe40c", "url": "https://pretalx.com/kvm-forum-2026/speaker/RDGZYL/"}, {"code": "AGG8T8", "name": "Ankit Agrawal", "avatar": "https://pretalx.com/media/avatars/X7XX7M_QGkCEcX.webp", "biography": "Ankit is an open-source developer working for NVIDIA on vGPU and Passthrough virtualization. He is currently working actively on providing virtualization support on NVIDIA Grace based systems.", "public_name": "Ankit Agrawal", "guid": "18a45e39-dba7-5eb4-8d29-523e09d5f934", "url": "https://pretalx.com/kvm-forum-2026/speaker/AGG8T8/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/JQRUKK/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/JQRUKK/", "attachments": []}, {"guid": "f8c1dfef-f047-5cc1-a9d2-775d06cfbb52", "code": "BFHGKB", "id": 103179, "logo": null, "date": "2026-11-12T09:35:00-07:00", "start": "09:35", "end": "2026-11-12T09:55:00-07:00", "duration": "00:20", "room": "1", "slug": "kvm-forum-2026-103179-nvidia-vgpu-the-next-phase-of-upstreaming", "url": "https://pretalx.com/kvm-forum-2026/talk/BFHGKB/", "title": "NVIDIA vGPU: The Next Phase of Upstreaming", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "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.\n\nWe 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.\n\nThe 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.\n\nWe 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.\n\nFinally, we will outline the next milestones, remaining integration work, and the areas where feedback from the KVM/VFIO community is most useful.\n\nSession Outline\n\n1. Recap: vGPU Lifecycle\n\nvGPU discovery, type selection, instance creation, assignment, runtime operation, teardown, and reset/recovery.\n\n2. Recap: Host-Side Architecture\n\nThe division of responsibilities between Nova-Core, firmware-facing paths, VFIO, and userspace.\n\n3. Current Upstreaming Progress\n\nGSP/FSP enablement, SR-IOV and vGPU mode setup, runtime lifecycle work, resource management, and VFIO variant driver integration.\n\n4. New Building Blocks\n\nNVKV, simplified GSP initialization, Plugin RPC, vGPU bootload flow, debug/log plumbing, and guest-memory hygiene.\n\n5. Roadmap/Next Milestones\n\nPatchset decomposition, review priorities, remaining integration work, and the path toward an upstreamable NVIDIA vGPU host stack.\n\nAudience Takeaways\n\nAttendees 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "UTSL33", "name": "Zhi Wang", "avatar": null, "biography": "Zhi is an open-source developer working on vGPU, confidential computing, and virtualization. He is currently working on NVIDIA vGPU. For confidential computing, he is interested in Intel TDX/AMD SEV-SNP and worked on TDX Connect enabling at Intel.", "public_name": "Zhi Wang", "guid": "07eb9166-5b13-5afa-b401-e6b870edaeb8", "url": "https://pretalx.com/kvm-forum-2026/speaker/UTSL33/"}, {"code": "RF3UU9", "name": "Alok Kumar", "avatar": null, "biography": "Alok Kumar is a Senior System Software Engineer at NVIDIA, where he focuses on GPU virtualization for NVIDIA GPU platforms.", "public_name": "Alok Kumar", "guid": "569153eb-8ebc-5ccf-be83-7cec435c62a6", "url": "https://pretalx.com/kvm-forum-2026/speaker/RF3UU9/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/BFHGKB/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/BFHGKB/", "attachments": []}, {"guid": "ac58e138-46f3-572f-be73-a7b16cf4955b", "code": "VCNXGV", "id": 102947, "logo": null, "date": "2026-11-12T09:55:00-07:00", "start": "09:55", "end": "2026-11-12T10:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-102947-virtualizing-cxl-type-2-devices-what-changes-beyond-pci-passthrough", "url": "https://pretalx.com/kvm-forum-2026/talk/VCNXGV/", "title": "Virtualizing CXL Type-2 devices: what changes beyond PCI passthrough", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "Abstract\n========\nPCI passthrough works for a lot of accelerators today: bind vfio-pci, map BARs\nand MSIs, run the guest driver. CXL Type-2 devices still show up as PCI\nfunctions, but the guest also expects coherent device memory and a few extra\ndiscovery surfaces that stock vfio-pci does not provide.\n\nIn short, passing a CXL.mem-capable GPU (or similar Type-2 device) to a VM\nneeds three things at once: a guest-mappable view of the firmware-committed\ncoherent memory range, a spec-consistent view of the CXL config and component\nregisters the guest driver reads at probe, and a guarantee that the guest\ncannot reprogram the host's physical HDM mapping. This talk walks through\nthose three requirements from the guest's point of view, then shows how Linux,\nQEMU, and libvirt split the work so the guest sees a normal CXL endpoint\nwithout getting control of the real decoder.\n\nThe goal is a cross-layer contracts discussion and open questions about how\nresource ownership, assignment, guest memory and ACPI fit together when the\ndevice has memory, not just MMIO. That cuts across KVM, QEMU, VFIO, CXL-Core,\niommufd, firmware, and management tools.\n\nI will build one mental model for the CXL type-2 device passthrough stack:\n* Host kernel owns the physical map and register policy.\n* QEMU wires guest physical memory and ACPI topology.\n* Guest runs its usual driver against shadows and overlays.\n\nAudience takeaways\n==================\n\n* Attendees should be able to explain the problem associated with CXL type-2\n  device passthrough to someone who only knows PCI passthrough. Why Type-2 is\n  not \"vfio-pci as today\": coherent device memory plus CXL config/component\n  surfaces, not just BARs and MSIs.\n\n* The three virtualization requirements: mmapable HDM-backed memory,\n  spec-consistent register view, host-protected physical decoder.\n  \n* Who provides each piece: cxl-core policy, vfio-pci regions, VMM memory\n  layout and overlays.\n\nOut of scope\n============\n\n* CXL Type-3 memory expander product path.\n* CXL.cache mediation and switched topologies.\n* Nested virt test harness.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "ABRLU8", "name": "Manish Honap", "avatar": "https://pretalx.com/media/avatars/LMCECP_ZWsFDE5.webp", "biography": "Manish Honap is a Senior System Software Engineer at NVIDIA, where he focuses on GPU virtualization and enabling passthrough GPU support for NVIDIA GPU platforms.", "public_name": "Manish Honap", "guid": "3ece4ec0-362f-5352-ac29-f3ba4fe85f9e", "url": "https://pretalx.com/kvm-forum-2026/speaker/ABRLU8/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/VCNXGV/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/VCNXGV/", "attachments": []}, {"guid": "b428d6ec-a291-5d17-be0f-fef9226cf6b3", "code": "ATSSVN", "id": 103353, "logo": null, "date": "2026-11-12T10:55:00-07:00", "start": "10:55", "end": "2026-11-12T11:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103353-qemu-kvm-live-migration-across-heterogeneous-hosts-on-arm64", "url": "https://pretalx.com/kvm-forum-2026/talk/ATSSVN/", "title": "QEMU/KVM: Live migration across heterogeneous hosts on ARM64", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "On x86, live migration across heterogeneous hosts has been a solved problem\nfor years: named CPU models and fine-grained feature control let a guest\nmove between machines with different silicon while keeping a stable guest\nABI. On ARM64, none of that exists yet, and QEMU/KVM only offers the\nso-called host passthrough vCPU model, which mostly inherits its features\nfrom the host CPU and, with only a few exceptions, cannot be tuned. As a\nconsequence, migration on ARM can only happen between strictly identical\nhosts. As ARM establishes itself in the server and cloud market, this gap\nis quickly becoming a blocker for real deployments.\n\nWe present a joint Red Hat and Nutanix end-to-end solution built from two\ncomplementary layers. The lower layer leverages the KVM/ARM capability to\nwrite a subset of the vCPU ID registers: ID-register descriptions are\nextracted from ARM's machine-readable specification, and a property is\ngenerated for each ID-register field. The upper layer provides hierarchical\nnamed CPU models (for example, `grace-v1`, `neoverse-v2-v1`,\n`arm-v9_0-a-v1`) that acts as a strict, forward-compatible migration\ncontract, using parent/child inheritance to keep the growing model set\nmaintainable.\n\nThis talk mostly addresses the new upper layer. It especially covers QMP\nintrospection of valid property values and valid vCPU models, which\nmanagement tools badly need; several strategies will be presented. We will\nalso explain the integration challenges with the existing host-passthrough\nCPU model: coexistence with the existing legacy composite options, cpreg\nvalues derived from a scratch vCPU that may be a superset of the actual\nvCPU model, and option ordering during both introspection and the actual\nrun.  We will also look at how these named models stay forward compatible,\nso that a model defined today keeps resolving to the same guest-visible CPU\non future hardware, QEMU, and kernel versions.\n\nA draft libvirt integration will be presented, and the talk will be\nillustrated by real heterogeneous migration cases.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "AJVBPG", "name": "Khushit Shah", "avatar": "https://pretalx.com/media/avatars/3LN3TL_10pN2QB.webp", "biography": "Member of Technical Staff 2 @ Nutanix", "public_name": "Khushit Shah", "guid": "da55bcd8-06bc-5685-99dc-69f7948c561d", "url": "https://pretalx.com/kvm-forum-2026/speaker/AJVBPG/"}, {"code": "QCLQYG", "name": "Sandesh Singh Patel", "avatar": null, "biography": "Member of technical staff at Nutanix", "public_name": "Sandesh Singh Patel", "guid": "4592d67d-21f3-5497-8718-a9e4337213ce", "url": "https://pretalx.com/kvm-forum-2026/speaker/QCLQYG/"}], "links": [{"title": "Nutanix's libvirt integration series", "url": "https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HQQA5PGINROARUIKC53UYLJGKYXSJYDV/", "type": "related"}, {"title": "Nutanix's Named CPU models on ARM64 series", "url": "https://lore.kernel.org/qemu-arm/20260716213858.609699-1-khushit.shah@nutanix.com/T/#me401c2f7af7e33b21c9a526f41bcf1dce2e90a30", "type": "related"}, {"title": "Redhat's Customisable host model series", "url": "https://lore.kernel.org/qemu-arm/20260726153221.24773-1-eric.auger@redhat.com/T/#t", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/ATSSVN/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/ATSSVN/", "attachments": []}, {"guid": "8067af25-4db4-5008-8b2d-aa00f6019376", "code": "WXARUL", "id": 103431, "logo": null, "date": "2026-11-12T11:25:00-07:00", "start": "11:25", "end": "2026-11-12T11:55:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103431-and-nv3-for-all-an-attempt-at-accelerating-nested-virtualisation-on-arm64", "url": "https://pretalx.com/kvm-forum-2026/talk/WXARUL/", "title": "... and NV3 for all (an attempt at accelerating nested virtualisation on arm64)", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "```\nWhile FEAT_NV2 made Nested Virtualisation a realistic possibility on arm64,\nperformance is still degrading very rapidly as we reach deeper nesting\nlevels. This degradation stems from the exponential increase of the number\nof traps caused by each additional level of nesting.\n\nFEAT_NV3 builds on top of FEAT_NV2 to address some of the overhead by\nthrowing additional architecture (and hardware) at the problem, reducing to\nzero the cost of emulating common sequences such as local exception returns.\n\nHowever it also possible to reap a significant proportion of the NV3\nbenefits on current NV2-capable hardware. This improves the situation in\ncases that suffer the most from the NV overhead such as L2 and up, at the\ncost of a deviation from the architecture.\n\nThis talk will look at the techniques that can be used to roughly emulate\nNV3 on top of NV2 in KVM/arm64, and look at the performance results.\n\nFinally, we will explore the ways this approach could be applied to other\nparts of the hypervisor to improve performance at the cost of further\ndepartures from the current architecture.\n```", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "7MMQDR", "name": "Marc Zyngier", "avatar": null, "biography": "Marc Zyngier has been toying with the Linux kernel since 1993, and has been involved over time with the RAID subsystem (MD), the interrupt subsystem, and all sorts of obsolete computer architectures.\nHe also messed with consumer electronics, cloud infrastructure, mobile phones and CPU design while\nkeeping track of the ARM architecture and co-maintaining KVM/arm64.", "public_name": "Marc Zyngier", "guid": "813e8efd-767a-5181-9d51-a2a981be526d", "url": "https://pretalx.com/kvm-forum-2026/speaker/7MMQDR/"}], "links": [{"title": "FEAT_NV3 support and emulation", "url": "https://web.git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv3", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/WXARUL/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/WXARUL/", "attachments": []}, {"guid": "cc80803d-364b-5a53-ad35-3ced27f8f5b6", "code": "9FBPKH", "id": 103591, "logo": null, "date": "2026-11-12T11:55:00-07:00", "start": "11:55", "end": "2026-11-12T12:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103591-bringing-arm64-support-to-the-mshv-accelerator-in-qemu", "url": "https://pretalx.com/kvm-forum-2026/talk/9FBPKH/", "title": "Bringing ARM64 Support to the MSHV Accelerator in QEMU", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "The Microsoft Hypervisor (mshv) driver in Linux enables QEMU to leverage Microsoft\u2019s hypervisor directly on Linux hosts. While initial enablement focused on x86_64, expanding AArch64 support is essential for modern ARM-based enterprise workloads.\n\nIn 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.\n\n**Talk Outline:**\n1. **Introduction & Architecture**\n    - Overview of the mshv Linux kernel module and Microsoft Hypervisor partition management on AArch64.\n2. **QEMU Accelerator Enablement**\n    - `-cpu host` configuration.\n    - MMIO emulation.\n    - Virtual GIC.\n3. **Live Migration**\n    - Saving/restoring MSHV specific states.\n    - Patch series will be ready before the conference.\n4. **Performance Benchmark: MSHV vs. KVM**\n    - Head-to-head performance breakdown on identical ARM64 hardware.\n        - virtio device performance (latency, throughput of virtio-blk, virtio-net)\n        - save/restore latency\n    - Insights into structural performance differences between KVM and MSHV.\n5. **Upstream Status & Next Steps**\n    - Current status of the patch series on qemu-devel.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "VBUAHN", "name": "Aastha Rawat", "avatar": null, "biography": "Aastha is a Software Engineer at Microsoft in Linux Systems Group. She works in the virtualization team. Her work spans the virtual machine monitors, and validation infrastructure, with contributions to projects including Cloud Hypervisor, QEMU.", "public_name": "Aastha Rawat", "guid": "212e994d-4793-5eb2-8296-a3027e80aa83", "url": "https://pretalx.com/kvm-forum-2026/speaker/VBUAHN/"}, {"code": "NVUH8L", "name": "Anirudh Rayabharam", "avatar": null, "biography": "Anirudh Rayabharam is a Senior Software Engineer at Microsoft working on Linux virtualization and the Hyper-V ecosystem. His work spans the Linux kernel, virtual machine monitors, and validation infrastructure, with contributions to projects including Cloud Hypervisor, QEMU, and the upstream Linux kernel.", "public_name": "Anirudh Rayabharam", "guid": "7115f5a2-0d33-5a67-96c9-32c5f9defc1b", "url": "https://pretalx.com/kvm-forum-2026/speaker/NVUH8L/"}], "links": [{"title": "[PATCH v5 00/13] Add ARM64 support for MSHV accelerator", "url": "https://lore.kernel.org/qemu-devel/20260717-mshv_accel_arm64_supp-v5-0-ef07d4c6b337@linux.microsoft.com/", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/9FBPKH/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/9FBPKH/", "attachments": []}, {"guid": "4ca7ac81-025f-5a38-8dc7-d97f07568bb6", "code": "MGJJDZ", "id": 101095, "logo": null, "date": "2026-11-12T13:45:00-07:00", "start": "13:45", "end": "2026-11-12T14:15:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-101095-bring-your-own-firmware-reloaded-and-what-igvm-can-do-for-you", "url": "https://pretalx.com/kvm-forum-2026/talk/MGJJDZ/", "title": "Bring your own firmware reloaded and what IGVM can do for you", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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\u2019s 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 \u201cBring Your Own Firmware\u201d (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\u2019s work in this respect.\n\nReferences:\n1. https://www.redhat.com/en/blog/confidential-guest-reset-qemu-hypervisor-design-choices-and-approach\n2. https://gitlab.com/qemu-project/kvm-forum/-/raw/main/_attachments/2024/BYOF_-_KVM_Forum_2024_iWTioIP.pdf \n3. v3 patchset: https://lists.gnu.org/archive/html/qemu-devel/2026-07/msg08290.html \n4. https://people.redhat.com/~anisinha/vmlaunchupdate \n5. https://www.qemu.org/docs/master/system/igvm.html", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "U7KZ3W", "name": "Ani Sinha", "avatar": "https://pretalx.com/media/avatars/JN83VH_xUnSBho.webp", "biography": "I am a software engineer who works for Red Hat in the virtualization engineering group. My primary focus areas are Confidential computing, QEMU, KVM, libvirt and open source cloud virtualization tools like cloud-init, Microsoft WALA agent, hyperv-daemons etc. My Red Hat personal page is located at: https://people.redhat.com/~anisinha/", "public_name": "Ani Sinha", "guid": "efee583a-0c84-5122-992a-532855989e36", "url": "https://pretalx.com/kvm-forum-2026/speaker/U7KZ3W/"}, {"code": "N9HXRT", "name": "Gerd Hoffmann", "avatar": null, "biography": "Gerd Hoffmann is working in the Red Hat virtualization team.  Main\nfocus in recent years is firmware for virtual machines, where he is\nworking on both guest side projects (seabios, edk2, svsm) and host\nside support in qemu.  Before getting more deeply involved in firmware\nsupport Gerd has maintained multiple subsystems (graphics, usb, audio)\nin qemu.", "public_name": "Gerd Hoffmann", "guid": "588f4fa7-a303-54e2-9012-f10214f66d98", "url": "https://pretalx.com/kvm-forum-2026/speaker/N9HXRT/"}], "links": [{"title": "patch v1 of hypervisor interface", "url": "https://lists.gnu.org/archive/html/qemu-devel/2026-06/msg06043.html", "type": "related"}, {"title": "patch v2 of hypervisor interface", "url": "https://lists.gnu.org/archive/html/qemu-devel/2026-07/msg04209.html", "type": "related"}, {"title": "patch v3 of hypervisor interface", "url": "https://lists.gnu.org/archive/html/qemu-devel/2026-07/msg08290.html", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/MGJJDZ/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/MGJJDZ/", "attachments": []}, {"guid": "f62fdc89-512b-5161-a452-ea541c54f39e", "code": "K7UYA9", "id": 103987, "logo": null, "date": "2026-11-12T14:15:00-07:00", "start": "14:15", "end": "2026-11-12T14:45:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103987-aws-nitro-enclaves-in-qemu", "url": "https://pretalx.com/kvm-forum-2026/talk/K7UYA9/", "title": "AWS Nitro Enclaves in QEMU", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nWalk 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "GZ7FKY", "name": "Alexander Graf", "avatar": null, "biography": "Alexander works at AWS, where he is responsible for the Nitro Hypervisor, focusing on Confidential Compute technologies, cross-platform hypervisor features and security. Previously, he worked on QEMU, KVM, openSUSE / SLES on ARM and U-Boot. Whenever something really useful comes to his mind, he implements it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC, a lot of work in QEMU for openSUSE on ARM and the UEFI compatibility layer in U-Boot.", "public_name": "Alexander Graf", "guid": "c27ae5ff-4db3-578e-83e8-d9401aa89d62", "url": "https://pretalx.com/kvm-forum-2026/speaker/GZ7FKY/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/K7UYA9/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/K7UYA9/", "attachments": []}, {"guid": "89490d8b-684c-5611-9ff6-ecbc373daabc", "code": "VKVWE8", "id": 103970, "logo": null, "date": "2026-11-12T15:15:00-07:00", "start": "15:15", "end": "2026-11-12T15:45:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103970-afvsock-namespaces-zerocopy-and-beyond", "url": "https://pretalx.com/kvm-forum-2026/talk/VKVWE8/", "title": "AF_VSOCK: Namespaces, Zerocopy, and Beyond", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn 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.\n\nWe 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`).\n\nIn 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.\n\nFinally, we highlight ongoing efforts, including guest-side namespace support and `SOCK_DGRAM`, concluding with a roadmap of remaining challenges and future directions.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "LPSJFJ", "name": "Stefano Garzarella", "avatar": "https://pretalx.com/media/avatars/NTKW8M_ajsoYl9.webp", "biography": "Stefano is a Principal Software Engineer at Red Hat. He is the maintainer of Linux's vsock subsystem (AF_VSOCK) and co-maintainer of rust-vmm and COCONUT SVSM. Current projects cover Confidential VMs and virtio devices support.", "public_name": "Stefano Garzarella", "guid": "207ac3b7-6bed-5704-a567-ec70770a0bd2", "url": "https://pretalx.com/kvm-forum-2026/speaker/LPSJFJ/"}, {"code": "XBD7QX", "name": "Bobby Eshleman", "avatar": null, "biography": null, "public_name": "Bobby Eshleman", "guid": "269122b0-9e3b-511a-b160-e03649a97fc2", "url": "https://pretalx.com/kvm-forum-2026/speaker/XBD7QX/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/VKVWE8/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/VKVWE8/", "attachments": []}, {"guid": "79c457dc-5de7-5a08-a25a-3b72e825ea5f", "code": "MSMPYU", "id": 104036, "logo": null, "date": "2026-11-12T15:45:00-07:00", "start": "15:45", "end": "2026-11-12T16:15:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-104036-dpio-af-a-rust-native-framework-for-building-disaggregated-data-planes", "url": "https://pretalx.com/kvm-forum-2026/talk/MSMPYU/", "title": "Dpio-af: a rust-native framework for building disaggregated data planes", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "RZBLRG", "name": "Adin Scannell", "avatar": null, "biography": "Adin Scannell is a software engineer at Meta. He has been in and out of the virtualization space for twenty years. He previously co-founded a startup building technology for VM cloning and guest introspection, which was acquired by Google. There, he led the creation and open-sourcing of gVisor and drove many efforts in the virtualization and container space.", "public_name": "Adin Scannell", "guid": "da5d5403-1fb5-52fb-953c-da292f6923d4", "url": "https://pretalx.com/kvm-forum-2026/speaker/RZBLRG/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/MSMPYU/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/MSMPYU/", "attachments": []}], "2": [{"guid": "e1a6ade9-0cec-5791-bfce-89a9c0405bda", "code": "XU7ZP7", "id": 103944, "logo": null, "date": "2026-11-12T09:15:00-07:00", "start": "09:15", "end": "2026-11-12T09:35:00-07:00", "duration": "00:20", "room": "2", "slug": "kvm-forum-2026-103944-in-place-conversion-support-for-confidential-vms", "url": "https://pretalx.com/kvm-forum-2026/talk/XU7ZP7/", "title": "In-place Conversion Support for Confidential VMs", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "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.\n\nThis 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.\n\nThis 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "8ZB7GZ", "name": "Michael Roth", "avatar": null, "biography": "Michael Roth is a member of the Datacenter Linux Kernel and Virtualization Development team at AMD who is currently working on linux guest/hypervisor support for SEV-SNP. He has been working on KVM virtualization for x86 and PowerPC since 2010, and has done a number of KVM Forum talks on various topic throughout that time.", "public_name": "Michael Roth", "guid": "217bdb72-8a63-54d4-8f70-24587e3f20f2", "url": "https://pretalx.com/kvm-forum-2026/speaker/8ZB7GZ/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/XU7ZP7/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/XU7ZP7/", "attachments": []}, {"guid": "e5c9695f-fb4b-5c5d-aeff-802c1f9cbce2", "code": "XZNHGA", "id": 103868, "logo": null, "date": "2026-11-12T09:35:00-07:00", "start": "09:35", "end": "2026-11-12T09:55:00-07:00", "duration": "00:20", "room": "2", "slug": "kvm-forum-2026-103868-state-of-the-state-tracking-memory-conversions-in-guestmemfd", "url": "https://pretalx.com/kvm-forum-2026/talk/XZNHGA/", "title": "State of the State: Tracking Memory Conversions in guest_memfd", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "In-place conversion is the latest core change to guest_memfd (hopefully merged by the time of KVM Forum 2026) [1].\n\nWith 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).\n\nThis change upholds the core purpose of guest_memfd, which is that the host must not be able to access guest private memory.\n\nThis 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].\n\n[1] https://lore.kernel.org/all/20260728-gmem-inplace-conversion-v9-0-35f9aec2aed2@google.com/ \n[2] https://lore.kernel.org/all/CAEvNRgEWOnZqiXMijZqggEi1hm14HxZ++9GpDRXUHqoE4UD6Bg@mail.gmail.com/", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "PDQU8G", "name": "Ackerley Tng", "avatar": "https://pretalx.com/media/avatars/RDTDBP_kpX6G84.webp", "biography": "Ackerley is a software engineer at Google Cloud. His work in the Confidential Computing team revolves around making guest_memfd useful and effective for CoCo VMs.\n\nHe is interested in operating systems, programming languages, and generally, beautiful code.", "public_name": "Ackerley Tng", "guid": "08f36b3e-a0c5-5783-8869-73d8275919a2", "url": "https://pretalx.com/kvm-forum-2026/speaker/PDQU8G/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/XZNHGA/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/XZNHGA/", "attachments": []}, {"guid": "fdb70c84-700e-50f5-8532-2b3de9984f71", "code": "QQWNVD", "id": 103954, "logo": null, "date": "2026-11-12T09:55:00-07:00", "start": "09:55", "end": "2026-11-12T10:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103954-enabling-live-migration-of-tdx-guests", "url": "https://pretalx.com/kvm-forum-2026/talk/QQWNVD/", "title": "Enabling live migration of TDX guests", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThese 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 \u2014 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.\n\nThis talk presents the status of our in-progress KVM/QEMU changes to support TDX's migration interfaces \u2014 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "7FBRHN", "name": "Kishen Maloor", "avatar": null, "biography": "Kishen Maloor is a Linux kernel engineer at Intel, currently working on enabling live migration for TDX guests in KVM and QEMU. He previously added netlink APIs to MPTCP for userspace-driven path management. Before moving to the kernel, he worked on edge and IoT software and standards, representing Intel in industry consortia, and earlier on middleware and frameworks for client devices.", "public_name": "Kishen Maloor", "guid": "2827d312-4a8b-5789-8d9e-eb3b0d5e61f9", "url": "https://pretalx.com/kvm-forum-2026/speaker/7FBRHN/"}, {"code": "9XEQ3Z", "name": "Rick Edgecombe", "avatar": null, "biography": "Rick is a kernel engineer working on TDX, as well as various x86 security and memory technologies.", "public_name": "Rick Edgecombe", "guid": "7a738f8d-58b0-57b2-a3d8-ca40ae01c691", "url": "https://pretalx.com/kvm-forum-2026/speaker/9XEQ3Z/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/QQWNVD/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/QQWNVD/", "attachments": []}, {"guid": "880a4079-faf4-5650-a5a1-2eb018559b22", "code": "HW9V9Y", "id": 104030, "logo": null, "date": "2026-11-12T10:55:00-07:00", "start": "10:55", "end": "2026-11-12T11:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-104030-virtio-vm-paravirtual-kvm-vfio-device", "url": "https://pretalx.com/kvm-forum-2026/talk/HW9V9Y/", "title": "virtio-vm: Paravirtual KVM/VFIO device", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nWe 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 \u201cL2\u201d VMs.\n\nThere 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "PCQP8S", "name": "James Houghton", "avatar": null, "biography": "I work on virtualization at Google, mostly focusing on live migration and memory management.", "public_name": "James Houghton", "guid": "138ee0c1-795c-5c73-a0cc-98dcc49bd4a0", "url": "https://pretalx.com/kvm-forum-2026/speaker/PCQP8S/"}, {"code": "L9CEPC", "name": "Andrei Vagin", "avatar": null, "biography": null, "public_name": "Andrei Vagin", "guid": "59546fac-9c50-5e54-85f8-2ec0fa6e4d60", "url": "https://pretalx.com/kvm-forum-2026/speaker/L9CEPC/"}, {"code": "GE3YPN", "name": "Venkatesh Srinivas", "avatar": null, "biography": null, "public_name": "Venkatesh Srinivas", "guid": "3fac9ae4-7923-5a58-ba94-bb3950f12439", "url": "https://pretalx.com/kvm-forum-2026/speaker/GE3YPN/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/HW9V9Y/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/HW9V9Y/", "attachments": []}, {"guid": "fca486b1-4363-5d21-aab1-212b8c14eaf6", "code": "LVJBQ7", "id": 103774, "logo": null, "date": "2026-11-12T11:25:00-07:00", "start": "11:25", "end": "2026-11-12T11:55:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103774-a-vhost-user-blk-storage-proxy-for-firecracker-microvms-a-local-nvme-write-back-tier-between-the-guest-and-ceph", "url": "https://pretalx.com/kvm-forum-2026/talk/LVJBQ7/", "title": "A vhost-user-blk storage proxy for Firecracker microVMs: a local NVMe write-back tier between the guest and Ceph", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n \nThis 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.\n \nWe will walk through the implementation structure and the design decisions we think generalize beyond our use case:\n \n- 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;\n- 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;\n- flow control: a bounded dirty budget with time-since-last-write destage ordering, applying backpressure through the virtqueue only under sustained overload;\n- building our own minimal backend instead of adopting SPDK, and what that cost/saved us;\n- 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;\n- 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.\n \nWe will close with production results comparing the two architectures: Ceph cluster load, guest-visible write latency, and per-host VM density.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "GGMAJS", "name": "Piotr Bejda", "avatar": "https://pretalx.com/media/avatars/VULYHX_G2K33kM.webp", "biography": "Ex-Google, Colossus TL - multi-purpose storage foundations, got to work on most of its different parts.\nEbpf-based live cloud debugger for compiled languages, first at startup, then at Datadog.\nNow storage lead at Blacksmith.\nDoing data-driven optimizations whenever I find opportunity.", "public_name": "Piotr Bejda", "guid": "000f8c04-a6a7-592b-b947-8ff2df4a6e3e", "url": "https://pretalx.com/kvm-forum-2026/speaker/GGMAJS/"}], "links": [{"title": "A recent blogpost about problems we are solving (but in the talk I would focus on this particular solution)", "url": "https://www.blacksmith.sh/blog/why-i-joined-blacksmith-to-work-on-storage-again", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/LVJBQ7/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/LVJBQ7/", "attachments": []}, {"guid": "deec1da9-aac9-5906-9c8f-f81eee2dfe4b", "code": "TKPCUV", "id": 103923, "logo": null, "date": "2026-11-12T11:55:00-07:00", "start": "11:55", "end": "2026-11-12T12:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103923-dynamic-disk-io-thread-scaling-for-qemu-with-the-io-thread-controller", "url": "https://pretalx.com/kvm-forum-2026/talk/TKPCUV/", "title": "Dynamic disk IO Thread Scaling for QEMU with the io-thread-controller", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn 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.\n\nWe 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "8UTXKH", "name": "Thanos Makatos", "avatar": "https://pretalx.com/media/avatars/LHMKUD_w0UUp9l.webp", "biography": "I'm software engineer at Nutanix, I focus on storage performance and disk I/O virtualization.", "public_name": "Thanos Makatos", "guid": "e011b470-390c-5018-86f8-ac78f977eb9c", "url": "https://pretalx.com/kvm-forum-2026/speaker/8UTXKH/"}], "links": [{"title": "io-thread-controller repo (soon to be populated)", "url": "https://github.com/nutanix/io-thread-controller", "type": "related"}, {"title": "QEMU patches to support dynamic IO worker thread management", "url": "https://github.com/tmakatos/qemu/tree/dev/thread-scaling-upstream", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/TKPCUV/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/TKPCUV/", "attachments": []}, {"guid": "0e47477f-5adb-56ab-9be1-bf690df8000f", "code": "KDRWGB", "id": 103991, "logo": null, "date": "2026-11-12T13:45:00-07:00", "start": "13:45", "end": "2026-11-12T14:15:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103991-gpu-paravirtualization-a-perspective-from-qemu", "url": "https://pretalx.com/kvm-forum-2026/talk/KDRWGB/", "title": "GPU paravirtualization: A perspective from QEMU", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nQEMU 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\u2014such as accidentally breaking Alpha CPU emulation.\n\nIn 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.\n\nThis talk will cover:\n\n* Interactions among foundational concepts: paravirtualization, direct rendering, and address translation.\n* The ecosystem: virtio capability sets, virglrenderer, the macOS Paravirtualized Graphics framework, Rutabaga, and DMA-BUF.\n* Pre-existing QEMU components facing new challenges: display backends, guest memory management, and RCU.\n* Potential features that may be implemented in the future.\n\nThis 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "Z8E3K3", "name": "Akihiko Odaki", "avatar": null, "biography": "Akihiko Odaki began contributing to QEMU to support Linux desktop environments virtualized on macOS running on Apple Silicon, with a focus on macOS GPU paravirtualization. He has since adopted Asahi Linux\u2014a native Linux port for Apple Silicon\u2014as his primary computing environment and has contributed improvements to QEMU/KVM compatibility on the platform.\n\nAlongside his open-source work, Akihiko is a Ph.D. student at the University of Tokyo. His research focuses on processor microarchitecture, using QEMU to analyze AArch64 and RISC-V programs and optimize hardware designs for their execution speed.\n\nHe also maintains QEMU\u2019s igb device emulation, which models an Intel NIC with SR-IOV capability.", "public_name": "Akihiko Odaki", "guid": "67066819-90f6-5bf7-a2e4-4c0705796739", "url": "https://pretalx.com/kvm-forum-2026/speaker/Z8E3K3/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/KDRWGB/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/KDRWGB/", "attachments": []}, {"guid": "be0d4fef-8ba8-5879-b5ed-a3eabb25d7a1", "code": "ZJ33RV", "id": 102428, "logo": null, "date": "2026-11-12T14:15:00-07:00", "start": "14:15", "end": "2026-11-12T14:45:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-102428-virtualization-vs-simulation-use-cases-and-technical-challenges", "url": "https://pretalx.com/kvm-forum-2026/talk/ZJ33RV/", "title": "Virtualization vs. simulation: use cases and technical challenges", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "NDKFFR", "name": "James Nutaro", "avatar": null, "biography": "James Nutaro is a Distinguished R&D Scientist and Group Lead in the Computational Systems Engineering & Cybernetics group at Oak Ridge National Laboratory (ORNL) in Oak Ridge, Tennessee. His research focuses on modeling and simulation methods, with a specific emphasis on systems integration, systems of systems performance assessment, and modeling from data.", "public_name": "James Nutaro", "guid": "a45ec230-f148-5228-8a57-a8f2f1ad2ead", "url": "https://pretalx.com/kvm-forum-2026/speaker/NDKFFR/"}, {"code": "UMGNNF", "name": "Christian Koertje", "avatar": null, "biography": null, "public_name": "Christian Koertje", "guid": "f224e1a4-1df2-5f29-a434-ad90c58514af", "url": "https://pretalx.com/kvm-forum-2026/speaker/UMGNNF/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/ZJ33RV/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/ZJ33RV/", "attachments": []}, {"guid": "1f40b0c4-df42-5ded-8293-1f8ac1ef5d8f", "code": "AWM8WP", "id": 103761, "logo": null, "date": "2026-11-12T15:15:00-07:00", "start": "15:15", "end": "2026-11-12T15:45:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103761-scaling-cpu-overcommit-in-kvm-with-dynamic-mwait-interception-and-coroutine-vcpus", "url": "https://pretalx.com/kvm-forum-2026/talk/AWM8WP/", "title": "Scaling CPU Overcommit in KVM with Dynamic MWAIT Interception and Coroutine vCPUs", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n1. Reclaiming idle capacity \u2014 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.\n2. Cutting the per-vCPU tax \u2014 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 \u00b5s and inter-vCPU switch latency by 1.6 \u00b5s.\n\nBeyond overcommit scaling, a novel sched_ext-based vCPU scheduler is also introduced  to mitigate preemption-induced jitters once host CPUs are fully sold.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "9U8RRG", "name": "Zhimin Feng", "avatar": null, "biography": "I am now working for ByteDance., currently focusing on QEMU/KVM/Virtualization related projects.", "public_name": "Zhimin Feng", "guid": "28d2a783-3eb1-5c1c-9d5f-4d4c83b9fc98", "url": "https://pretalx.com/kvm-forum-2026/speaker/9U8RRG/"}, {"code": "YBY8AA", "name": "Xiangfeng Cai", "avatar": null, "biography": "Xiangfeng is a software engineer at ByteDance, working on the KVM/QEMU virtualization stack that powers the company's large-scale cloud infrastructure.", "public_name": "Xiangfeng Cai", "guid": "5ba2d70a-15a3-591b-9fd9-0159d4bf6b29", "url": "https://pretalx.com/kvm-forum-2026/speaker/YBY8AA/"}, {"code": "GMSXCV", "name": "Ying Fang", "avatar": "https://pretalx.com/media/avatars/AQBTHB_ksVLUNL.webp", "biography": "I am currently working at bytedance as a OS virtualization enginer. Daily works focus on KVM and QEMU and dedicated to enable cloud computing for large scale datacenters.", "public_name": "Ying Fang", "guid": "92a63df8-8619-59dc-b608-1c82063924cd", "url": "https://pretalx.com/kvm-forum-2026/speaker/GMSXCV/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/AWM8WP/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/AWM8WP/", "attachments": []}, {"guid": "c202fb4b-8682-5b95-a71b-db80006bfead", "code": "QPSFWD", "id": 103112, "logo": null, "date": "2026-11-12T15:45:00-07:00", "start": "15:45", "end": "2026-11-12T16:15:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103112-qemu-memory-tiering", "url": "https://pretalx.com/kvm-forum-2026/talk/QPSFWD/", "title": "QEMU memory tiering", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nSince 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). \n 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.\n\nAnother 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).\n\nWe will compare different approaches, comments will be more than welcomed.  It is still an open question on how QEMU should implement its tiering functionality.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "XPQHAZ", "name": "Peter Xu", "avatar": null, "biography": "Red Hat virtualization engineer, working on QEMU/KVM and Linux.", "public_name": "Peter Xu", "guid": "8a450419-78f5-5de6-a959-a00dbd8c4f12", "url": "https://pretalx.com/kvm-forum-2026/speaker/XPQHAZ/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/QPSFWD/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/QPSFWD/", "attachments": []}]}}, {"index": 2, "date": "2026-11-13", "day_start": "2026-11-13T04:00:00-07:00", "day_end": "2026-11-14T03:59:00-07:00", "rooms": {"1": [{"guid": "b045e92b-986b-5984-8727-055d7abf6288", "code": "FQQWZN", "id": 101612, "logo": null, "date": "2026-11-13T08:40:00-07:00", "start": "08:40", "end": "2026-11-13T09:10:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-101612-keynote-qemu", "url": "https://pretalx.com/kvm-forum-2026/talk/FQQWZN/", "title": "Keynote: QEMU", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "LWK9PT", "name": "Alex Benn\u00e9e", "avatar": "https://pretalx.com/media/avatars/BFWUWN_w2KEVlI.webp", "biography": "Long time systems and embedded developer with a side of Dynamic Binary Translation.\nAlex started learning to program in the 80s in an era of classic home computers that allowed you to get down and dirty at the system level. After graduating with a degree in Chemistry he's worked on a variety of projects including Fruit Machines, Line Cards, CCTV recorders and point-to-multipoint wireless microwave systems. \nSince the turn of the century his primary focus has been working with FLOSS platforms, especially Linux. An alumni of Transitive he has a broad experience of cross-platform virtualization as well as a strong background in telecommunications and networking. He leads the QEMU team ensuring the latest features are available so developers can develop and test their code before silicon becomes widely available. He also contributes to the work on VirtIO allowing devices of all types to be efficiently shared with guests.\nA keen Emacs user he will happily answer questions and proselytise for the One True Editor (tm).", "public_name": "Alex Benn\u00e9e", "guid": "306714f1-0670-52bd-85ba-8078e6f07652", "url": "https://pretalx.com/kvm-forum-2026/speaker/LWK9PT/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/FQQWZN/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/FQQWZN/", "attachments": []}, {"guid": "75917fc0-9289-5c00-9ec3-5305ba72aa97", "code": "QWDHGG", "id": 104057, "logo": null, "date": "2026-11-13T09:15:00-07:00", "start": "09:15", "end": "2026-11-13T09:35:00-07:00", "duration": "00:20", "room": "1", "slug": "kvm-forum-2026-104057-kvm-planes-and-virtualization-based-security-the-sum-is-greater-than-the-parts", "url": "https://pretalx.com/kvm-forum-2026/talk/QWDHGG/", "title": "KVM planes and Virtualization-Based Security: the sum is greater than the parts", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "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\u2014certainly 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "TBTHBS", "name": "Paolo Bonzini", "avatar": null, "biography": "Paolo Bonzini works on virtualization for Red Hat, where he is a Distinguished Engineer. He is currently the maintainer of the KVM hypervisor and a contributor and submaintainer for QEMU.", "public_name": "Paolo Bonzini", "guid": "ed550d22-e6f2-56ce-b6b8-f6fd768ab6e5", "url": "https://pretalx.com/kvm-forum-2026/speaker/TBTHBS/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/QWDHGG/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/QWDHGG/", "attachments": []}, {"guid": "d1f7644f-654f-582d-8743-f959e92944a1", "code": "MLPKFB", "id": 103946, "logo": null, "date": "2026-11-13T09:35:00-07:00", "start": "09:35", "end": "2026-11-13T09:55:00-07:00", "duration": "00:20", "room": "1", "slug": "kvm-forum-2026-103946-virtual-secure-mode-on-kvm-planes", "url": "https://pretalx.com/kvm-forum-2026/talk/MLPKFB/", "title": "Virtual Secure Mode on KVM Planes", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "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\npopularity 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\nAI, we see value in VSM on KVM Planes.\n\nVM 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\nand 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.\n \nSome 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "VJNGFM", "name": "Sriram Nambakam", "avatar": "https://pretalx.com/media/avatars/XSDBRK_zmt0HbG.webp", "biography": "I have been a UNIX and Linux enthusiast for more than three decades now and have been contributing to open source especially in the area of identity, security and distributed systems.\n\nFor the past few years, my team at Microsoft has been focused on improving the security of Linux Based systems in Azure, especially in the area of code integrity and confidential computing.\n\nI am currently serving as a Principal Software Architect in the Azure Linux team at Microsoft.", "public_name": "Sriram Nambakam", "guid": "12fa55c9-e278-56e1-ad75-7dabef88e90e", "url": "https://pretalx.com/kvm-forum-2026/speaker/VJNGFM/"}, {"code": "8Z8RND", "name": "James Bottomley", "avatar": null, "biography": "James Bottomley is a Distinguished Engineer at IBM Research where he\nworks on Cloud and Container technology.  He is also Linux Kernel\nmaintainer of the SCSI subsystem. He has been a Director on the Board\nof the Linux Foundation and Chair of its Technical Advisory Board. He\nwent to university at Cambridge for both his undergraduate and\ndoctoral degrees after which he joined AT&T Bell labs to work on\nDistributed Lock Manager technology for clustering. In 2000 he helped\nfound SteelEye Technology, a High availability company for Linux and\nWindows, becoming Vice President and CTO.  He joined Novell in 2008 as\na Distinguished Engineer at Novell's SUSE Labs, Parallels (later Odin)\nin 2011 as CTO of Server Virtualization and IBM Research in 2016.  He has\nbeen active around legal issues in Open Source since 2006.", "public_name": "James Bottomley", "guid": "62f79e95-d673-5427-8c6a-3bf717340ae7", "url": "https://pretalx.com/kvm-forum-2026/speaker/8Z8RND/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/MLPKFB/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/MLPKFB/", "attachments": []}, {"guid": "5cbd2e3a-2d4d-556b-89b8-4937f787592f", "code": "ZB3GWA", "id": 103169, "logo": null, "date": "2026-11-13T09:55:00-07:00", "start": "09:55", "end": "2026-11-13T10:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103169-coconut-svsm-on-kvm-planes-boarding-completed", "url": "https://pretalx.com/kvm-forum-2026/talk/ZB3GWA/", "title": "COCONUT-SVSM on KVM Planes: Boarding Completed?", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nAt 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.\n\nThis 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.\n\nThe 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "NRGGUQ", "name": "J\u00f6rg R\u00f6del", "avatar": "https://pretalx.com/media/avatars/ZFCLBB_lnTsjPW.webp", "biography": "J\u00f6rg is Principal Member of Technical Staff at AMD and the creator and maintainer of the COCONUT-SVSM project. Prior to this, he lead the Confidential Computing efforts at SUSE, working on enabling SEV and related technologies. In this role he implemented major parts of the AMD SEV-ES guest support in the Linux kernel and brought it upstream into kernel 5.10. He is also active in the Linux kernel community as the maintainer for the IOMMU subsystem and a contributor to other areas like KVM or the X86 architecture.", "public_name": "J\u00f6rg R\u00f6del", "guid": "c6d1386a-7b93-56fa-92b7-ddfeccc6c71a", "url": "https://pretalx.com/kvm-forum-2026/speaker/NRGGUQ/"}, {"code": "FBMVLD", "name": "Melody (Huibo) Wang", "avatar": null, "biography": "Melody works for AMD in the Linux kernel team on secure virtualization. Currently she is working on implementing alternate injection for SEV-SNP virtual machines. In the past, Melody had worked on the security of trusted execution environment, including AMD SEV series and Intel SGX. She was specializing in computer system security and privacy, including cloud computing, blockchain, and data privacy.", "public_name": "Melody (Huibo) Wang", "guid": "035b8c9e-7cfa-582e-b4be-345c42a93eb6", "url": "https://pretalx.com/kvm-forum-2026/speaker/FBMVLD/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/ZB3GWA/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/ZB3GWA/", "attachments": []}, {"guid": "dc3d8291-4bf4-5e0f-a396-8cb82fe17bca", "code": "B7ZLZ7", "id": 103830, "logo": null, "date": "2026-11-13T10:55:00-07:00", "start": "10:55", "end": "2026-11-13T11:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103830-kvm-memory-management-from-scratch-the-gmap-rewrite", "url": "https://pretalx.com/kvm-forum-2026/talk/B7ZLZ7/", "title": "KVM memory management from scratch: the gmap rewrite", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\nAs 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.\n\nThus 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.\n\nThis 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "NPRR3R", "name": "Claudio Imbrenda", "avatar": "https://pretalx.com/media/avatars/83QC39_hijcLKH.webp", "biography": "KVM/s390 co-maintainer.", "public_name": "Claudio Imbrenda", "guid": "b488df74-8f1c-542e-b5a6-8ed76c4e38cc", "url": "https://pretalx.com/kvm-forum-2026/speaker/NPRR3R/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/B7ZLZ7/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/B7ZLZ7/", "attachments": []}, {"guid": "7b5fca66-a20b-5ef4-aa05-55d02a9f2332", "code": "LGVNHA", "id": 103770, "logo": null, "date": "2026-11-13T11:25:00-07:00", "start": "11:25", "end": "2026-11-13T11:55:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103770-an-introduction-to-the-amd-root-guest", "url": "https://pretalx.com/kvm-forum-2026/talk/LGVNHA/", "title": "An Introduction to the AMD Root Guest", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "XYMB8T", "name": "Tom Lendacky", "avatar": null, "biography": "Tom Lendacky is a member of the Linux OS group at Advanced Micro Devices where he is responsible for enabling and enhancing support for AMD processor features in the Linux kernel. He is currently working on extending the SEV support in the Linux kernel to further enhance the features and capabilities of SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging). He has spoken at various Linux events, including KVM Forum a few times.", "public_name": "Tom Lendacky", "guid": "5be4b885-2a5d-5636-97e8-64c66ce74e32", "url": "https://pretalx.com/kvm-forum-2026/speaker/XYMB8T/"}, {"code": "TDEXLL", "name": "David Kaplan", "avatar": null, "biography": null, "public_name": "David Kaplan", "guid": "a8a419ad-fec4-511f-9b1a-e19d6c86769e", "url": "https://pretalx.com/kvm-forum-2026/speaker/TDEXLL/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/LGVNHA/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/LGVNHA/", "attachments": []}, {"guid": "1e4ef0b6-30af-500b-b367-83c0270b8e08", "code": "BY8NR3", "id": 105593, "logo": null, "date": "2026-11-13T11:55:00-07:00", "start": "11:55", "end": "2026-11-13T12:25:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-105593-artificial-intuition-lessons-learned-from-vibe-auditing-kvm", "url": "https://pretalx.com/kvm-forum-2026/talk/BY8NR3/", "title": "Artificial Intuition: Lessons Learned From Vibe-Auditing KVM", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nTo 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "SUEASE", "name": "Stefan Teodorescu", "avatar": null, "biography": "Software Engineer in the Kernel Security team at Google", "public_name": "Stefan Teodorescu", "guid": "879dc51b-258e-5f95-8b97-731a54aaa972", "url": "https://pretalx.com/kvm-forum-2026/speaker/SUEASE/"}, {"code": "BJGJVU", "name": "Marcel Busch", "avatar": null, "biography": null, "public_name": "Marcel Busch", "guid": "fb96b6e1-6941-5843-acf2-b61da1714e0e", "url": "https://pretalx.com/kvm-forum-2026/speaker/BJGJVU/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/BY8NR3/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/BY8NR3/", "attachments": []}, {"guid": "d744b9bc-bcb8-5a49-b5b3-73440e8dd888", "code": "UYWQ79", "id": 103971, "logo": null, "date": "2026-11-13T13:45:00-07:00", "start": "13:45", "end": "2026-11-13T14:15:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103971-enabling-confidential-vms-updates-from-the-coconut-svsm-project", "url": "https://pretalx.com/kvm-forum-2026/talk/UYWQ79/", "title": "Enabling Confidential VMs: Updates from the Coconut SVSM Project", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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\u2014most notably a new UEFI variable service that enables SecureBoot.\nWe 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "WDQULX", "name": "Oliver Steffen", "avatar": null, "biography": "I work in Red Hat's Virtualization Team, focusing on confidential virtualization, firmware, and booting.", "public_name": "Oliver Steffen", "guid": "fa14bb53-132b-573b-91ee-74736ef97866", "url": "https://pretalx.com/kvm-forum-2026/speaker/WDQULX/"}, {"code": "S8Z8X8", "name": "Luigi Leonardi", "avatar": null, "biography": "Luigi is a Software Engineer in Red Hat virtualization team. His main focus are confidential computing and firmware.", "public_name": "Luigi Leonardi", "guid": "973035fa-3364-5aa5-a479-5415d6a3e9f9", "url": "https://pretalx.com/kvm-forum-2026/speaker/S8Z8X8/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/UYWQ79/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/UYWQ79/", "attachments": []}, {"guid": "3dfed670-101e-5133-87ed-7fd21cf5ac46", "code": "CFSAUG", "id": 103119, "logo": null, "date": "2026-11-13T15:15:00-07:00", "start": "15:15", "end": "2026-11-13T15:45:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-103119-one-ring-one-crash-breaking-hypervisors-from-the-guest", "url": "https://pretalx.com/kvm-forum-2026/talk/CFSAUG/", "title": "One ring, one crash: breaking hypervisors from the guest", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThreat 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.\n\nWhat 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.\n\nWhat 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.\n\nWhat 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.\n\nScope 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "ZFLVDT", "name": "Anatol Belski", "avatar": "https://pretalx.com/media/avatars/JS9CGP_HLPfZfp.webp", "biography": "Anatol Belski is a Senior Software Engineer at Microsoft working on Linux virtualization and cloud infrastructure. He contributes to various OSS projects, including Cloud Hypervisor. He is interested in virtio, virtual block devices, disk image formats, and virtualization testing. He is the author of Virtio Villain, a testing framework for virtio device implementations across several VMMs.", "public_name": "Anatol Belski", "guid": "9ce16280-dbc2-5cb8-9495-28cf3b2e6244", "url": "https://pretalx.com/kvm-forum-2026/speaker/ZFLVDT/"}], "links": [{"title": "Virtio Villain is a guest side fault injection harness for virtio device models", "url": "https://github.com/weltling/virtio-villain", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/CFSAUG/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/CFSAUG/", "attachments": []}, {"guid": "4d1088a4-c766-5444-a4a9-d04cde8ca75b", "code": "7PDWPC", "id": 98674, "logo": null, "date": "2026-11-13T15:45:00-07:00", "start": "15:45", "end": "2026-11-13T16:15:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-98674-backend-assisted-observability-for-diagnosing-windows-vm-failures-in-cloud-environments", "url": "https://pretalx.com/kvm-forum-2026/talk/7PDWPC/", "title": "Backend-Assisted Observability for Diagnosing Windows VM Failures in Cloud Environments", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nIn 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "SUTGQS", "name": "Zhengrong Li", "avatar": null, "biography": "I am responsible for Windows-related initiatives at Alibaba Cloud, including planning, development, and support for Windows workloads. In this role, I have worked extensively on diagnosing difficult Windows VM failures in production, with a focus on backend-assisted observability for opaque issues such as boot failures, hangs, and BSODs.", "public_name": "Zhengrong Li", "guid": "7c8cb271-84cb-54d0-9e11-dbbc3a732149", "url": "https://pretalx.com/kvm-forum-2026/speaker/SUTGQS/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/7PDWPC/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/7PDWPC/", "attachments": []}, {"guid": "ea4cdb85-d8fd-594e-99b6-fd030befa9aa", "code": "ZUV9VA", "id": 104060, "logo": null, "date": "2026-11-13T16:15:00-07:00", "start": "16:15", "end": "2026-11-13T16:45:00-07:00", "duration": "00:30", "room": "1", "slug": "kvm-forum-2026-104060-securing-the-vmm-against-speculative-attacks-using-x86-pkru", "url": "https://pretalx.com/kvm-forum-2026/talk/ZUV9VA/", "title": "Securing the VMM Against Speculative Attacks Using x86 PKRU", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nExisting 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.\n\nIn 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.\n\n\nWe will discuss:\n\n- The Guest-to-Host Threat Model: Why VMM userspace execution handling untrusted guest inputs remains a critical attack surface for speculative execution.\n- Limitations of Existing Defenses: Why frequent IBPB flushing is too costly, and why guest_memfd leaves gaps when guest memory must remain mapped.\n- The PKRU Defense Paradigm: How unprivileged, low-latency protection key switching can isolate access boundaries and neutralize speculative gadgets on the fly.\n- Deployment & Practical Impact: Hardening KVM/QEMU infrastructure against guest-originated attacks with minimum runtime overhead, noting how exclusive vCPU-to-pCPU pinning\u2014standard in public cloud \"slice of hardware\" offerings\u2014naturally completes this mitigation strategy.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "QMZXAZ", "name": "Jacky Li", "avatar": null, "biography": "Kernel Developer.", "public_name": "Jacky Li", "guid": "b57106db-58a8-562d-a109-c90897ee9983", "url": "https://pretalx.com/kvm-forum-2026/speaker/QMZXAZ/"}, {"code": "GWBBR3", "name": "Mingwei Zhang", "avatar": null, "biography": "Software engineer in Google", "public_name": "Mingwei Zhang", "guid": "7a966aa9-14ea-5330-842c-90fdd3c5df57", "url": "https://pretalx.com/kvm-forum-2026/speaker/GWBBR3/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/ZUV9VA/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/ZUV9VA/", "attachments": []}], "2": [{"guid": "33abd4e2-5ddb-5b89-814c-0ff80ed96709", "code": "NYBVPU", "id": 103612, "logo": null, "date": "2026-11-13T09:15:00-07:00", "start": "09:15", "end": "2026-11-13T09:35:00-07:00", "duration": "00:20", "room": "2", "slug": "kvm-forum-2026-103612-testing-device-passthrough-an-introduction-to-vfio-selftests-and-libvfio", "url": "https://pretalx.com/kvm-forum-2026/talk/NYBVPU/", "title": "Testing Device Passthrough: An Introduction to VFIO selftests and libvfio", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "VFIO and IOMMUFD enable safe, secure, and performant assignment of peripheral\ndevices to user-space applications and virtual machines. As the complexity of\ndevice passthrough has evolved, so has the need for a dedicated testing\ninfrastructure. In this talk, we introduce VFIO selftests, a newly integrated\ntest suite located in tools/testing/selftests/vfio. We will explore the initial\nmotivation behind its creation: specifically, the need for standardized, low-\nlevel validation of VFIO and IOMMUFD UAPIs with real devices, real DMA\nactivity, and real interrupts.\n\nA key feature of VFIO selftests is its built-in driver framework that enables\ntests to trigger DMA and interrupts from a range of different devices in a\ngeneric way. We will dive into the architecture of this driver framework and\nexplore how it simplifies interacting with PCI endpoints, abstracting away\ncomplex setup tasks so developers can focus on testing the kernel, not dealing\nwith devices.\n\nFinally, we will discuss the interaction between VFIO and KVM selftests. Beyond\ntesting VFIO in isolation, the entirety of the VFIO selftests routines are\npackaged into a reusable library: libvfio. While KVM selftests already provide\na comprehensive environment for testing KVM behavior, testing KVM and VFIO\ninteractions (e.g. irqbypass) has historically been challenging. By linking\nagainst libvfio, KVM selftests can easily use all the low-level VFIO setup\nroutines and the driver framework itself.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "LP3MMT", "name": "David Matlack", "avatar": null, "biography": "David is a Software Engineer at Google that has been working on KVM and virtualization for over 10 years, with a recent focus on Device Virtualization and Live Update technologies. David is currently the maintainer for VFIO selftests in the Linux Kernel.", "public_name": "David Matlack", "guid": "f0e17e30-fff1-56bb-95f0-d709b674f969", "url": "https://pretalx.com/kvm-forum-2026/speaker/LP3MMT/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/NYBVPU/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/NYBVPU/", "attachments": []}, {"guid": "0e5e6d8e-a043-5911-be56-37ecfc3b6a14", "code": "CEUSUL", "id": 103608, "logo": null, "date": "2026-11-13T09:35:00-07:00", "start": "09:35", "end": "2026-11-13T09:55:00-07:00", "duration": "00:20", "room": "2", "slug": "kvm-forum-2026-103608-turning-an-ethernet-controller-into-a-dma-engine-for-vfio-selftests", "url": "https://pretalx.com/kvm-forum-2026/talk/CEUSUL/", "title": "Turning an ethernet controller into a DMA engine for VFIO selftests", "subtitle": "", "track": null, "type": "Short talk", "language": "en", "abstract": "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.\n\nThis 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "WWQ9TC", "name": "Josh Hilke", "avatar": null, "biography": "KVM engineer @ Google", "public_name": "Josh Hilke", "guid": "95ffdd1c-9d66-59e2-ba2e-8c5762057936", "url": "https://pretalx.com/kvm-forum-2026/speaker/WWQ9TC/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/CEUSUL/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/CEUSUL/", "attachments": []}, {"guid": "6a2c38ca-272c-58a0-b115-5a8726d0b0f0", "code": "HGLBEK", "id": 98390, "logo": null, "date": "2026-11-13T09:55:00-07:00", "start": "09:55", "end": "2026-11-13T10:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-98390-building-a-virtio-serial-fpga-device", "url": "https://pretalx.com/kvm-forum-2026/talk/HGLBEK/", "title": "Building a virtio-serial FPGA device", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThis 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.\n\nFinally, 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "FFRKZG", "name": "Stefan Hajnoczi", "avatar": null, "biography": "Stefan works on QEMU and Linux VIRTIO drivers in Red Hat's Virtualization team. He focuses on storage and has worked on virtiofs, virtio-vsock, and tracing in the past. A QEMU contributor since 2010, he organizes open source internships for QEMU and is part of QEMU's Technical Leadership Committee.", "public_name": "Stefan Hajnoczi", "guid": "4515bd9a-efc4-5186-b933-cbbac8f29921", "url": "https://pretalx.com/kvm-forum-2026/speaker/FFRKZG/"}], "links": [{"title": "Blog series", "url": "https://blog.vmsplice.net/2026/01/building-virtio-serial-fpga-device-part.html", "type": "related"}, {"title": "Code", "url": "https://gitlab.com/stefanha/virtio-serial-fpga", "type": "related"}], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/HGLBEK/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/HGLBEK/", "attachments": []}, {"guid": "2946e9d0-2cb6-538b-8b40-b76c81e1662b", "code": "7NLBGB", "id": 103006, "logo": null, "date": "2026-11-13T10:55:00-07:00", "start": "10:55", "end": "2026-11-13T11:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103006-nvidia-vgpu-towards-zero-copy-live-migration", "url": "https://pretalx.com/kvm-forum-2026/talk/7NLBGB/", "title": "NVIDIA vGPU: Towards zero-copy live migration", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "**Abstract**\n--------------\nVFIO 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.\n \nThis 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.\n \nWe 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.\n \nFinally, 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.\n\n**Audience takeaways**\n---------------------------\nAttendees 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "3USWJY", "name": "Vinayak Kale", "avatar": "https://pretalx.com/media/avatars/YPXVQN_i9QaSzL.webp", "biography": "Vinayak Kale is a Senior Systems Software Engineer at NVIDIA where he focuses on NVIDIA vGPU driver development on KVM-based hypervisors. Vinayak specializes in live-migration optimizations for NVIDIA vGPU driver stack.", "public_name": "Vinayak Kale", "guid": "e8b6de9b-b247-51b1-919e-69fb45344b30", "url": "https://pretalx.com/kvm-forum-2026/speaker/3USWJY/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/7NLBGB/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/7NLBGB/", "attachments": []}, {"guid": "34771469-ba54-55dd-8145-afa8d2d9c655", "code": "J7SQCV", "id": 100073, "logo": null, "date": "2026-11-13T11:25:00-07:00", "start": "11:25", "end": "2026-11-13T11:55:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-100073-optimized-switchover-timing-for-live-migration-of-memory-intensive-workloads", "url": "https://pretalx.com/kvm-forum-2026/talk/J7SQCV/", "title": "Optimized Switchover Timing for Live Migration of Memory-Intensive Workloads", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "Most live migrations just work: pre-copy converges, QEMU hits its downtime target, and nobody notices. The painful ones are growing more common \u2014 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.\n\nToday's convergence policies \u2014 static timeouts, stepwise downtime ramps, iteration-counter schedules, and naive remaining-bytes heuristics \u2014 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?\n\nLi 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.\n\nRecently 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\u00d7 lower switchover downtime with less variance; gains are workload-dependent and we discuss where the policy helps most.\n\n**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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "XZCZXP", "name": "Aseef Imran", "avatar": "https://pretalx.com/media/avatars/V8F9NW_tJLuj6N.webp", "biography": "Aseef is a Software Engineer at Red Hat, where he works on KubeVirt. He is an active upstream contributor to the project. Aseef holds a Bachelor's and Master's degree in Computer Science from Boston University.", "public_name": "Aseef Imran", "guid": "ae0303a6-4984-50e2-ba53-27095812cb81", "url": "https://pretalx.com/kvm-forum-2026/speaker/XZCZXP/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/J7SQCV/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/J7SQCV/", "attachments": []}, {"guid": "b29e187f-df6f-522f-92ff-ac3471e29298", "code": "BCYMLB", "id": 103764, "logo": null, "date": "2026-11-13T11:55:00-07:00", "start": "11:55", "end": "2026-11-13T12:25:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103764-ept-based-cow-and-incremental-snapshot-for-agentic-sandbox-memory-oversubscription", "url": "https://pretalx.com/kvm-forum-2026/talk/BCYMLB/", "title": "EPT-Based CoW and Incremental Snapshot for Agentic Sandbox Memory Oversubscription", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\nHowever, there are two fundamental gaps in the current virtualization infrastructure:\n- 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.\n- 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.\n\nTo 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "BQXXBM", "name": "Hao Hong", "avatar": null, "biography": "Bytedance Virtualization Engineer.", "public_name": "Hao Hong", "guid": "26aff556-c49c-5112-a84c-680c5fba2f82", "url": "https://pretalx.com/kvm-forum-2026/speaker/BQXXBM/"}, {"code": "HSNNGK", "name": "Zhengyu Zhao", "avatar": null, "biography": "Virtualization Engineer at ByteDance", "public_name": "Zhengyu Zhao", "guid": "c3fdcecb-c33b-528a-a05b-8dd45c99ede5", "url": "https://pretalx.com/kvm-forum-2026/speaker/HSNNGK/"}, {"code": "7GTHNV", "name": "Issac Hai", "avatar": null, "biography": "Bytedance Virtualization Engineer.", "public_name": "Issac Hai", "guid": "7b94aa45-7541-5453-bbd8-23536da2fc5d", "url": "https://pretalx.com/kvm-forum-2026/speaker/7GTHNV/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/BCYMLB/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/BCYMLB/", "attachments": []}, {"guid": "24ca2a7e-8695-585e-ad6d-48ea4c9b1ff3", "code": "XKYJWR", "id": 104038, "logo": null, "date": "2026-11-13T13:45:00-07:00", "start": "13:45", "end": "2026-11-13T14:15:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-104038-virtio-win-drivers-and-qemu-kvm-windows-support-weather-report", "url": "https://pretalx.com/kvm-forum-2026/talk/XKYJWR/", "title": "virtio-win drivers and QEMU/KVM Windows support weather report", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "In this session, I will discuss several topics related to Windows support in QEMU/KVM:\n\n- virtio-win project news and future directions: from virtio hardware support to new Windows drivers.\n- HCK-CI test framework: from driver certification to a general CI platform for Windows guests, including functional and performance testing.\n- Other Windows guest topics, ranging from VBS to using AI for Windows guest debugging.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "P3JSMQ", "name": "Yan Vugenfirer", "avatar": "https://pretalx.com/media/avatars/SYQ7AU_gHlhBli.webp", "biography": "Yan Vugenfirer is a senior principal SW engineer at Red Hat and a maintainer of the virt-win project. Yan has been enabling Windows guests' operation in QEMU/KVM environment for more than 15 years.", "public_name": "Yan Vugenfirer", "guid": "7af8a8cb-a986-5848-a63c-9e8b40f9353e", "url": "https://pretalx.com/kvm-forum-2026/speaker/P3JSMQ/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/XKYJWR/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/XKYJWR/", "attachments": []}, {"guid": "ef8ccfd0-b22f-5b23-b4a1-ba7177ed80a6", "code": "KP7PP9", "id": 104035, "logo": null, "date": "2026-11-13T14:15:00-07:00", "start": "14:15", "end": "2026-11-13T14:45:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-104035-client-virtualisation-with-qemu-on-windows-and-macos", "url": "https://pretalx.com/kvm-forum-2026/talk/KP7PP9/", "title": "Client virtualisation with QEMU on Windows and macOS", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nThe state of macOS as a guest on Arm (vmapple) and TCG will be covered a bit but won't be central to the talk.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "S7YFLA", "name": "Mohamed Mediouni", "avatar": null, "biography": "Virtualization engineer.", "public_name": "Mohamed Mediouni", "guid": "3d6aa2af-9a71-5c6c-a6b8-0467a7f0f2c5", "url": "https://pretalx.com/kvm-forum-2026/speaker/S7YFLA/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/KP7PP9/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/KP7PP9/", "attachments": []}, {"guid": "89027e97-4108-5653-9686-586cc416cb31", "code": "EDDF3C", "id": 103797, "logo": null, "date": "2026-11-13T15:15:00-07:00", "start": "15:15", "end": "2026-11-13T15:45:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103797-hardware-accelerated-cross-architecture-virtual-machines", "url": "https://pretalx.com/kvm-forum-2026/talk/EDDF3C/", "title": "Hardware-Accelerated Cross-Architecture Virtual Machines", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "Can hardware-assisted virtualization be used even when host and guest architectures differ?\n\nThe 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.\n\nThis 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.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "FNFEVB", "name": "Steffen Eiden", "avatar": null, "biography": "Steffen is a kernel/KVM developer with a strong focus on the s390 architecture and Hardware-Accelerated Cross-Architecture Virtual Machines.", "public_name": "Steffen Eiden", "guid": "83851a63-4050-5baa-a44c-714a6a9d68bd", "url": "https://pretalx.com/kvm-forum-2026/speaker/FNFEVB/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/EDDF3C/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/EDDF3C/", "attachments": []}, {"guid": "23d5b481-cf54-5958-b21b-c40ad71e7674", "code": "LXYZ39", "id": 101372, "logo": null, "date": "2026-11-13T15:45:00-07:00", "start": "15:45", "end": "2026-11-13T16:15:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-101372-from-single-binary-to-heterogeneous-emulation", "url": "https://pretalx.com/kvm-forum-2026/talk/LXYZ39/", "title": "From Single-binary to Heterogeneous emulation", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "Last year, we presented our work in progress on single-binary. It's now\navailable upstream (or should be soon) as 'qemu-system' and supports\narchitectures [arm, aarch64, microblaze]. Now we showed this approach could work,\nwe have new challenges lying ahead of us with Heterogeneous emulation.\n\nIn this presentation, we'll first come back on what we implemented with\nthe single-binary, and which value it brings to the QEMU project. Then,\nwe'll present what is heterogeneous emulation and the new problems we\nneed to solve. Finally, we'll present our vision for solving them in the\nfuture.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "ALZGTG", "name": "Pierrick Bouvier", "avatar": null, "biography": "Software engineer at Qualcomm working on QEMU for hexagon and heterogeneous emulation.", "public_name": "Pierrick Bouvier", "guid": "e0d8ab31-69fc-5e9d-9239-7420111015ef", "url": "https://pretalx.com/kvm-forum-2026/speaker/ALZGTG/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/LXYZ39/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/LXYZ39/", "attachments": []}, {"guid": "4d004c26-4fc5-5513-b5d9-193b0f8aa662", "code": "UGZ9WN", "id": 103151, "logo": null, "date": "2026-11-13T16:15:00-07:00", "start": "16:15", "end": "2026-11-13T16:45:00-07:00", "duration": "00:30", "room": "2", "slug": "kvm-forum-2026-103151-x64echo-native-speed-c-library-pass-through-for-qemu-user-mode", "url": "https://pretalx.com/kvm-forum-2026/talk/UGZ9WN/", "title": "X64Echo: Native-Speed C++ Library Pass-through for QEMU User-Mode", "subtitle": "", "track": null, "type": "Talk", "language": "en", "abstract": "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.\n\nBox64 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.\n\nQEMU-X64Echo builds on our [Lorelei]([url](https://www.youtube.com/watch?v=_jioQFm7wyU)) work from last year, whose dlcall plugin interface and plugin are already upstream in QEMU.\n\nThe 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\u00d7 the throughput of full emulation on compute-heavy library work, and 29\u00d7 on a graphics-heavy QtWidgets workload.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"code": "VUBNC7", "name": "Ziyang Zhang", "avatar": null, "biography": "A postgraduate student at Shanghai Jiao Tong University, currently focusing on contributing to the software ecosystem of the RISC-V platform.", "public_name": "Ziyang Zhang", "guid": "b4d1afdb-b2fd-5bf9-8343-8e747c1800ad", "url": "https://pretalx.com/kvm-forum-2026/speaker/VUBNC7/"}], "links": [], "feedback_url": "https://pretalx.com/kvm-forum-2026/talk/UGZ9WN/feedback/", "origin_url": "https://pretalx.com/kvm-forum-2026/talk/UGZ9WN/", "attachments": []}]}}]}}}