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

Hi Demi,

> On 25 Feb 2026, at 16:19, Demi Marie Obenour <[email protected]> wrote:
>
> On 2/25/26 08:29, Bertrand Marquis wrote:
>> Hi Demi,
>>
>>> On 25 Feb 2026, at 14:12, Demi Marie Obenour <[email protected]> wrote:
>>>
>>> On 2/25/26 08:09, Manivannan Sadhasivam wrote:
>>>> On Wed, Feb 25, 2026 at 07:53:38AM -0500, Demi Marie Obenour wrote:
>>>>> On 2/25/26 02:45, Manivannan Sadhasivam wrote:
>>>>>> Hi Bertrand,
>>>>>>
>>>>>> On Fri, Feb 20, 2026 at 09:02:12AM +0000, Bertrand Marquis wrote:
>>>>>>> Hi Parav,
>>>>>
>>>>> (snip)
>>>>>
>>>>>>>> How can one implement a transport without defining the basic data transfer semantics?
>>>>>>>
>>>>>>> We did a lot of experiments and we are feature equivalent to PCI, MMIO or Channel I/O.
>>>>>>> If anything is missing, we are more than happy to discuss it and solve the issue.
>>>>>>>
>>>>>>
>>>>>> I'd love to have this transport over PCI because it addresses the shortcomings
>>>>>> of the existing PCI transport which just assumes that every config space access\
>>>>>> is trap and emulate.
>>>>>
>>>>> Would you mind elaborating on "over PCI"?
>>>>>
>>>>> I can see two meanings for this:
>>>>>
>>>>> 1. Virtio-msg over a physical PCI bus for heterogeneous multiprocessing
>>>>>  environments.
>>>>>
>>>>> 2. Virtio-msg over an emulated PCI bus for QEMU, Cloud Hypervisor,
>>>>>  and other existing VMMs.
>>>>>
>>>>> Which one are you referring to?
>>>>>
>>>>
>>>> Physical PCI bus, that's why I mentioned 'trap and emulate' which only applies
>>>> to emulated PCI bus.
>>>
>>> Is virtio-msg appropriate when the PCI bus is emulated, or should
>>> the existing PCI transport be used instead?
>>
>> No existing PCI transport should be used, virtio msg over PCI is just for a specific case
>> and definitely not when virtio devices are pci devices.
>
> Is virtio-msg an appropriate way for a VM to _implement_ a virtio device?
>
> More specifically:
>
> Suppose I want to implement a virtio device in a VM, rather than
> on the host, for isolation reasons.  This is on KVM, so the Xen
> transport isn't feasible, and it needs to be portable, so the FF-A
> transport isn't feasible.  The AMP transport _could_ be feasible, but
> it requires a "virtio-vfio" device that speaks the vfio-user protocol.
> Such a device does not currently exist.

Right now virtio device/driver implementations are independent of
the transport so the idea is you can implement it and reuse in KVM
(which will probably continue to use PCI), xen (which currently use
PCI or mmio using ioreq but will also support virtio-msg).

>
> There are a few other options:
>
> 1. I can implement the virtio-vhost-user protocol.  This was
>   proposed but never standardized.  It has the advantage of being
>   a good fit for the vhost-user protocol, and thus providing easy
>   interoperability with many frontend VMMs like QEMU.

That is a solution if available.

>
> 2. I can implement virtio-msg over PCI, but have the driver speak
>   the _device_ side of the protocol.  This is a better fit to the
>   virtio-msg-pci device, which is going to be standardized.  However,
>   it doesn't map as well to the vhost-user protocol, and thus will
>   make it harder to interoperate with existing frontend VMMs.

We need to stop speaking of PCI, it is giving a wrong idea.
In your use case it does not make sense if PCI is emulated you
would do virtio over PCI or use virtio over Messages if available
but virtio-msg over PCI is never a solution which should only be
used in cases where you have a physical PCI connection between
2 systems.

>
> 3. I can implement virtio-msg over PCI, have the driver speak the
>   device side of the protocol, and translate this to vhost-user in
>   the VMM.  This leads to additional complexity and also creates a
>   specific device that is not likely to be used for other purposes.

same as above

>
> 4. I can try to implement whatever future interface will be available
>   for QEMU to implement devices.

I would do this. The plan is to add virtio-msg support in qemu so that
any device implementation available in qemu could be used with virtio-msg
 or virtio-pci or virtio-mmio.

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.