Re: [virtio-dev] [PATCH v4] vsock: add vsock device

[Ian Campbell <ian.campbell@docker.com>]

On Mon, 2016-03-21 at 16:54 +0000, Stefan Hajnoczi wrote:
> On Mon, Mar 21, 2016 at 12:53:23PM +0000, Ian Campbell wrote:
> 
> Answers to the first few points.  I'll reply with more tomorrow.
> 
> > 
> > On Wed, 2016-03-16 at 10:53 +0000, Stefan Hajnoczi wrote:
> > The Linux .ko and various things under sysfs end up called
> > "transport-
> > virtio" (or s/-/_/g) rather than e.g. "vsock-transport-virtio",
> > which
> > would be less generic sounding.
> Besides renaming the module to vsock_transport_virtio.c, is there
> anything else you noticed that needs to be renamed?

I didn't notice anything, but I also didn't go looking (although I
suspect vmci_transport has the same issue).

> > > diff --git a/trunk/content.tex b/trunk/content.tex
> > > index d989d98..4e9f165 100644
> > > --- a/trunk/content.tex
> > > +++ b/trunk/content.tex
> > > @@ -5641,6 +5641,223 @@ descriptor for the \field{sense_len},
> > > \field{residual},
> > >  \field{status_qualifier}, \field{status}, \field{response} and
> > >  \field{sense} fields.
> > > 
> > > +\section{Socket Device}\label{sec:Device Types / Socket Device}
> > > +
> > > +The virtio socket device is a zero-configuration socket
> > > communications device.
> > > +It facilitates data transfer between the guest and device
> > > without using the
> > > +Ethernet or IP protocols.
> > > +
> > > +\subsection{Device ID}\label{sec:Device Types / Socket Device /
> > > Device ID}
> > > +  13
> > The SVN version of the virtio spec seems to include many more
> > device id
> > allocations, in particular in the table at the start of Section 5
> > ("Device Types") it assigns 13 as "memory balloon" (not the
> > traditional
> > one) and 5.5 ("Traditional Memory Balloon Device") says:
> >     This is the traditional balloon device. The device number 13 is
> >     reserved for a new memory balloon interface, with different
> >     semantics, which is expected in a future version of the
> > standard.
> Thanks for pointing this out.  I'll select a new device ID.

You probably want to update that table too -- that way you'll get merge
conflicts on rebase if you race with someone else.

Or maybe the virtio editors would take a patch which only reserved the
number?

> > > +The ctrl virtqueue is reserved for future use and is currently unused.
> > Is the normal way to reflect this in a driver backend implementation by
> > exposing a small (perhaps even zero sized) queue?
> I'll drop the ctrl virtqueue in the next revision.
> 
> Previous revisions had the ctrl virtqueue at index 0, followed by rx and
> tx.  Now that the ctrl and event virtqueues are at the end we might as
> well make ctrl the last virtqueue.  At that point there's no reason to
> reserve it anymore so it can be dropped.

Sounds good, thanks!

Ian.