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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Feb 25, 2026 at 09:18:58AM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: 25 February 2026 12:55 PM
> > 
> > On Wed, Feb 25, 2026 at 05:09:45AM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: 20 February 2026 03:33 PM
> > > >
> > > > On Fri, Feb 20, 2026 at 06:13:55AM +0000, Parav Pandit wrote:
> > > > > > > 4. I dont find the transport messages to read and write to the driver memory supplied in VIRTIO_MSG_SET_VQUEUE addresses to
> > > > operate
> > > > > > the virtqueues.
> > > > > > > Dont we need VIRTIO_MEM_READ, VIRTIO_MEM_WRITE request and response?
> > > > > >
> > > > > > surely this can be an optional transport feature bit.
> > > > > >
> > > > > How is this optional?
> > > > > How can one implement a transport without defining the basic data transfer semantics?
> > > > > For example for TCP transporting, driver side OS is implementing header format foo, and device side is using header format bar.
> > > > > How does it work?
> > > >
> > > > I'm not sure what do foo/bar refer to, or what TCP transporting means.
> > > This proposal is subset of past proposal of [1].
> > >
> > > Proposal [1] covered transporting virtio control and data operations using something other than MMIO and PCI.
> > > And current proposal is similar, except that it didn't define the transport binding at all for the specific bus.
> > > It is only a partial 'control-transport'.
> > >
> > > [1] https://yhbt.net/lore/virtio-comment/20231023104647.290759-2-pizhenwei@bytedance.com/
> > >
> > > So foo and bar are the definitions I expect as listed in the patch-5 of [1].
> > > If it has to be done by the bus, lets write up this as 'control-transport'.
> > >
> > > > The simplest way to do TCP on top of virtio is to layer it above virtio
> > > > net. That uses VQs for data transfers.
> > > >
> > > The intention of this proposal is not to do TCP on top of virtio.
> > > The intention of this proposal is to do virtio on transports other than MMIO, PCI and channel.
> > > Such a transport can be anything - not defined in virtio spec.
> > 
> > > It could be FFA, some two SoC as written in cover letter example, or it can be something else such as TCP or UDP or vsock or whatever else.
> > 
> > I feel this "anything" is simply too broad a requirement.
> > I did not see any demand for  virtio over TCP.
> > And, making it work with existing drivers will be a mess.
> Why would it be a mess? Because of load/store semantics?
> If so, would the message layer also faces the same challenge?

not sure what "the message layer" is.

> > We can scope this for buses that can do DMA for now.
> That looks reasonable good start.
> However, "Appendix C. Creating New Transports" needs modification.
> 
> Following two likely needs to stay outside of the "control transport".
> 
> A transport provides a mechanism for the device to send device notifications to the driver, such as used
> buffer notifications.
> A transport provides a mechanism for the driver to send driver notifications to the device, such as available
> buffer notifications.


Well existing transports sure do include these.

> We also need to fix the Appendix to describe about control transport and full transport.
> Current definition of Appendix C is listing MMIO And PCI transport, yet it misses virtqueue implementation by _full_ transport.

because they all share a single virtqueue implementation.

> > 
> > 
> > 
> > >
> > > And hence, data transfer part must be scoped properly.
> > > Maybe I am yet to read this text in the 1600 lines of proposed patch...
> > 
> > 
> > Once we get into "support everything in the most abstract way possible"
> > we have already lost.
> Unlikely.
> Nvme over TCP is present since 2021.
> NVMe over RDMA is present since 2017.
> iSCSI over TCP is present from 2014.
> NFS .. 
> List continues...
> 
> The idea is to not define most abstract thing.
> The idea is to define the practical spec that cater to requirements already listed, including the TCP one in [1].

I don't object to virtio over TCP. just do not want to block this
work on that.


> > No one asked for virtio over carrier pigeons.
> CSP user already explained the use case of virtio over network transport in [1].
> Considering above many use cases already done on similar non virtio devices as pigeons is severe undermining the scope of virtio.
> 
> One can say, I only want to engineer control transport ignoring needs of [1].
> However, we must have the doors and vision open so that users of [1] can also use it without creating yet another 'fabric transport'.
> 
> At the same time, we must define the binding to the bus where it is going to be used for the DMA.
> 
> For example, cover letter mentions about " between a host processor and its co-processors"
> And " between normal and secure worlds"
> 
> How can one implement a driver if the bus driver does not know how to enumerate/discover it?
> 
> In the proposed example, of host processor and co-processor if they are connected via Xenbus or AMBA bus,
> how should driver discover this device?
> 
> If this bus binding is not part of the virtio spec, how can it be ever implemented and yet comply to the virtio spec?
> Can someone please explain this?
> 
> I frankly expect an ARM FF-A bus binding transport section in virtio-spec.
> So that device and driver can inter-operate implemented by two different entities.
> Only virtio level messages do not seem sufficient.

I agree at least one should be shown at least as an rfc.