Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Julien Grall]

(+ 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)
>
> 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)
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.

> 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.
> 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,

--
Julien Grall