[PATCH v2 0/3] libxl: Stubdom cd-rom changing support

[Jason Andryuk <jandryuk@xxxxxxxxx>]

These patches enable cd-rom media changing for an HVM with a linux
stubdom.

v1 didn't support these empty drives.  The code came out of OpenXT which
has a hack - null.iso.  null.iso is an ISO with no contents.  OpenXT
doesn't actually eject the cd-rom, it just inserts null.iso.  This patch
set has QEMU present empty media.

The first patch creates an empty file, /run/xen/empty-cdrom.%u, for Phy
drives that are "empty".  The place holder simplifies things because the
block scripts don't work for an empty params.  Even if the scripts were
modified for that, a stubdom will timeout on startup when the empty
disk/blkback never connects.  The empty file works around these issues.

The second patch allows use of Phy backend drives for a cd-rom.  This
works for non-stubdom HVMs.  Actually special casing stubdoms didn't
work.

The third patch expands the cd-rom changing code to support the stubdom
case.

To change the cd-rom medium, libxl will:
 - QMP eject the medium from QEMU
 - block-detach the old PV disk
 - block-attach the new PV disk
 - QMP change the medium to the new PV disk by fdset-id

xl cd-eject follows the above through connecting the new PV disk,
empty-cdrom.%u.  It skips the QMP media change.  This keeps the xenstore
entries which are needed to identify that a cd-rom drive is present.  If
the xenstore entries were removed on eject, libxl wouldn't find the
device (hdc) for a subsequent cd-insert.

The QMP change insert uses fdset-id STUBDOM_FDSET_CD + $disk - 'a'.
That is, hda -> 'a', so
STUBDOM_FDSET_CD + 'a' - 'a' = STUBDOM_FDSET_CD.
For hdc:
STUBDOM_FDSET_CD + 'c' - 'a' = STUBDOM_FDSET_CD + 2.

The stubdom must internally handle adding /dev/xvdc to the appropriate
fdset inside QEMU.

A script like this:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-core/initrdscripts/initramfs-stubdomain/qemu-xvdc-add-fd.sh

Can be called by busybox mdev configured like this:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-core/busybox/files/mdev.conf

(OpenXT mdev as the hotplug helper works, but with a ~Qubes stubdom, I
had to run mdev as a daemon, mdev -d.)

Linux locks the cd-rom by default?  That means the QMP eject commands
fail, but then Linux unlocks.  Re-running a second time works.  Windows
doesn't do that.

There are spurious messages sometimes like:
libxl: error: libxl_qmp.c:1837:qmp_ev_parse_error_messages: Domain 5:Could not 
dup FD for /dev/fdset/8002 flags 0: No such file or directory

libxl doesn't know when the stubdom has setup the fdset.  Since it gets
those errors, it'll retry adding to the fdset.

Jason Andryuk (3):
  libxl: Create empty cdrom file for stubdom
  libxl: Allow Phy backend for CDROM devices
  libxl: Enable stubdom cdrom changing

 docs/misc/stubdom.txt             |  16 ++
 tools/libs/light/libxl_device.c   |  17 +-
 tools/libs/light/libxl_disk.c     | 345 +++++++++++++++++++++++++++---
 tools/libs/light/libxl_domain.c   |   4 +
 tools/libs/light/libxl_internal.h |   1 +
 5 files changed, 344 insertions(+), 39 deletions(-)

-- 
2.43.0