On Wed, Mar 7, 2018 at 6:13 AM, Volo M. <v...@vovs.net> wrote: > Hi Devs, > > Could you please help me to identify right way to start using Virtio > drivers for Xen guests >
*HiThis 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 <https://www.xenproject.org/downloads/windows-pv-drivers.html>and more info at: https://www.xenproject.org/developers/teams/windows-pv-drivers.html <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://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.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems/15>https://www.qubes-os.org/doc/networking/ <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 <https://lists.gt.net/xen/devel/318380>Christopher*
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
