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.
> 
> Maybe focusing on use cases like:
> - FF-A
> - messaging unit + shared memory
> - hypervisor based events + shared memory
> 
> 
> Would make the discussion focus more.
> 
> Cheers
> Bertrand
> 
>

indeed, possible. but do include ff-a bit for reference then.
even if down the road it is not part of the spec (though no idea why
and I would like to see).

-- 
MST