To join this session live please go to:
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.