On 03/01/2018 10:26 AM, Gerd Hoffmann wrote:
Hi,
1. Possible security issues - VirtIO devices are PCI bus masters, thus
allowing real device (running, for example, in untrusted driver domain)
to get control over guest's memory by writing to its memory
2. VirtIO currently uses GFNs written into the shared ring, without Xen
grants support. This will require generic grant-mapping/sharing layer
to be added to VirtIO.
3. VirtIO requires QEMU PCI emulation for setting up a device. Xen PV
(and PVH) domains don't use QEMU for platform emulation in order to
reduce attack surface. (PVH is in the process of gaining PCI config
space emulation though, but it is optional, not a requirement)
Well, that is wrong. virtio doesn't require pci. There are other
transports (mmio, ccw), and it should be possible to create a xen
specific transport which uses grant tables properly.
You are correct, PCI is not a requirement here
Seems there even
was an attempt to implement that in 2011, see
https://wiki.xenproject.org/wiki/Virtio_On_Xen
And even more, that was also raised at Linux Plumbers
Conference 2013 [1]. But still, there is no implementation
available
4. Most of the PV drivers a guest uses at the moment are Xen PV drivers,
e.g. net,
block, console, so only virtio-gpu will require QEMU to run.
You are not forced to use qemu, you can certainly create an alternative
host side implementation (and still use on the existing virtio guest
drivers).
Yes, this is true. We also discussed virtio with Xen
community, Stefano Stabellini says:
"the issues with virtio are (in order of seriousness):
1) virtio assumes that the backend is able to map any page in memory
In other words, it is not possible to do driver domains with virtio
2) virtio doesn't work with PV guests, only HVM (I think PVH would have
the same issue)
Virtio does synchronous IO emulation. QEMU for PV guests is not capable
of handling synchronous IO requests. The infratructure is just not
there.
3) virtio performance is poor with Xen
There are multiple reasons for this, but the main one is that the
backends are in QEMU, running in Dom0. They become the bottleneck
quickly.
"
Whenever writing a xenbus implementation for both guest and host or
writing a virtio implementation for the host only is better -- dunno.
The virtio path obviously needs some infrastructure work for virtio
support in Xen, which may pay off long term. Your call.
Well, I do agree that long term virtio might be a better choice.
But at the moment I still tend to have a dedicated Xen PV DRM
implementation.
That being said, I would kindly ask DRI community to review
the driver and consider it for inclusion.
cheers,
Gerd
Thank you,
Oleksandr Andrushchenko
[1] https://www.youtube.com/watch?v=FcVDHBQInxA
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
