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

[Demi Marie Obenour <demiobenour@gmail.com>]

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

On 2/25/26 10:40, Bertrand Marquis wrote:
> 
> 
>> 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.

Do irqfds and ioeventfds already provide this?  What interface should
the device-implementing VM use to provide the device?  Should it be
a new type of virtio device?  Should this be standardized?
-- 
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 --]