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

Demi Marie Obenour
2026-02-25T15:36:48Z

[-- Attachment #1.1.1: Type: text/plain, Size: 2168 bytes --]

On 2/25/26 10:12, Bertrand Marquis wrote:
> Hi Parav,
>
>> On 25 Feb 2026, at 16:07, Parav Pandit <parav@nvidia.com> wrote:
>>
>> Hi Bertrand,
>>
>>> From: Parav Pandit <parav@nvidia.com>
>>> 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

Is "hypervisor based events + shared memory" only really intended for
Xen and other true type-1 hypervisors? Should KVM and other type-2
hypervisors use a different approach, like virtio-vhost-user?
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]