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

Hi Bertrand,

> From: Parav Pandit <[email protected]>
> Sent: 25 February 2026 08:30 PM

[..]
> > >>> So the PCI device is not one virtio device but one bus behind which there can be many devices.
> > >>>
> > >>> Is this making the concept a bit clearer ?
> > >>>
> > >> 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?
> 
> 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.

If the objective of the virtio-msg layer is to really support FF-A or similar other non-PCI transports, lets please focus the discussion on such use case and binding of that specific non-PCI bus. (like the link you pointed on arm site).

This would help this series to progress faster without getting distracted on PCI side.