[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen Virtio Drivers





On Wed, Mar 7, 2018 at 6:13 AM, Volo M. <vm@xxxxxxxx> wrote:
Hi Devs,

Could you please help me to identify right way to start using Virtio drivers for Xen guests

Hi


This reply might not be the answer that you’re looking for, but it may be helpful for the next person arriving via searching with a similar Virtio driver query.

If you can, using the native Xen device drivers in your Windows VM is preferable to using Virtio, and there’s a driver set available at: https://www.xenproject.org/downloads/windows-pv-drivers.html

and more info at: https://www.xenproject.org/developers/teams/windows-pv-drivers.html

Alternatively, Citrix’s XenServer also has a set of Xen PV drivers for Windows VMs.


Virtio's design requires that the domain where the Virtio device is emulated (where QEMU is running) has full privileges over the VM using the Virtio driver -- ie. is able to map any memory inside that VM. This requirement is contrary to the security model of a type-1 hypervisor such as Xen, and is not necessary: Xen's native device drivers are performant and don't need it, and they are compatible with deprivileged Driver Domains.

Driver domains are important for many Xen deployments -- for example, OpenXT and Qubes OS use network driver domains:
https://wiki.xenproject.org/wiki/Driver_Domain
https://www.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems/15
https://www.qubes-os.org/doc/networking/

In addition to security architecture, there is a question of performance:
the Virtio protocols are optimized for -- and can work well with -- hosted Type-2 hypervisors, but being implemented in QEMU they tend to become a performance bottleneck in Xen deployments where Dom0 is usually only one of many domains, and possibly not the largest.

Significant development effort on Xen has gone into isolating and deprivileging the QEMU device emulator (stubdomains, dm_ops, dropping privileges, non-root QEMU, SELinux and XSM policy, ...) to reduce attack surface.
Running VMs without QEMU at all whenever possible is a valued capability.

Finally, although Virtio is often presented as a paravirtualized solution, it requires an emulation infrastructure that is not otherwise necessary - and so it is not compatible with PV and PVH guests on x86, or at all on ARM, because of this requirement.


A reference to a related earlier discussion thread:

https://lists.gt.net/xen/devel/318380


Christopher


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.