Re: Using RPMSG to communicate between host and guest drivers

[Doug Miller <doug.miller@cornelisnetworks.com>]

On 8/26/2024 11:50 AM, Mathieu Poirier wrote:
> Apologies for the late reply - this got lost in the vacation email backlog.
>
> On Mon, 26 Aug 2024 at 10:27, Dennis Dalessandro
> <dennis.dalessandro@cornelisnetworks.com> wrote:
>> On 7/31/24 4:02 PM, Doug Miller wrote:
>>> I am working on SR-IOV support for a new adapter which has shared
>>> resources between the PF and VFs and requires an out-of-band (outside
> It would have been a good idea to let people know what "PF" and "VF"
> means to avoid confusion.
"PF" refers to the Physical Function of the PCI adapter - that which
exists always, regardless of whether SR-IOV is active. The "VF" refers
to the virtual function(s) that are created when SR-IOV is enabled and
configured. Typically, the VFs and the PF are assigned to different OS
instances running in different VMs. So, the OS that owns the PF needs to
be able to handle resource requests from the OSes that own the VFs (and
also send notifications).
>
>>> the adapter) communication mechanism to manage those resources. I have
>>> been looking at RPMSG as a mechanism to communicate between the driver
>>> on a guest (VM) and the driver on the host OS (which "owns" the
>>> resources). It appears to me that virtio is intended for communication
>>> between guests and host, and RPMSG over virtio is what I want to use.
>>>
> Virtio is definitely the standard way to convey information between a
> host and a guest.  You can specify as many virtqueues as needed
> (in-band and out-of-band) and it is widely supported.  What
> information is conveyed by the virtqueues and how it gets conveyed is
> entirely up to the use case.  Have a look at the specification of
> existing virtio drivers to get a better idea [1].  If the driver you
> are working with hasn't been standardised, I highly encourage you to
> submit a draft for it.  If it has then add to the current
> specification.
>
> All that said, you could use RPMSG as the protocol that runs on top of
> the virtqueues - that should be fairly easy to do.
I had initially started looking at using virtio directly, but it looked
like I was going to have to get a new device ID defined upstream and it
would be a significant effort compared to using an existing facility. I
then saw device ID VIRTIO_ID_RPMSG, which appears to be exactly what
we'd have to create if we were defining a new virtio device for what we
need. However, the problem has been understanding how to write code to
provide the rpmsg "device" side. There does not appear to be any
documentation and there is no example code to follow. It seems that the
device side is typically contained in a GPU or accelerator, which was
not written for a Linux kernel. So I have many questions on how (and
when) to use the interfaces (rpmsg_register_device,
rpmsg_create_channel, rpmsg_create_ept, rpmsg_find_device, ...).
>
> Thanks,
> Mathieu
>
> [1]. https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
>
>>> Can anyone confirm that RPMSG is capable of doing what we need? If so,
>>> I'll need some help figuring out how to use that from kernel device
>>> drivers (I've not been able to find any examples of doing the
>>> service/device side). If not, is there some other facility that is
>>> better suited?
>> Hi Bjorn and Mathieu, any advice here for Doug? Adding linux-rdma folks as that
>> is where this will eventually target.
>>
>> -Denny
>>

External recipient