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

Hi Manivannan,

> On 26 Feb 2026, at 06:40, Manivannan Sadhasivam <[email protected]> wrote:
>
> 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.

We could have A bus implementation specified in the spec but not all bus
implementations. A big part of the design is to allow implementation on several
transport mechanisms (at the end you only need to have a way to share or access
remote memory and transport messages).
As of now the identified ones are:
- FF-A
- PCI for system to system (Edgar)
- Xen (grantables and events)
- Arm MHU based (cpu to coprocessor)

But we know that there are others working on other hypervisor specific solutions.

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

As said implementation over FF-A has a public specification.
It is not in the virtio specification but i am happy to give a link to it in the spec.

Cheers
Bertrand

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


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.