On 20/08/2020 12:57, Simon Leiner wrote:
Hi Julien,
Hi Simon,
On 20.08.20 13:17, Julien Grall wrote:
There is a lot of interest to get Virtio working on Xen at the moment.
Is this going to be a new transport layer for Virtio?
It is designed that way, yes. The current implementation (based on
virtio_mmio.c) has a few limitations:
- Only the host side is implemented for Linux (We are currently only
using bare metal domains for the device side - so the device
implementation is based on OpenAMP[1])
- It lacks some features, e.g. there is currently no device
configuration space
- It is tested only very narrowly (only for my use case which is RPMsg
via the rpmsg_char kernel driver)
As this was really just a byproduct of my main research topic, I'm
currently not in touch with the virtio standards committee. But I'm
happy to contribute my work if there is interest :-)
I have CCed a few folks that are interested in virtio. May I ask why did
you create a new transport rather than using the existing one?
So far, there is an RFC to implement virtio-mmio for Xen on Arm (see
[2]). 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.
A new transport requires to modify all the OSes so they can work on Xen.
This is fine for open-source OS, but it may be more difficult to get
proprietary OS to invest in the new transport.
Do see any use of this transport outside of Xen?
Cheers,
[2]
https://lore.kernel.org/xen-devel/1596478888-23030-1-git-send-email-olekst...@gmail.com/
--
Julien Grall
