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

Message

Jason Andryuk Feb. 1, 2024, 9:40 p.m. UTC

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

Comments

Anthony PERARD Feb. 13, 2024, 11:41 a.m. UTC | #1

On Thu, Feb 01, 2024 at 04:40:01PM -0500, Jason Andryuk wrote:
> 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.

Yes, looks like it. It would be possible to have libxl retry
automatically since Linux eject and unlock the cd-rom tray, then QEMU
does send an event via QMP about this, so libxl could retry after
receiving the event. Waiting for events is just not implemented in
libxl, but that something that could be done.

The event is, for example:
    'event': 'DEVICE_TRAY_MOVED', 'data': {'device': 'ide-5632', 'tray-open': True, 'id': 'ide-5632'}

Cheers,