Package: libxenmisc
Version: 4.20.0+68-g35cb38b222-1
Severity: important
I'm tagging this important because I imagine that not everyone uses USB
on DomU instances. Since the upgrade to trixie, passthrough USB has
stopped working with Xen instances. This is critical for us, as one of the
DomU instances needs access to a USB HSM that previously worked in USB
passthrough mode in `bookworm` (Xen 4.17.5).
When tried to add a hub and a device to a DomU machine, whether it's
manually or in a config file battle-tested with 4.17.5, an error pops:
pa-xen:~# /usr/lib/xen-4.20/bin/xl usbdev-attach test_usb hostbus=2
hostaddr=2
libxl: error: libxl_qmp.c:1837:qmp_ev_parse_error_messages: Domain
7:Parameter 'hostaddr' expects uint64
libxl: error: libxl_device.c:1500:device_addrm_aocomplete: unable to add
device
libxl_device_usbdev_add failed.
I'm attaching a patch in a subsequent mail to fix this bug, valid
against 4.20-4.20.2. I haven't sent it upstream yet, but I'll defer to
you. A Xen instance with a patched libxenmisc1 has been running in
production since November 6th, 2025 without causing any problems. I'd like
to request an upload to stable-proposed-updates so I don't have to hold the
4.20.2 Xen packages carrying security updates.
I'll leave some details on how I found out and solved it in case
somebody hits this same problem:
After much debugging, what happens is that Xen appears to be using a
really old version of QMP (https://wiki.qemu.org/Documentation/QMP), the
JSON protocol that Xen uses to talk to the QEMU instance over a named
pipe. You can talk to the instance (in this case #10) with a command like
this:
socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-10
The instance greets you with:
{"QMP": {"version": {"qemu": {"micro": 3, "minor": 0, "major": 10},
"package": "Debian 1:10.0.3+ds-0+deb13u1"}, "capabilities": ["oob"]}}
If you then try to execute a similar command to the one Xen sends with
libxl:
{"execute": "qmp_capabilities"
}{"execute":"device_add","id":2025,"arguments":{"id":"xenusb-5-2","driver":"usb-host","bus":"xenusb-0.0","port":"1","hostbus":"5","hostaddr":"2"}}
{"return": {}}
Then you get the error:
{"id": 2025, "error": {"class": "GenericError", "desc": "Parameter
'hostaddr' expects uint64"}}
Now that you can play back and forth with the message, you can actually
send the value of keys "hostaddr" and "hostbus" as a number, instead of a
string, and it starts working.
I narrowed it down for now to the creation of the USB controller and
USB individual devices. I imagine that QEMU was upgraded between bookworm
and trixie, and they deprecated receiving the affected values as
strings. ¯\_(ツ)_/¯
I still cannot understand how this was still not fixed on upstream's
git HEAD branch as of mid November, when I checked last! One would think
that USB passthrough was more popular... :-D
Thanks,
Ender.
--
Consultor de seguridad - Security consultant
Desarrollador de Debian - Debian developer
