On 9/15/2024 11:58 AM, Jason Gunthorpe wrote:
On Fri, Sep 13, 2024 at 08:39:26AM -0600, Mathieu Poirier wrote:
KVM has nothing to do with this. The life of a virtio device starts
in the VMM (Virtual Machine Manager) where a backend device is created
and a virtio MMIO entry for that device is added to the device tree
that is fed to the VM kernel. When the VM kernel boots the virtio
MMIO entry in the DT is parsed as part of the normal device discovery
process and a virtio-device is instantiated, added to the virtio-bus
and a driver is probed.
I suggest you start looking at that process using the kvmtool and a
simple virtio device such as virtio-rng.
I would repeat again, I think trying to create a companion virtio
device to go along with a real vPCI device and then logically
associating both of them with a single driver is going to cause so
much pain you should not do it.
Find a way to send your RPCs through your own vPCI device.
Jason
When you say "your own vPCI device", are you referring to the virtual
functions that are created by the adapter? Those are defined by the
hardware specification and we don't have the ability to extend them.
What we're investigating is using RPMSG-over-VIRTIO, not using virtio
devices directly. It appeared to me that rpmsg was intended to provide a
general-purpose "pipe" between two processors that otherwise don't have
a communication path. That sounds ideal for what we need.
- Doug
External recipient
