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

On Wed, Feb 25, 2026 at 03:12:11PM +0000, Bertrand Marquis wrote:
> Hi Parav,
> 
> > On 25 Feb 2026, at 16:07, Parav Pandit <[email protected]> wrote:
> >
> > 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.
> 
> Agree the example of virtio-msg over PCI made the discussion divert a bit.
> 

I brought it up *only* because I felt that the bus implementations need to be
defined in the spec, because it would be hard for us to use virtio-msg without
defining the actual bus implementation. Merely defining the 'bus requirements'
is not enough.

> Maybe focusing on use cases like:
> - FF-A
> - messaging unit + shared memory
> - hypervisor based events + shared memory
> 

IMO, for the initial version, you can atleast define one bus implementation. It
could be one among the three you mentioned above. PCI bus implementation could
very well come later once this gets in.

- Mani

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