Hi,You are correct, PCI is not a requirement here
1. Possible security issues - VirtIO devices are PCI bus masters, thusWell, that is wrong. virtio doesn't require pci. There are other
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)
transports (mmio, ccw), and it should be possible to create a xen
specific transport which uses grant tables properly.
Seems there evenAnd even more, that was also raised at Linux Plumbers
was an attempt to implement that in 2011, see
https://wiki.xenproject.org/wiki/Virtio_On_Xen
Yes, this is true. We also discussed virtio with Xen4. Most of the PV drivers a guest uses at the moment are Xen PV drivers,You are not forced to use qemu, you can certainly create an alternative
e.g. net,
block, console, so only virtio-gpu will require QEMU to run.
host side implementation (and still use on the existing virtio guest
drivers).
Whenever writing a xenbus implementation for both guest and host orWell, I do agree that long term virtio might be a better choice.
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.
cheers,Thank you,
Gerd