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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 16, 2018 at 06:52:36PM +0100, Ian Jackson wrote:
> 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. 

From those two options I'd prefer multiple xenstore keys as much
cleaner. We do have them as an array in libxl already.

So, let image/dmargs be actually a directory with entries like:
 - image/dmargs/000 = -xen-domid
 - image/dmargs/001 = 123
 - image/dmargs/002 = -nodefaults
 ...

I wonder if there needs to be arguments count, or iterating until ENOENT
is enough?

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

That's also an option. I'll see how hard it would be to add this to
qemu.

> Hey, we should teach socat about libvchan :-).

:)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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