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

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

General idea is to allow freely set device_model_version and
device_model_stubdomain_override and choose the right options based on this 
choice.
Also, allow to specific path to stubdomain kernel/ramdisk, for greater 
flexibility.

First two patches add documentation about expected toolstack-stubdomain-qemu
interface, both for MiniOS stubdomain and Linux stubdomain.

Initial version has no QMP support - in initial patches it is completely
disabled, which means no suspend/restore and no PCI passthrough.

Later patches add QMP over libvchan connection support. This means libxenlight
will be linked with libxenvchan.

Ideally talking to stubdomain would be added only to new libxl__qmp_ev* API,
which is written from start with the assumption of untrusted qemu. But
unfortunately some parts of libxl public API that calls into QMP, are not
async-aware and can't use libxl__qmp_ev* API. Example of such API is
libxl_domain_unpause(). Because of this, separate patch add support for QMP
over vchan also to the old API.

There is also a need for external locking access to vchan connection (one
server can handle only one client and libvchan does not verify this). Since I
haven't found any asynchronous locking primitives in libxl, for now I've added
flock() on a lock file, but this also needs to be converted to async version.

The actual stubdomain implementation is here:

    https://github.com/marmarek/qubes-vmm-xen-stubdom-linux
    (branch for-upstream, tag for-upstream-v3)

See readme there for build instructions.
Beware: building on Debian is dangerous, as it require installing "dracut",
which will remove initramfs-tools. You may end up with broken initrd on
your host.

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

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

Remaining parts for eliminating dom0's instance of qemu:
 - do not force QDISK backend for CDROM
 - multiple consoles support in xenconsoled

Changes in v2:
 - apply review comments by Jason Andryuk
Changes in v3:
 - rework qemu arguments handling (separate xenstore keys, instead of \x1b 
separator)
 - add QMP over libvchan, instead of console
 - add protocol documentation
 - a lot of minor changes, see individual patches for full changes list
 - split xenconsoled patches into separate series

Cc: Simon Gaiser <simon@xxxxxxxxxxxxxxxxxxxxxx>
Cc: Eric Shelton <eshelton@xxxxxxxxx>
Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Cc: Wei Liu <wei.liu2@xxxxxxxxxx>

Eric Shelton (1):
  libxl: Handle Linux stubdomain specific QEMU options.

Marek Marczykowski-Górecki (16):
  Document ioemu MiniOS stubdomain protocol
  Document ioemu Linux stubdomain protocol
  libxl: fix qemu-trad cmdline for no sdl/vnc case
  libxl: Allow running qemu-xen in stubdomain
  libxl: write qemu arguments into separate xenstore keys
  libxl: create vkb device only for guests with graphics output
  xl: add stubdomain related options to xl config parser
  tools/libvchan: notify server when client is connected
  libxl: typo fix in comment
  libxl: move xswait declaration up in libxl_internal.h
  libxl: use vchan for QMP access with Linux stubdomain, libxl__ev_qmp_* version
  libxl: use vchan for QMP access with Linux stubdomain, non-async version
  libxl: add save/restore support for qemu-xen in stubdomain
  tools: add missing libxenvchan cflags
  libxl: add locking for libvchan QMP connection
  libxl: require qemu in dom0 even if stubdomain is in use

 docs/man/xl.cfg.5.pod.in     |  23 +-
 docs/misc/stubdom.txt        | 103 +++++++++-
 tools/Rules.mk               |   6 +-
 tools/libvchan/init.c        |   3 +-
 tools/libxl/Makefile         |   2 +-
 tools/libxl/libxl_create.c   |  51 +++-
 tools/libxl/libxl_dm.c       | 241 ++++++++++++++------
 tools/libxl/libxl_internal.h | 134 ++++++-----
 tools/libxl/libxl_mem.c      |   6 +-
 tools/libxl/libxl_qmp.c      | 433 ++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_types.idl  |   3 +-
 tools/xl/xl_parse.c          |   7 +-
 12 files changed, 856 insertions(+), 156 deletions(-)

base-commit: 4595e7d86aea956a55f8e5a607f3b8c8c3519f77
-- 
git-series 0.9.1

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