Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for 
qemu-xen runnning in a Linux-based stubdomain."):
> On Tue, Oct 16, 2018 at 05:53:02PM +0100, Ian Jackson wrote:
> > I think you may need a quoting
> > scheme, or to use nul.
> 
> The main reason for this over alternatives (including nul) is using
> shell script on the stubdomain side to handle this. Handling nul char in
> shell is major PITA.

Ah.  Yes.  You could handle multiple arguments in multiple xenstore
keys easily enough though, I think ?

Or you could pass a shell string.  That is, you could shell escape the
arguments in libxl.  Shell escaping is a bit fiddly but not too
hard.[1] Then in the stubdom you can just say sh -c.

[1] One algorithm would be
   1. replace all \ in each argument with '\\'
   2. replace all ' in each argument with '\''
   3. put ' ' around each argument
   4. concatenate with spaces in between

> > | xenstore values should normally be 7-bit ASCII text strings
> > | containing bytes 0x20..0x7f only
> > 
> > I think you could have separate xenstore keys for the seperate
> > arguments, or you could encode it somehow.
> 
> What "normally" means in this context? For me it doesn't mean other
> characters are prohibited.

The reasoning is explained in the surrounding text,  Basically, it
makes debugging (listing xenstore by hand, etc) very annoying.

> > >     * qemu can access saved state (if any) at its FD 3
> > >     * qemu can write its state (for save/migration) to its FD 4
> > 
> > That's a description of the protocol to *qemu*.  Is the toolstack then
> > responsible for the protocol across the domain boundary ?  I think it
> > would be nice to specify that here too.
> 
> Well, toolstack is responsible for qemu command line (and QMP), so it is
> part of the stubdomain protocol...

Err, I mean, you are specifying a protocol at the qemu boundary.  It
is good to write that down.  But it would be nice to also write down
the protocol at the stubdom boundary, even though both halves of it
are actually implemented by part of the toolstack (the stubdom side
being scripts passed in by the toolstack).

> > This is awkward, isn't it.  The Xen PV console protocol has no reset
> > mechanism.  Can we use libvchan here and provide qmp vchans ?
> 
> That would be an option too. Require (trivial) vchan->unix socket proxy.

Yes.  Or teaching qemu about libvchan.
Hey, we should teach socat about libvchan :-).

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel