Session Abstract
Virtio is a framework that specifies how certain class of IO devices can be accessed in virtual environments. Virtio devices are typically implemented in software, which has a front-end portion that runs in guest OS context and a backend portion which runs in a context outside of that guest OS.
Session Speakers
Srivatsa Vaddagiri
Qualcomm, Principal Engineer
Srivatsa Vaddagiri works as Principal Engineer at Qualcomm Innovation Center in<br /> Bangalore, India. He has over 20 years of experience working with various Unix<br /> kernels, including AIX and Linux. His Linux kernel contributions include cpu<br /> hotplug support and cgroup-aware extensions to CPU scheduler. At Qualcomm,<br /> Srivatsa's focus includes improving Linux kernel used in automotive products and<br /> virtio development on a Type-1 hypervisor. Srivatsa holds a MS degree in<br /> Software systems from BITS, Pilani.<br />
To join this session live please go to:
-
Zoom link: https://zoom.us/j/416137389
-
YouTube link: https://youtu.be/CCm7yC2rBP8
Description:
Virtio is a framework that specifies how certain class of IO devices can be accessed in virtual environments. Virtio devices are typically implemented in software, which has a front-end portion that runs in guest OS context and a backend portion which runs in a context outside of that guest OS. In case of Type-2 hypervisor like KVM, backend portion runs in the context of a VMM (Qemu, LKVM etc) or in some cases KVM host kenrel itself. In case of Type-1 hypervisors like Xen or ACRN, backend runs in the context of another guest OS.
A crucial aspect of Virtio is memory access provided for backends. Typically backends have read/write access to complete guest OS memory that is hosting the front-end counterpart. Such wholesale access to memory is not desirable when a guest OS is running security-sensitive applications. It is desireable to restrict access for backend only to the regions required. How can that be best accomplished while still adhering to the Virtio specification?
This discussion is based on Qualcomm’’s efforts to implement virtio for a Linux guest OS running on a Type-1 hypervisor. Frontend and backend portions of virtio run in separate guest OS contexts. A very small portion of memory is shared between the two guest OS. We present the changes done to virtio front-end drivers to accomodate the memory-access limitations for backends. A further limitation addressed is lack of support in hypervisor to trap virtio config space access and have that be handled in backend. Instead suitable changes are discussed how virtio-mmio transport can accommodate a message passing mechanism. Finally we present the need for a new backend implementation that is hypervisor agnostic and can handle various limitations presented by different hypervisors.
