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

Demi Marie Obenour <[email protected]> Wed, 25 Feb 2026 10:19:45 -0500
Newsgroups	dev.linux.lists.virtio-comment
Message-ID	<[email protected]>
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.

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.
   
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.

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.

4. I can try to implement whatever future interface will be available
   for QEMU to implement devices.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)