Jason Andryuk writes ("[PATCH v5 00/21] Add support for qemu-xen runnning in a
Linux-based stubdomain"):
> In coordination with Marek, I'm making a submission of his patches for Linux
> stubdomain device-model support. I made a few of my own additions, but Marek
> did the heavy lifting. Thank you, Marek.
Hi. Thanks very much for this contribution. Sorry it has taken me so
long to get to review it.
> Later patches add QMP over libvchan connection support. The actual connection
> is made in a separate process. As discussed on Xen Summit 2019, this allows to
> apply some basic checks and/or filtering (not part of this series), to limit
> libxl exposure for potentially malicious stubdomain.
OK.
> Few comments/questions about the stubdomain code:
>
> 1. There are extra patches for qemu that are necessary to run it in
> stubdomain.
> While it is desirable to upstream them, I think it can be done after merging
> libxl part. Stubdomain's qemu build will in most cases be separate anyway, to
> limit qemu's dependencies (so the stubdomain size).
Yes.
> 2. By default Linux hvc-xen console frontend is unreliable for data transfer
> (qemu state save/restore) - it drops data sent faster than client is reading
> it. To fix it, console device needs to be switched into raw mode (`stty raw
> /dev/hvc1`). Especially for restoring qemu state it is tricky, as it would
> need
> to be done before opening the device, but stty (obviously) needs to open the
> device first. To solve this problem, for now the repository contains kernel
> patch which changes the default for all hvc consoles. Again, this isn't
> practical problem, as the kernel for stubdomain is built separately. But it
> would be nice to have something working with vanilla kernel. I see those
> options:
> - convert it to kernel cmdline parameter (hvc_console_raw=1 ?)
> - use channels instead of consoles (and on the kernel side change the
> default
> to "raw" only for channels); while in theory better design, libxl part
> will
> be more complex, as channels can be connected to sockets but not files, so
> libxl would need to read/write to it exactly when qemu write/read the
> data,
> not before/after as it is done now
What a mess. Thanks for trying to tackle it!
Would it be possible to add a rendenzvous to the console ? Eg, the
guest could write a "ready" byte after it has set the mode.
I'm not sure I understand the problem with libxl and channels. Maybe
a helper process (perhaps existing only during migration) could help ?
Or, libxl has the "datacopier" async thing in it which you can spawn
one of and hopefully forget about. You could teach it channels, or
make a thing like it that uses channels, or something.
> 3. Mini-OS stubdoms use dmargs xenstore key as a string. Linux stubdoms use
> dmargs as a directory for numbered entries. Should they be different names?
Yes, I think so. That way if there's a version mismatch you get
ENOENT rather than an empty argument list...
I'll go and look at the patches now.
Regards,
Ian.
