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

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

And hence, data transfer part must be scoped properly.
Maybe I am yet to read this text in the 1600 lines of proposed patch...

> --
> MST