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
