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

> On 25 Feb 2026, at 16:48, Demi Marie Obenour <[email protected]> wrote:
>
> On 2/25/26 10:40, Bertrand Marquis wrote:
>>
>>
>>> On 25 Feb 2026, at 16:36, Demi Marie Obenour <[email protected]> wrote:
>>>
>>> On 2/25/26 10:12, 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
>>>
>>> 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?

There are 2 sides:
- virtio-msg support in qemu (working on that)
- your new virtio device/driver

Once the first point is available you can create a new device type if you need
or just reuse any existing ones (block, net, you name it) and build something
on top which is probably the easiest solution.

As said once the transport will be in linux and qemu, any existing virtio driver
will work and that is the same for virtio devices existing already in qemu.

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.