what's plan to support the service/driver at the virtio level?

[xiaoxiang781216]

In Linux kernel, we can:

1. Write various virtio drivers(e.g. virtio-blk, virtio-net...)
2. Write various rpmsg drivers(e.g. rpmsg-char, rpmsg-tty...)

But, we can just write rpmsg drivers in Open-AMP, but virtio drivers is very useful in some case:

1. Interact with virito device/driver in Linux kernel(A core) from RTOS(M core) in the same SoC
2. Improve IPC performance in some(e.g. network or file system) case

So, I think the support of native virito driver is a great addition to Open-AMP, we(Xiaomi) are very interesting to improve Open-AMP virtio driver capability.

[arnopo]

Hello @xiaoxiang781216 ,

Some other companies are also interested in extending the open-amp library to support more Virtio services.
Some discussions and works are just starting on the topic.
I added people involved as assignee of the issue.

[xiaoxiang781216]

Thanks @arnopo . Let see how can we work together to improve virtio driver experience in the IoT space.

[xiaoxiang781216]

Where can I find the related proposal or reference change? I want to evaluate the potential influence to the current code base. @arnopo @wmamills

[danmilea]

There's ongoing work to integrate a virtio MMIO front-end layer in the open-amp library based on the Zephyr virtio MMIO implementation from https://github.com/danmilea/zephyr/blob/main/drivers/virtio/virtio-mmio.c (updated to use OpenAMP virtqueue APIs), with the goal to also include support for device drivers (e.g. virtio console, virtio-net).

The framework will also support hypervisorless mode operation. More information on hypervisorless virtio is available here:

• https://www.openampproject.org/news/hypervisorless-virtio-blog/
• https://github.com/danmilea/hypervisorless_virtio_zcu102

@xiaoxiang781216

[xiaoxiang781216]

Thanks @danmilea . I will study these document and feedback to you soon.

[xiaoxiang781216]

@danmilea @arnopo I see that all virito driver support is done on virtio-exp branch, when will the work merge back to the main branch? We are very interesting to try these new exciting features on our platform. @qinwei2004

[arnopo]

Hi @xiaoxiang781216
yes @danmilea has already done a great job.
Current status is that some services are now available ( net, console, entropy) but there are strong correlation for time being with the MMIO transport layer.
So for me a good trigger to merge in main would be to also support the remotreproc virtio transport.
I don't see any associated work started, So if you are interesting in, you are welcome.

[xiaoxiang781216]

@danmilea will you continue MMIO transport in the near feature?

[danmilea]

@xiaoxiang781216 Do you mean adding support for the remoteproc style of virtio? Before looking into that, I think it's more relevant to investigate the requirements of an OpenAMP-based solution for VIRTIO back-ends, since the current implementation includes only front-end support. The scope pf my current work is to get everything on a usable level in a hypervisorless-virtio type of deployment.

[CV-Bowen]

There's ongoing work to integrate a virtio MMIO front-end layer in the open-amp library based on the Zephyr virtio MMIO implementation from https://github.com/danmilea/zephyr/blob/main/drivers/virtio/virtio-mmio.c (updated to use OpenAMP virtqueue APIs), with the goal to also include support for device drivers (e.g. virtio console, virtio-net).

The framework will also support hypervisorless mode operation. More information on hypervisorless virtio is available here:

• https://www.openampproject.org/news/hypervisorless-virtio-blog/
• https://github.com/danmilea/hypervisorless_virtio_zcu102

@xiaoxiang781216

@danmilea Hi, I want to implement the virtio-mmio-serial/net driver based on openamp. Do you have some examples show how to use the virtio mmio apis in virito-exp branch?

[danmilea]

Hi @CV-Bowen
zephyr-openamp-staging (branch virtio-exp) includes samples for net and serial which use the open-amp library virtio mmio support in a standard virtual guest configuration. The hvl_net_rng_reloc sample works in a hypervisorless virtio environment (details in the sample README.rst file).

[CV-Bowen]

@danmilea Got, Thanks a lot.

[arnopo]

@CV-Bowen , @danmilea, @xiaoxiang781216,

We have 2 complementary PRs for Virtio. I'd like to suggest that we move forward step by step to have a common dev approved by everyone and ease the reviews by splitting PRs.

step 1:

• @CV-Bowen : create a new PR that introduce virtio API with create_virtqueues/delete_virtqueues dispatcher ops
  => no remorteproc_virtio or rpmsg update that will come in step 3

step 2:

• @danmilea : create a new PR with virtio MMIO transport only that uses new dispatcher ops

step3

• @CV-Bowen update remoteproc_virtio: optimize the remoteproc virtio transport layer #489( or create new one ) for the remoteproc virtio implementation and virtio RPMsg
• @danmilea: update Virtio native support for lib openamp #494 ( or create new one) for virtio services

[arnopo]

Step 1 merged : #495

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.