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

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

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.
We can scope this for buses that can do DMA for now.



> 
> 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.
No one asked for virtio over carrier pigeons.
Let us not over engineer please.

-- 
MST