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?
signature.asc
Description: PGP signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel