Re: [PATCH v1 0/4] virtio-msg transport layer

On Thu, Feb 26, 2026 at 07:01:25AM +0000, Bertrand Marquis wrote:
> Hi Manivannan,
> 
> > On 26 Feb 2026, at 06:36, Manivannan Sadhasivam <[email protected]> wrote:
> >
> > On Wed, Feb 25, 2026 at 03:15:39PM +0000, Parav Pandit wrote:
> >>
> >>> From: Manivannan Sadhasivam <[email protected]>
> >>> Sent: 25 February 2026 08:41 PM
> >>>
> >>> On Wed, Feb 25, 2026 at 03:00:19PM +0000, Parav Pandit wrote:
> >>>
> >>> [...]
> >>>
> >>>>>>> Yes. This makes a lot of sense now.
> >>>>>>>
> >>>>>>> This is a virtio-msg-transport device that needs its own device id in the table.
> >>>>>>> And its binding to the PCI transport.
> >>>>>>
> >>>>>> ok. how about an rfc of that idea on the list?
> >>>>>
> >>>>>
> >>>>> I will let Edgar answer on this.
> >>>>>
> >>>> Sure.
> >>>> Also please explain how is this different than SR-IOV devices?
> >>>> On a PCI device there are some child devices exposed using some virtio-msg bus transport.
> >>>> And all of them are going to share same PCI BDF.
> >>>> These individual devices cannot be mapped to different VMs (secure or regular) in a performant way either.
> >>>> So what would this virtio-msg-transport device achieve?
> >>>>
> >>>
> >>> IDK why you are comparing this transport with SR-IOV, which altogether serves a
> >>> different purpose.
> >>>
> >> In the example showed there are multiple devices behind one PCI device.
> >> Why is it not similar to SR-IOV that does exactly that, on one PCI link, exposes multiple devices.
> >>
> >
> > That could be one usecase, but not the actual design.
> >
> >>>> If there was no PCI bus when implementing the virtio-msg transport, it would make sense to avoid trap-emulate story.
> >>>> But underlying transport being PCI, its back to square one for the originally described motivation.
> >>>>
> >>>
> >>> Even with PCI as the physical bus, we don't need any trap and emulate assumption
> >>> with this transport, because the communication is message based, not writing and
> >>> reading registers directly in the BAR memory.
> >>>
> >> That is true. Somewhere in this thread, there was mention of trap+emulation as reason to create some msg based transport.
> >> So I do not know why t+e was mentioned.
> >> I don’t have the link to that email at the moment.
> >>
> >
> > I mentioned that because to run the existing Virtio PCI one would need an
> > emulated PCI device. I think it is also possible to expose custom designed HW as
> > a Virtio PCI device, but that's not the majority.
> >
> > One primary example is how the virtqueue configuration happens. The driver
> > selects the queue by writing to the 'queue_select' and immediately it expects
> > the device to select that virtqueue and give response in other fields such as
> > 'queue_size'. This only happens in an emulated PCI bus. But in a real PCI bus,
> > the device on the other end cannot synchronize itself with the host. And this is
> > what being fixed by the message based communication.
> >
> > We tried using the existing Virtio PCI transport in a design where two SoCs are
> > connected using PCIe bus, both running Linux. One will act as Virtio Frontend
> > and another as backend. Then we ran into all sort issues due to the above
> > mentioned assumption/expectation by the transport.
> >
> 
> Definitely check Edgar's work using virtio-msg as it seems that it is exactly what
> you are looking for.
> 

I already have a prototype based on the intial virtio-msg transport kernel
patches by Viresh: https://github.com/Mani-Sadhasivam/linux/tree/pci-epf-virtio-msg

I guess some of it, especially the queue implementation was inspired from
Edgar's work I believe.

- Mani

-- 
மணிவண்ணன் சதாசிவம்