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

> 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.

> > 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.

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