KVM Forum 2020

Being able to craft a detailed virtual topology for a VM may be crucial for achieving good performance. But it is also risky, as interfaces become more complex, and an inconsistent configuration may be selected, causing more harm than good.

E.g., it would be good to be able to specify the size of caches, for cases when some software (e.g., glibc) inside the VM checks it and decides whether or not to enable some optimizations depending right on that.

On the other hand, even just defining the vCPUs topology (threads, cores, NUMA nodes, etc) may lead to less stable or outright worse performance, if the vCPUs and the memory of the VM are not properly pinned at the host level.

In this talk, we will show some first-hand examples, we will outline what is currently there in Linux, libvirt and QEMU and we will discuss if it is possible to improve things even further.

Secure VM technology on multiple architectures has been introduced in the last few years and is slowly gaining ground. The goal of protecting VMs against accesses and manipulation from the hypervisor can be achieved in many ways. However the challenges to get a secure VM up and running are mostly the same no matter the architecture and secure VM technology.  Let's have a look at the goals that secure VMs want to achieve, the challenges that need to be overcome to run them and how the architectures solved them. Also let's try to have a look into the future which will bring us secure VM migration, dumping and more device support and try to anticipate the challenges that are still waiting.  If we take a step back and have a look at the problems that are common to all architectures we might be able to find a common solution.

Despite virtualisation hardware being implemented in all arm64 Android devices, it is seldom available to KVM and instead tends to run bespoke payloads targeting security and data isolation.

The Android-KVM project at Google aims to extend upstream arm64 KVM to cater for the requirements of mobile guest payloads. Of critical importance is the notion that the host cannot access guest memory without the explicit permission of that guest. This requires a split between the KVM code at EL2 and the host kernel at EL1, along with standardised communication between the host and its guests for mutually controlled shared memory instantiation and a degree of portability between hypervisor implementations.

This presentation will offer a quick tour of the arm64 virtualisation architecture before diving into some of the challenges and open problems that we have faced while enabling KVM for Android.

Solid-state storage devices with request latencies of less than 10 microseconds pose challenges for virtualization. Even small overheads result in a visible reduction of I/O performance. Solving this requires changes to the I/O stack.

This talk covers recommended tuning and current work on improving I/O performance for QEMU guests with NVMe drives.

The first part to achieving good I/O performance is to ensure that the guest is taking advantage of multicore and NUMA effectively. This involves both manual tuning and recently added optimizations for getting the most out of the hardware.

The second part is efficient I/O request submission and completion. Traditionally this involved vmexits and eventfds, but improvements to QEMU's AioContext polling can eliminate them and achieve much higher performance.

Come find out how close to bare metal performance QEMU gets!

First investigations about Kernel Address Space Isolation (ASI) were presented at Linux Plumber and KVM Forum last year. Kernel Address Space Isolation aims to mitigate some cpu hyper-threading data leaks possible with speculative execution attacks (like L1 Terminal Fault (L1TF) and Microarchitectural Data Sampling (MDS)). In particular, Kernel Address Space Isolation will provide a separate kernel address space for KVM when running virtual machines, in order to protect against a malicious guest VM attacking the host kernel using speculative execution attacks.

Several RFCs for implementing this solution have been submitted. This presentation will describe the current state of the Kernel Address Space Isolation proposal with focusing on its usage with KVM, in particular the page table mapping requirements and the performance impact.

A Q&A panel discussion on a variety of topics (technical and non-technical) related to KVM, QEMU, securing virtual machines, and more. The discussion will be for about an hour. Topics will be chosen based on several sources: prepared list, audience questions on a live Etherpad, or interesting tangents based on live discussion.

Live Etherpad link - https://etherpad.opendev.org/p/KVMForum_2020_Panel