On Thu, Jun 18, 2020 at 12:39:40PM +0200, Guennadi Liakhovetski wrote: > On Thu, Jun 18, 2020 at 11:33:24AM +0200, Vincent Whitchurch wrote: > > By the "normal rpmsg API" I mean register_rpmsg_driver(), rpmsg_send(), > > etc. That API is not tied to virtio in any way and there are other > > non-virtio backends for this API in the tree. So it seems quite natural > > to implement a vhost backend for this API so that both sides of the link > > can use the same API but different backends, instead of forcing them to > > use of different APIs. > > Ok, I see what you mean now. But I'm not sure this is useful or desired. I'm > not an expert in KVM / VirtIO, I've only been working in the area for less > than a year, so, I might well be wrong. > > You're proposing to use the rpmsg API in vhost drivers. As far as I > understand so far that API was only designated for the Linux side (in case of > AMPs) which corresponds to VM guests in virtualisation case. So, I'm not sure > we want to use the same API for the hosts? This can be done as you have > illustrated, but is it desirable? The vhost API is far enough from the VirtIO > driver API, so I'm not sure why we want the same API for rpmsg? Note that "the Linux side" is ambiguous for AMP since both sides can be Linux, as they happen to be in my case. I'm running virtio/rpmsg between two physical processors (of different architectures), both running Linux. virtio has distinct driver and device roles so the completely different APIs on each side are understandable. But I don't see that distinction in the rpmsg API which is why it seems like a good idea to me to make it work from both sides of the link and allow the reuse of drivers like rpmsg-char, instead of imposing virtio's distinction on rpmsg.
