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

> From: Manivannan Sadhasivam <[email protected]>
> Sent: 26 February 2026 11:06 AM
> 
> 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.
>
I didn’t understand the design part.
Why that cannot be the design if the intent is to have multiple devices?
 
> > > > 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.
> 
Yes, I am familiar with this inefficiency.
Well for such fundamental case, all resource creation can be directly move to an admin command interface being basic facility for long enough period.

> 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.
>
When you say front end meaning the driver, and backend being the device?
If yes, then then it is very common for us as well to have modern interface for resource creation such as virtqueue.

I am still yet to catch up on Bertrand, Edgar's, Demi's and other emails from yesterday.

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