[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Virtio in Xen on Arm (based on IOREQ concept)




On 20.07.20 23:38, Stefano Stabellini wrote:

Hello Stefano

On Fri, 17 Jul 2020, Oleksandr wrote:
*A few word about solution:*
As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm
Any plans for virtio-pci? Arm seems to be moving to the PCI bus, and
it would be very interesting from a x86 PoV, as I don't think
virtio-mmio is something that you can easily use on x86 (or even use
at all).
Being honest I didn't consider virtio-pci so far. Julien's PoC (we are based
on) provides support for the virtio-mmio transport

which is enough to start working around VirtIO and is not as complex as
virtio-pci. But it doesn't mean there is no way for virtio-pci in Xen.

I think, this could be added in next steps. But the nearest target is
virtio-mmio approach (of course if the community agrees on that).
Hi Julien, Oleksandr,

Aside from complexity and easy-of-development, are there any other
architectural reasons for using virtio-mmio?

I am not asking because I intend to suggest to do something different
(virtio-mmio is fine as far as I can tell.) I am asking because recently
there was a virtio-pci/virtio-mmio discussion recently in Linaro and I
would like to understand if there are any implications from a Xen point
of view that I don't yet know.
Unfortunately, I can't say anything regarding virtio-pci/MSI. Could the virtio-pci work in virtual environment without PCI support (various embedded platforms)?

It feels to me that both transports (easy and lightweight virtio-mmio and complex and powerfull virtio-pci) will have their consumer demand and worth being implemented in Xen.



For instance, what's your take on notifications with virtio-mmio? How
are they modelled today? Are they good enough or do we need MSIs?

Notifications are sent from device (backend) to the driver (frontend) using interrupts. Additional DM function was introduced for that purpose xendevicemodel_set_irq_level() which results in vgic_inject_irq() call.

Currently, if device wants to notify a driver it should trigger the interrupt by calling that function twice (high level at first, then low level).


--
Regards,

Oleksandr Tyshchenko




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.