Re: [Qemu-devel] Re: Planning for 0.13

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

On Wed, Jan 06, 2010 at 10:49:54PM +0000, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > On Wed, Jan 06, 2010 at 05:19:45PM +0000, Jamie Lokier wrote:
> > > Michael S. Tsirkin wrote:
> > > > On Wed, Jan 06, 2010 at 09:24:45AM -0600, Anthony Liguori wrote:
> > > > > A helper is semantics equivalent to passing an fd from a management  
> > > > > tool.  All of the problems you describe are equally applicable to that  
> > > > > model.
> > > > 
> > > > No, because management calls qemu and parses qemu help output.  Yes it
> > > > is not ideal but it works today.
> > > 
> > > I don't understand.  What do you think would not work with
> > > helper="..."  where ... is specified on the qemu command line by the
> > > management script, versus the management script doing the helper
> > > operations itself first and then calling qemu with fd=?
> > > 
> > > If you are thinking that management scripts will tailor the -net
> > > arguments according to qemu version, you're right for some
> > > configurations (but not well established simple ones).
> > > 
> > > Presumably management can do the same capability when specifying "..."
> > > - the difference being it would query the helper tool to get _it's_
> > > features in some cases, e.g. for arguments to a helper which uses SSH
> > > to provide an encrypted tunnel.
> > 
> > What won't work is that besides fd= management specifies many other
> > arguments to the -net flag.
> 
> I still don't understand.  What prevents management from specifying
> the other arguments with helper=, either in the helper argument (for
> arguments to the helper itself), or to qemu (for things qemu needs be told)?
> 
> > What you describe: helper= instead of fd= will work and I have no issue
> > with this. And we won't need any protocol between helper and qemu: just
> > the fd returned.
> 
> You may still need qemu to know whether to use send/recv (datagram
> socket) or read/write with framing (pipe or something), but if it
> comes to that, qemu can use fstat() to decide what it needs.  There is
> probably no need for options passed back, I agree :-)

Well, if we special-case some fd type, let's just put all handling in
qemu. There's no advantage in spreading it around. It only makes sense
to move stuff out to helper script if it can be done generically IMO.

> I think there is a lot to be said for letting the helper keep the
> initial unix socket open, so it can reliably detect when the parent
> qemu dies and then clean up.
> 
> > But of course this means that it can't be used to create new
> > backends such as vepa, which often need to setup the fd in complex
> > ways.
> 
> For vepa, I don't know if you mean the fd needs complex setup
> initially, or complex options with each packet.  (Web browser
> unavailable right now).
> 
> For complex initial setup, that's exactly what a helper would be good
> for.  Any options needed for that setup would be part of the
> helper="/path/to/helper opts..." string.  If there are options which
> depend on helper version, management can query the helper itself with
> /path/to/helper --help; that doesn't seem likely to be needed much.
> 
> If individual packet transmission requires "complex ways" then of
> course that would have to be inside qemu.  Is that the case with vepa
> and other things under discussion?

As I said, stuff like vhost needs physical addresses as part of its
setup, so that definitely needs to be in qemu too.


>  I got the impression there isn't much variation in the way packets
>  are tranmitted and received.
> 
> -- Jamie

No. E.g. for TX/RX, with packet socket (which is what you'll use for vepa)
you need to do it differently from e.g. TCP socket.

It is true that TCP sockets really do look very much like pipes,
so you can write code that handles these generically.

But other devices don't, and there's a lot of minor differences there,
which we *could* abstract away - but in the end we won't get any new
features users need, and code will be more complex and hard to debug.

-- 
MST