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

> From: Michael S. Tsirkin <[email protected]>
> Sent: 25 February 2026 12:55 PM
> 
> On Wed, Feb 25, 2026 at 05:09:45AM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <[email protected]>
> > > 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/[email protected]/
> >
> > 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?

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

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.

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

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