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

Bertrand Marquis
2026-02-25T15:42:02Z

> On 25 Feb 2026, at 16:36, Demi Marie Obenour <demiobenour@gmail.com> wrote:
>
> 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?

Well there is definitely a use case in xen but any other type 1 or type 2
hypervisor could benefit from using virtio-msg and have asynchronous
handling instead of a trap and emulate based implementation.

Cheers
Bertrand

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)<OpenPGP_0xB288B55FFF9C22C1.asc>

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.