Re: Virtio Xen (WAS: Re: [Linux] [ARM] Granting memory obtained from the DMA API)

[Simon Leiner <simon@xxxxxxxxx>]

Hi Julien,

On 25.08.20 15:02, Julien Grall wrote:
> May I ask why did you create a new transport rather than using the
> existing one?

We wanted a mechanism for dynamically creating virtio devices at 
runtime. I looked at virtio-mmio briefly and it seemed to me that a lot 
of things would have to be known in advance (how many devices are 
there? How much memory do they need? Where does the memory range for 
virtio-mmio start on the device domain?). So after reading a bit about 
Xen and how the classic split drivers work, I figured building a split 
driver for virtio was the way to go. The basic principle is really 
simple:

 - Using grants to share memory for the virtqueues
 - Using event channels as a queue notification mechanism
 - All state handling and other information exchange (like number of 
   queues, grant refs, event channel numbers etc.) is done through the 
   Xenbus.

On the Linux side, this is implemented as a kernel module. No patches 
to the kernel itself (apart from the ones I sent in earlier) or to Xen 
itself are required.

> So far, there is an RFC to implement virtio-mmio for Xen on Arm

I did not see that before. Also, I'm not familiar with the ioreq 
mechanism. But from skimming the patch, it seems like it achieves the 
same thing (dynamic creation of virtio devices at runtime). Is that 
right?

> But the idea of a Xen specific transport is discussed on the mailing
> list time to time. It would be more secure than existing transport,
> but I am worried about the adoption of the transport. 

What are the security issues with the existing transport mechanisms?
I'm quite new to the Xen community, so I have no idea about adoption 
rates.

> A new transport requires to modify all the OSes so they can work on 
> Xen.

Just to be clear: They would need to be modified in order to support 
that mechanism, but it changes nothing about the interface between 
hypervisor and guest.

However, supporting the same use case with an already existing 
transport mechanism is more elegant than building another transport 
mechanism specifically for that case IMO. The only technical difference 
between my implementation and the virtio-mmio approach in actually 
running the virtio device is that I'm using event channels for queue 
notification while virtio-mmio uses some bytes in memory for that. I do 
not have any measurements indicating whether or not this makes a 
difference.

> Do see any use of this transport outside of Xen? 

This mechanism relies on the Xenbus, so no.

Greetings,
Simon