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

Manivannan Sadhasivam <[email protected]> Wed, 25 Feb 2026 20:41:25 +0530
Newsgroups dev.linux.lists.virtio-comment
Message-ID <u6crvmiyjbz4d7gokuegarg7d2c2krymfutzgtr26epzmv2ro7@5saaxv4agwwi>
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.

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

- Mani

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