Re: [PATCH v5 00/21] Add support for qemu-xen runnning in a Linux-based stubdomain

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

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.