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

On Thu, Feb 26, 2026 at 05:59:52AM +0000, Parav Pandit wrote:
> 
> 
> > 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?
>  

PCI is going to be *one* of the bus implementations for virtio-msg. Other busses
could also expose multiple devices if the underlying protocol supports. So I
didn't want to tie it with SR-IOV alone.

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

I'm not aware of this 'admin command interface'. Could you elaborate?

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

Yes!

> If yes, then then it is very common for us as well to have modern interface for resource creation such as virtqueue.
> 

When I talked to Michael a couple of years back at Vienna LPC about these
issues, he suggested going for a separate transport than fixing the existing PCI
transport (which might not be possible while preserving backwards
compatibility). That's when I encountered this new virtio-msg transport and it
suited my needs.

- Mani

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