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

Demi Marie Obenour <[email protected]> Wed, 25 Feb 2026 11:15:50 -0500
Newsgroups	dev.linux.lists.virtio-comment
Message-ID	<[email protected]>
On 2/25/26 10:51, Bertrand Marquis wrote:
> 
> 
>> 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.
I'm not actually using QEMU due to its large attack surface.
I'm writing my own device implementation, either in Cloud Hypervisor
or as a vhost-user device.  It will implement a vhost-user device
that can be used by a different VM.

I'm going to call the guest implementing the device the "backend",
and the guest using the device the "frontend".  The threat model is
that both assume the other might be malicious, but denial of service is
not a serious concern.  Latency and throughput _are_ serious concerns,
as this will be used for real-time sound and video streams.

The main four things I am trying to figure out are:

1. Most importantly, is this the best approach?  Does it make sense
   to abstract over virtio-msg and vhost-user like this, or should
   they be completely separate, with separate userspace APIs?  If they
   should be separate, I'll implement virtio-vhost-user instead.
   
2. Where should I translate from vhost-user semantics to virtio-msg
   semantics?  I can do this in the device model, the guest kernel, or
   in guest userspace.  All three have advantages and disadvantages.
   An implementation in the device model makes it easier to protect
   the frontend VM from the backend VM, but adds additional complexity
   in the backend VM's VMM.

3. How do I make my implementation interoperable with the common Linux
   virtio-msg device implementation API?  If I develop a driver in
   parallel with the one you are working on, we will need to coordinate
   to avoid exposing diverging APIs to userspace.

4. Is the virtio device I am writing something that could be
   standardized?  Is its driver one that would be upstreamable?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)