(+ Stefano and Wei)
Hi,
On 02/27/2018 12:40 PM, Oleksandr Andrushchenko wrote:
Please find some more clarifications on VirtIO use with Xen (I would like to thank Xen community for helping with this)
- 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
- 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.
- 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)
I don't think the support of PCI configuration space emulation for PVH would help there. The plan is to emulate in Xen, QEMU is still out of the equation there.
- 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. Although this use case would work on x86 it will require additional changes to get this running on ARM, which is my target platform.
All type of guests but x86 HVM are not using QEMU for device emulation.
I would even be stronger here. Using QEMU would require a significant amount of engineering to make it work and increase the cost of safety certification for automotive use cases. So IHMO, the Xen PV display solution is the best.
The protocol was accepted and merged in Xen 4.9. This the standard way to have para-virtualized display for guests on Xen. Having the driver merged in Linux would help user to get out-of-box display in guest.
Cheers,