[From nobody Wed Aug 12 06:23:06 2026 Received: (at submit) by bugs.debian.org; 26 Feb 2026 06:08:49 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=4.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, DKIM_VALID_EF,FOURLA,FREEMAIL_FROM,HAS_PACKAGE,HTML_MESSAGE,MULTALT, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 57; hammy, 150; neutral, 161; spammy, 0. spammytokens: hammytokens:0.000-+--trixie, 0.000-+--bookworm, 0.000-+--upstreams, 0.000-+--upstream's, 0.000-+--QEMU Return-path: <ender.altaboxes@gmail.com> Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:53250) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.96) (envelope-from <ender.altaboxes@gmail.com>) id 1vvUYK-005HII-18 for submit@bugs.debian.org; Thu, 26 Feb 2026 06:08:49 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-59e5f52b13eso588341e87.2 for <submit@bugs.debian.org>; Wed, 25 Feb 2026 22:08:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772086123; cv=none; d=google.com; s=arc-20240605; b=PkJf0ZcUM+Tb81cI/F1pv5Z++Rb9OMUbMu7WM9CwnD6IW2a5MnTQZ83CYrTLWrJy0B 4vSVk8tZ5syPOQjYS8+jCHruhj1/9FW7rnSEFp+vaY0BJVAiXPltN35LQgDjsVVRPlUj QLzkyN9TYxf765RicaKAe6o40Cx7YQiY4fxT51BuItmXh4+Px5ndkXXLISZodbnvBDW8 oBwZ+U/vldx++0Bw2bTtjd0XsvQkNqgd9pw7DUNMfwyUEAiH/Ryj6lVihmOvA1zY8qzQ 4o/M0ecpWKygUhj+K+P8sbDbw+usoxaPJqeHJbpj6UeZwbXgIoKb+HkgR+dlGLWupwyE dgaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=BPGKdb/vGQ7QbvRIeYp7nbIQttfrdnKVwJrIBw0Tz8I=; fh=lIR/7veID2U00tj1D35G+ANF85YwqTAbTuNH/WGncTs=; b=V5EF7sbd7oBP+bqoIMVs+V+9kvacjQdLjBkM3ZBpAhUayy6XS8wQNUZZbi4f/+ca1r cUZ/L09+BLHsAAvWD9dksoqT8Bedk0/xSA3gXSaYYz1F1sHJyVO8LcTKDL2yydp8hfyX 7kL1L74PCUBBulzCyNpBLd/P0dlITPil8W22VL0diWjJXM2K2LDEdfi8I33dVdY7EbXa t0Ztnot45tjZWLJ8qpXXFIX4aM90XJsv1h3FSSLcnUWBz7oaCg/MB0DLRqfix1hh11Kr SP4Py08l9/IbtE/DS2QkJKA1vjsmfIlwh82qqts8gpyQPffCTlDDNv2bp5F9Lu9DxTSH US0Q==; darn=bugs.debian.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772086123; x=1772690923; darn=bugs.debian.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=BPGKdb/vGQ7QbvRIeYp7nbIQttfrdnKVwJrIBw0Tz8I=; b=BG5mkwtyEoN8nTN+Uwm+iozRMuew6fCFXsGbKeFL3jzb/Y71YGHq8aD8UIgwgHjb2g r5jQJbScdydU41BSJtjnQ4AHtr+6AWLZMswNKPdoBnzf+8J7COsTb1WjFft689+g5oKL ria/vXNzClibqsA0cSvaPJhRISlcKt6cQJQpIZnsAOmtQQDJHHARpNPP1RaV8COMspm/ 1Y0wxKHkJ7gmlwRfRgoLXOwzgeIM5oKJpXJQsOeaKumIBhTOwOZ7bhK/gJe0P7jty0dX Efyrwcd8kHfg4Fy8R9wOsczA446lamU2sRwh4gBZj1bBX17z3kTW1iQXZqjJqMWDixyw Uf9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772086123; x=1772690923; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BPGKdb/vGQ7QbvRIeYp7nbIQttfrdnKVwJrIBw0Tz8I=; b=QUXr+tTcaiUMn8S62pCSzF5MebtwLsj+s7FhDipICD4XO5dKUAiCtWUvXF/twKZhl/ Lojzdbq5a9NHPc8W9XIhpnHzGUZ1iZsNPU9/dpxuOmk4TKlBbrl7GXVXzy0jtbL1iIoh 1W1PahZd2Z7CW3u5v7IZ55bLAbF8VY0aeuEuQYw/COVIJIQMrtvts4LWkMXagefsNzED 2V4DXwHof4rSIZHag4Mica3N7rUq2Gp25++rXyCQLvpUeYcILJdvlHhI2YyVFQrmDvj6 0i3t5M+IfLo17H78QUNMMsZQbVU9aPGYd+t5SIt7lFKCxpTv0/yFJ9vnQOHyHVunLbwx nbWw== X-Gm-Message-State: AOJu0YzOE970ZW18ROwHFpqaTMmFVYGuabQ6F/N3mc7vqGylHqHdvbnZ qR/bR9tygKSzneVJTSsHpC2ugCo5NrN8K58MwwcHfS30LXhFk/+nBvYBcTy9ro5Qfi9X2KY2GpY fGkP0rZ6MxR2Msl1dA4xDO3MGW346EhzsJWj6jjYXTQ== X-Gm-Gg: ATEYQzwOXqCIWlRetUz6R+enFZh7vf+QffurxYfXHkjdECZJK2tyGq99KPZ2B2LnIqG bOYOHTjt3woc0GqZENnfLn7aH8FYdxSCCmsC11cQw53lE5+Lvui/+o+zUZ3ayLMb8QmA8Lb4Qw5 hZyF2pGtWTgrsm4JbYXHYKHeYdg59KsdD8nbSIzpSBvl9dGwX2UdgqYJ0tZ8FyFoStVJYQz67P6 7ZDUwO5WGHHCVG9MiHEjGcNimQ2MXF7ZNu/oBXrdHaSmIzb2eaoqYV4mhXlBGTSrltcu8rrFzEn mu9CGG7Z04ycBW3NKKc= X-Received: by 2002:a05:6512:1085:b0:59f:9348:5483 with SMTP id 2adb3069b0e04-5a105d91965mr830448e87.5.1772086123147; Wed, 25 Feb 2026 22:08:43 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?David_Mart=C3=ADnez_Moreno?= <ender.altaboxes@gmail.com> Date: Wed, 25 Feb 2026 22:08:32 -0800 X-Gm-Features: AaiRm50ir9S0BjZTQx4RO49mwBzpPpQaEtus-i_tJ4QXDnt8rwhpaGd0xScwNgQ Message-ID: <CAErCQkjFRudZc4Gqoya0czhKqQH8z=M=moz=RTWxWdwKohwBcg@mail.gmail.com> Subject: Xen 4.20 uses an outdated spec of QMP, so passthrough USB is broken. To: submit@bugs.debian.org Content-Type: multipart/alternative; boundary="000000000000e1b752064bb3f362" Delivered-To: submit@bugs.debian.org --000000000000e1b752064bb3f362 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D2 hostaddr=3D2 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. =C2=AF\_(=E3=83=84)_/=C2=AF 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. --=20 Consultor de seguridad - Security consultant Desarrollador de Debian - Debian developer --000000000000e1b752064bb3f362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Package: libxenmisc</div><div>Version: 4.20.0+68-g35c= b38b222-1<br>Severity: important</div><div><br></div><div>=C2=A0 =C2=A0 I&#= 39;m tagging this important=C2=A0because I imagine that not everyone uses U= SB on DomU instances.=C2=A0 Since the upgrade to trixie, passthrough USB ha= s stopped working with Xen instances.=C2=A0 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).<br><br>=C2=A0 =C2=A0 When = tried to add a hub and a device to a DomU machine, whether it's manuall= y or in a config file battle-tested with 4.17.5, an error pops:<br><br>pa-x= en:~# /usr/lib/xen-4.20/bin/xl usbdev-attach test_usb hostbus=3D2 hostaddr= =3D2<br>libxl: error: libxl_qmp.c:1837:qmp_ev_parse_error_messages: Domain = 7:Parameter 'hostaddr' expects uint64<br>libxl: error: libxl_device= .c:1500:device_addrm_aocomplete: unable to add device<br>libxl_device_usbde= v_add failed.</div><div><br></div><div>=C2=A0 =C2=A0 I'm attaching a pa= tch in a subsequent mail to fix this bug, valid against 4.20-4.20.2.=C2=A0 = I haven't sent it upstream yet, but I'll defer to you.=C2=A0 A Xen = instance with=C2=A0a patched libxenmisc1 has been running in production sin= ce November 6th, 2025 without causing=C2=A0any problems.=C2=A0 I'd like= to request an upload to stable-proposed-updates so I don't have to hol= d the 4.20.2 Xen packages carrying security updates.</div><div><br></div><d= iv>=C2=A0 =C2=A0 I'll leave some details on how I found out and solved = it in case somebody hits this same problem:</div><div><br></div><div>=C2=A0= =C2=A0 After much debugging, what happens is that Xen appears to be using = a really old version of QMP (<a href=3D"https://wiki.qemu.org/Documentation= /QMP">https://wiki.qemu.org/Documentation/QMP</a>), the JSON protocol that = Xen uses to talk to the QEMU instance over a named pipe.=C2=A0 You can talk= to the instance (in this case #10) with a command like this:</div><div><br= ></div><div>socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-10</div><div><br></= div><div>=C2=A0 =C2=A0 The instance greets you with:<br><br>{"QMP&quot= ;: {"version": {"qemu": {"micro": 3, "mi= nor": 0, "major": 10}, "package": "Debian 1:1= 0.0.3+ds-0+deb13u1"}, "capabilities": ["oob"]}}<br= ><br></div><div>=C2=A0 =C2=A0 If you then try to execute a similar command = to the one Xen sends with libxl:<br><br></div><div>{"execute": &q= uot;qmp_capabilities" }{"execute":"device_add",&qu= ot;id":2025,"arguments":{"id":"xenusb-5-2&quo= t;,"driver":"usb-host","bus":"xenusb-0.0= ","port":"1","hostbus":"5",&qu= ot;hostaddr":"2"}}<br>{"return": {}}<br><br></div>= <div>=C2=A0 =C2=A0 Then you get the error:<br><br></div><div>{"id&quot= ;: 2025, "error": {"class": "GenericError", &= quot;desc": "Parameter 'hostaddr' expects uint64"}}<= br><br></div><div>=C2=A0 =C2=A0 Now that you can play back and forth with t= he message, you can actually send the value of keys "hostaddr" an= d "hostbus"=C2=A0as a number, instead of a string, and it starts = working.</div><div><br></div><div>=C2=A0 =C2=A0 I narrowed it down for now = to the creation of the USB controller and USB individual devices.=C2=A0 I i= magine that QEMU was upgraded between bookworm and trixie, and they depreca= ted receiving the affected values as strings.=C2=A0=C2=AF\_(=E3=83=84)_/=C2= =AF</div><div><br></div><div>=C2=A0 =C2=A0 I still cannot understand how th= is was still not fixed on upstream's git HEAD branch as of mid November= , when I checked last!=C2=A0 One would think that USB passthrough was more = popular... :-D</div><div><br></div><div>=C2=A0 =C2=A0 Thanks,</div><div><br= ></div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ender.</div><span cl= ass=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmai= l_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Consu= ltor de seguridad - Security consultant<br>Desarrollador de Debian - Debian= developer</div></div></div></div> --000000000000e1b752064bb3f362-- ]