remoteproc_virtio: add shm_io for remoteproc virtio

[CV-Bowen]

Now the rpmsg device need pass a share memory io region to rpmsg_init_vdev().
I think every virtio device need a share memory io to access the share memory and this region should be provided by the transport layer. Like the MMIO transport layer did in OpenAMP.

So I add shm_io in the remoteproc virtio device and also provide an API to set it.

[tnmysh]

Any usage of this API anywhere ? Either in demos or OpenAMP ?
If not, may be not right time to have this change.
Also we don't alwasy assume shm_io will be always used. dmabuf based memory allocation is also possible. I think such use case was posted by TI in another PR.

@arnopo, @edmooring any thoughts?

[arnopo]

Quite agree with @tnmysh. This PR introduces an unused field. If possible I would prefer it to be integrated in a PR that provides the full picture of the need.

@tnmysh : I remember we discussed the possibility of using dmabuf-based memory allocation in a meeting, but I don't see any associated PR or issue. Could you please provide a reference if you have it?

[edmooring]

Are there any consumers for this new API? I can't find any in either open-amp or openamp-system-reference.

[CV-Bowen]

@arnopo @tnmysh @edmooring Thanks, I use this API in NuttX (but code not up streamed). We want make the remoteproc transport layer supports more virtio devices.
I will continue this PR when I up streamed the NuttX part code.

[github-actions]

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

[CV-Bowen]

@tnmysh : I remember we discussed the possibility of using dmabuf-based memory allocation in a meeting, but I don't see any associated PR or issue. Could you please provide a reference if you have it?

@tnmysh I want to continue this PR and I'm interested in the dma method. That will be very thankfully if you can proviud a reference if you have it.

[tnmysh]

@arnopo , @CV-Bowen here is PR that mentions using dma-buf:

OpenAMP/libmetal#82

I remember TI folks were working to update that PR. Not sure about latest status.

[github-actions]

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