[PATCH BlueZ v1 1/2] doc: test-runner: document the virtual machine architecture

[PATCH BlueZ v1 1/2] doc: test-runner: document the virtual machine architecture

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Add an ARCHITECTURE section describing how the virtual machine instance
is created and how it communicates with the launcher.

Document that the tool is both the launcher and the guest init, that
there is no disk image and the launcher root filesystem is shared
read-only over 9p, the TEST* variables passed on the kernel command
line, the sandbox mounts and the writable overlays needed on top of the
read-only root.

Also document the console and controller attachment: the guest console
is /dev/hvc0, and '-u' attaches the given socket as a second virtio
console, /dev/hvc1, on which the N_HCI line discipline is set so the
transport is HCI H:4 to the hci_uart driver. Mention '-o' as the way
additional channels are added, as done by test-functional.

While at it, add the missing '-H' and '-o' entries to OPTIONS.

Assisted-by: opencode:claude-opus-5
---
 doc/test-runner.rst | 105 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/doc/test-runner.rst b/doc/test-runner.rst
index 12f80df04964..6429e80fc75b 100644
--- a/doc/test-runner.rst
+++ b/doc/test-runner.rst
@@ -25,10 +25,115 @@ OPTIONS
 :-U/--usb=<qemu_args>: Provide USB device
 :-P/--pcie=<qemu_args>: Provide PCIe device
 :-q/--qemu=<path>: QEMU binary
+:-H/--qemu-host-cpu: Use host CPU (requires KVM support)
 :-k/--kernel=<image>: Kernel image (bzImage)
 :-F/--virtiofs[=<path>]: Path to virtiofsd, or no to disable virtio-fs
+:-o/--option=<opt>: Additional argument passed to QEMU
 :-h/--help: Show help options
 
+ARCHITECTURE
+============
+
+**test-runner(1)** is both the launcher and the guest ``init``.  When run
+normally it builds a QEMU command line and starts QEMU, replacing itself
+with it unless it has to stay around to clean up after a ``virtiofsd`` or
+a passed-through PCIe device.  The same binary is re-executed inside the
+guest as PID 1, where it sets up the sandbox and runs the requested
+command::
+
+    ┌────────────────────────────────────────────────────────┐
+    │ test-runner (launcher)                                 │
+    │   ├ virtiofsd (optional)  ←─── vhost-user ───┐         │
+    │   └ qemu                                     │         │
+    │      ┌──── guest ─────────────────────────────┴─────┐  │
+    │      │ kernel (bzImage), init=test-runner           │  │
+    │      │   ├ prepare_sandbox()                        │  │
+    │      │   ├ attach controller (optional)             │  │
+    │      │   ├ start dbus / bluetoothd / btmon / btvirt │  │
+    │      │   ├ fork+exec <command>                      │  │
+    │      │   └ reboot() when it exits                   │  │
+    │      └──────────────────────────────────────────────┘  │
+    └────────────────────────────────────────────────────────┘
+
+There is no disk image.  The launcher's root filesystem is passed through
+read-only and used as the guest root, so the guest runs the very same
+BlueZ build tree that was just compiled.
+
+Two passthrough implementations are supported.  When ``virtiofsd`` is
+available, a ``virtiofsd`` process is started alongside QEMU and exports
+``/`` over a vhost-user socket::
+
+    virtiofsd --socket-path <tmpdir>/virtiofs --shared-dir / --readonly
+              --tag /dev/root ...
+    -chardev socket,id=virtiofs0,path=<tmpdir>/virtiofs
+    -device  vhost-user-fs-pci,queue-size=1024,chardev=virtiofs0,tag=/dev/root
+    -object  memory-backend-memfd,id=mem0,size=<mem>,share=on
+    -numa    node,memdev=mem0
+    -append  "... rootfstype=virtiofs root=/dev/root ..."
+
+Since vhost-user requires the guest memory to be shareable, the machine
+memory is backed by a memfd object.  Otherwise, the fallback is 9p::
+
+    -fsdev local,id=fsdev-root,path=/,readonly=on,security_model=none
+    -device virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root
+    -append "... rootfstype=9p rootflags=trans=virtio,version=9p2000.u ..."
+
+9p passthrough is noticeably more CPU intensive, so virtio-fs is used by
+default whenever possible.
+
+Either way the kernel command line also carries the launcher settings::
+
+    -append "... init=<test-runner> TESTHOME=<cwd> TESTARGS='<command>' ..."
+
+The ``TEST*`` variables carry the options given to the launcher over to
+the guest instance.
+
+As PID 1, ``prepare_sandbox()`` mounts ``sysfs``, ``proc``, ``devtmpfs``,
+``devpts``, ``debugfs`` and ``tmpfs`` on ``/dev/shm``, ``/run`` and
+``/tmp``.  Since the root is read-only, writable ``tmpfs`` instances are
+also overlaid on ``/var/lib/bluetooth``, ``/etc/bluetooth``,
+``/etc/dbus-1`` and ``/usr/share/dbus-1``.
+
+Console and controller
+----------------------
+
+The guest console is a virtio console, ``/dev/hvc0``, multiplexed onto the
+launcher's stdio, so kernel messages and the command output appear on the
+terminal that started test-runner.
+
+With ``-u``, the given UNIX socket (typically a **btproxy(1)** or
+**btvirt(1)** server socket) is attached as a second virtio console::
+
+    -chardev socket,path=<socket>,id=bt0
+    -device  virtconsole,chardev=bt0,name=bt.0
+
+In the guest this is ``/dev/hvc1``.  test-runner sets the ``N_HCI`` line
+discipline with the H:4 protocol on it, so the kernel ``hci_uart`` driver
+registers an ``hciX`` device.  The transport is therefore plain HCI H:4
+carried over a virtio console to a UNIX socket on the launcher side::
+
+    guest                                             launcher
+    ┌───────────────────────────┐                 ┌──────────────────┐
+    │ bluetoothd                │                 │ btvirt/btproxy   │
+    │   ↕ mgmt / HCI sockets    │                 │                  │
+    │ hci_uart  hci0            │   virtconsole   │                  │
+    │   ↕ H:4                   │     bt.0        │                  │
+    │ /dev/hvc1  ───────────────┼─────────────────┤  AF_UNIX socket  │
+    └───────────────────────────┘                 └──────────────────┘
+
+With ``-U`` a host USB controller is passed through instead (a
+``qemu-xhci`` controller plus the given ``usb-host`` device), and with
+``-P`` a PCIe controller is passed through via vfio-pci.  In both cases
+the guest uses the normal ``btusb``/``btintel_pcie`` drivers.
+
+Extra QEMU devices
+------------------
+
+``-o`` appends raw arguments to the QEMU command line.  This is how
+additional channels between the launcher and the guest are added, for
+example by **test-functional(1)**, which attaches its own virtio-serial
+ports and a writable shared directory this way.
+
 Kernel
 ======
 
-- 
2.55.0

[PATCH BlueZ v1 2/2] doc: test-functional: document the test environment architecture

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Add an ARCHITECTURE section describing the split between the Pytest
upper tester, which runs on the developer machine and drives the test,
and the VM hosts started via test-runner, which run the BlueZ and kernel
instances under test.

Document the control, log, tty and shared channels set up on top of
test-runner and how they relate to the existing options, and the btvirt
and USB controller topologies. Details of the virtual machine setup
itself are left to test-runner, and writing VM-side test code to the
pytest-bluezenv documentation.

Also fix the temporary directory paths, which are named after
pytest-bluezenv rather than bluez-func-test.

Assisted-by: opencode:claude-opus-5
---
 doc/test-functional.rst | 92 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git a/doc/test-functional.rst b/doc/test-functional.rst
index f45867f2dbe3..4a784e7850a3 100644
--- a/doc/test-functional.rst
+++ b/doc/test-functional.rst
@@ -143,9 +143,97 @@ Tests that require kernel image or USB controllers are skipped if none
 are available. Normally, tests use `btvirt`.
 
 VM instances share a directory ``/run/shared`` with host machine,
-located on host usually in ``/tmp/bluez-func-test-*/shared-*``.  Core
+located on host usually in ``/tmp/pytest-bluezenv-*/shared-*``.  Core
 dumps etc. are copied out from it before test instance is shut down.
 
+ARCHITECTURE
+============
+
+A test run consists of the Pytest process (the *upper tester*, running on
+the developer machine) and one or more *VM hosts*.  Each VM host is a
+separate **test-runner(1)** instance, i.e. a QEMU virtual machine booting
+the given kernel image with the developer machine's root filesystem passed
+through read-only.  The VM hosts are wired together by a Bluetooth
+controller: either the emulated **btvirt(1)** controller, or a real USB
+controller passed through to the VM::
+
+    developer machine (upper tester)            VM hosts (lower testers)
+    ┌──────────────────────────────┐           ┌────────────────────────┐
+    │ pytest                       │  control  │ test-runner / qemu #0  │
+    │  ├ host #0 ──────────────────┼───────────┤  └ bluetoothd, obexd,  │
+    │  ├ host #1 ─────────┐        │    log    │    bluetoothctl, ...   │
+    │  │                  │        │           └───────────┬────────────┘
+    │  └ btvirt ──────────┼────────┼── HCI ────────────────┘
+    │                     │        │           ┌────────────────────────┐
+    └─────────────────────┼────────┘           │ test-runner / qemu #1  │
+                          └────────── control ─┤  (same as above)       │
+                                     log, HCI  └────────────────────────┘
+
+The upper tester never runs Bluetooth code itself; it only drives the VM
+hosts.  Test code executes inside the VMs, which is what makes it possible
+to test two independent BlueZ and kernel instances talking to each other.
+
+VM hosts are started lazily and reused between tests where possible, since
+booting is the expensive part of a run.
+
+Channels
+--------
+
+Each VM host is started by ``test-runner`` with additional QEMU devices
+(``-o``), providing the following channels between the upper tester and
+the VM:
+
+control
+	Virtio-serial port used for the RPC connection over which the
+	upper tester drives the VM: starting daemons, running commands,
+	collecting results and exceptions.
+
+log
+	Virtio-serial port carrying the log records produced inside the
+	VM, with their timestamps.  This is what ``--log-filter`` and
+	``--no-log-reorder`` operate on, and why accurate guest time
+	(``chronyd`` plus the KVM PTP clock) matters.
+
+tty
+	A serial port with a root shell on it, used by
+	``test/test-functional-attach``.  The socket path is printed at
+	startup as a ``socat`` command line.
+
+shared
+	Writable shared directory, ``/run/shared`` in the VM and
+	``/tmp/pytest-bluezenv-*/shared-*`` on the developer machine.
+	Core dumps and ``btmon`` captures are written there and collected
+	before the VM is shut down.
+
+The ``test-runner`` console (``/dev/hvc0``) additionally carries kernel
+messages and is captured as the host log.
+
+Controllers
+-----------
+
+By default a single ``btvirt`` process runs on the developer machine and
+provides an emulated BR/EDR/LE controller to every VM host over a UNIX
+socket, also bridging the air interface between them::
+
+    VM host #0                 developer machine              VM host #1
+    ┌────────────┐            ┌─────────────────┐            ┌────────────┐
+    │ bluetoothd │            │     btvirt      │            │ bluetoothd │
+    │  hci0      ├─ HCI H:4 ──┤ (emulated air   ├── HCI H:4 ─┤  hci0      │
+    └────────────┘            │      link)      │            └────────────┘
+                              └─────────────────┘
+
+See **test-runner(1)** for how the socket is attached to the VM.
+
+With ``--usb`` the ``btvirt`` process is not started; each VM host gets a
+real USB controller passed through instead, and the VMs talk over the
+actual radio.  Tests still prefer ``btvirt`` unless ``--force-usb`` is
+given.
+
+Writing test code that runs in the VM, and the available VM-side
+facilities, are documented by `pytest-bluezenv
+<https://pypi.org/project/pytest-bluezenv/>`__.
+
+
 REQUIREMENTS
 ============
 
@@ -357,7 +445,7 @@ e.g. by running with ``--trace`` option.
 
 To do it manually, when starting the tester will log a line like::
 
-	TTY: socat /tmp/bluez-func-test-q658swgi/bluez-func-test-tty-0 STDIO,rawer
+	TTY: socat /tmp/pytest-bluezenv-q658swgi/pytest-bluezenv-tty-0 STDIO,rawer
 
 with the location of the socket where the serial is connected to.
 
-- 
2.55.0

RE: [BlueZ,v1,1/2] doc: test-runner: document the virtual machine architecture

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: doc/test-runner.rst:25
error: doc/test-runner.rst: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth

RE: [BlueZ,v1,1/2] doc: test-runner: document the virtual machine architecture

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 4573 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1164802/

---Test result---

Test Summary:
CheckPatch                    PASS      0.52 seconds
GitLint                       PASS      0.41 seconds
BuildEll                      PASS      19.42 seconds
BluezMake                     PASS      371.20 seconds
MakeCheck                     PASS      14.23 seconds
MakeDistcheck                 PASS      139.01 seconds
CheckValgrind                 PASS      232.65 seconds
CheckSmatch                   PASS      290.59 seconds
bluezmakeextell               PASS      95.03 seconds
TestFunctional                FAIL      1057.13 seconds
IncrementalBuild              PASS      389.26 seconds
ScanBuild                     PASS      1125.63 seconds

Details
##############################
Test: TestFunctional - FAIL
Desc: Run test-functional
Output:
FAIL functional.test_kernel_testers::test_kernel_selftest[hosts11-vm1-noc]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
FAIL functional.test_adv_monitor::test_adv_monitor_GHSA_hhgc_hfgf_8m4x[hosts1-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
FAIL functional.test_btmgmt::test_btmgmt_info[hosts10-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
FAIL functional.test_bluetoothctl::test_bluetoothctl_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
FAIL functional.test_bluetoothctl::test_bluetoothctl_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
FAIL functional.test_bluetoothctl::test_bluetoothctl_script_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
FAIL functional.test_bluetoothctl::test_bluetoothctl_script_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
FAIL functional.test_a2dp::test_a2dp_transport_created[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_a2dp::test_a2dp_transport_acquire[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_obex::test_obex_ftp_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_obex::test_obex_ftp_get[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_obex::test_obexctl_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_agent::test_agent_pair_bredr[accept-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_agent::test_agent_pair_bredr[reject-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_avrcp::test_avrcp_GHSA_m2vx_pw5f_rc8v[hosts3-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_unicast_transport_created[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_unicast_transport_acquire[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_broadcast_transport_created[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_broadcast_transport_created[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_broadcast_transport_acquire[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bap_broadcast_transport_acquire[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bap::test_bass_past_transport_acquire[hosts6-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_bredr[hosts8-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_le[hosts9-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"


https://github.com/bluez/bluez/pull/2528

---
Regards,
Linux Bluetooth

Re: [BlueZ,v1,1/2] doc: test-runner: document the virtual machine architecture

[Luiz Augusto von Dentz]

Hi Pauli,

On Mon, Sep 14, 2026 at 7:30 PM <bluez.test.bot@gmail.com> wrote:
>
> This is automated email and please do not reply to this email!
>
> Dear submitter,
>
> Thank you for submitting the patches to the linux bluetooth mailing list.
> This is a CI test results with your patch series:
> PW Link:https://patchwork.kernel.org/series/1164802/
>
> ---Test result---
>
> Test Summary:
> CheckPatch                    PASS      0.52 seconds
> GitLint                       PASS      0.41 seconds
> BuildEll                      PASS      19.42 seconds
> BluezMake                     PASS      371.20 seconds
> MakeCheck                     PASS      14.23 seconds
> MakeDistcheck                 PASS      139.01 seconds
> CheckValgrind                 PASS      232.65 seconds
> CheckSmatch                   PASS      290.59 seconds
> bluezmakeextell               PASS      95.03 seconds
> TestFunctional                FAIL      1057.13 seconds
> IncrementalBuild              PASS      389.26 seconds
> ScanBuild                     PASS      1125.63 seconds
>
> Details
> ##############################
> Test: TestFunctional - FAIL
> Desc: Run test-functional
> Output:
> FAIL functional.test_kernel_testers::test_kernel_selftest[hosts11-vm1-noc]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> FAIL functional.test_adv_monitor::test_adv_monitor_GHSA_hhgc_hfgf_8m4x[hosts1-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> FAIL functional.test_btmgmt::test_btmgmt_info[hosts10-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_script_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_script_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> FAIL functional.test_a2dp::test_a2dp_transport_created[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_a2dp::test_a2dp_transport_acquire[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_obex::test_obex_ftp_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_obex::test_obex_ftp_get[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_obex::test_obexctl_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_agent::test_agent_pair_bredr[accept-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_agent::test_agent_pair_bredr[reject-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_avrcp::test_avrcp_GHSA_m2vx_pw5f_rc8v[hosts3-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_unicast_transport_created[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_unicast_transport_acquire[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_broadcast_transport_created[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_broadcast_transport_created[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_broadcast_transport_acquire[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bap_broadcast_transport_acquire[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bap::test_bass_past_transport_acquire[hosts6-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_bredr[hosts8-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_le[hosts9-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
>
>
> https://github.com/bluez/bluez/pull/2528

Any idea how to fix the errors above? Locally they seem to work just
fine, so perhaps this is something related to the CI environment.

> ---
> Regards,
> Linux Bluetooth
>


-- 
Luiz Augusto von Dentz

Re: [BlueZ,v1,1/2] doc: test-runner: document the virtual machine architecture

[Pauli Virtanen]

Hi,

ti, 2026-09-15 kello 11:56 -0400, Luiz Augusto von Dentz kirjoitti:
> On Mon, Sep 14, 2026 at 7:30 PM <bluez.test.bot@gmail.com> wrote:
> > This is automated email and please do not reply to this email!
> > 
> > Dear submitter,
> > 
> > Thank you for submitting the patches to the linux bluetooth mailing list.
> > This is a CI test results with your patch series:
> > PW Link:https://patchwork.kernel.org/series/1164802/
> > 
> > ---Test result---
> > 
> > Test Summary:
> > CheckPatch                    PASS      0.52 seconds
> > GitLint                       PASS      0.41 seconds
> > BuildEll                      PASS      19.42 seconds
> > BluezMake                     PASS      371.20 seconds
> > MakeCheck                     PASS      14.23 seconds
> > MakeDistcheck                 PASS      139.01 seconds
> > CheckValgrind                 PASS      232.65 seconds
> > CheckSmatch                   PASS      290.59 seconds
> > bluezmakeextell               PASS      95.03 seconds
> > TestFunctional                FAIL      1057.13 seconds
> > IncrementalBuild              PASS      389.26 seconds
> > ScanBuild                     PASS      1125.63 seconds
> > 
> > Details
> > ##############################
> > Test: TestFunctional - FAIL
> > Desc: Run test-functional
> > Output:
> > FAIL functional.test_kernel_testers::test_kernel_selftest[hosts11-vm1-noc]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> > FAIL functional.test_adv_monitor::test_adv_monitor_GHSA_hhgc_hfgf_8m4x[hosts1-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> > FAIL functional.test_btmgmt::test_btmgmt_info[hosts10-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_script_show[hosts7-vm1]: failed on setup with "ConnectionResetError: [Errno 104] Connection reset by peer"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_script_list[hosts7-vm1]: failed on setup with "pytest_bluezenv.rpc.RemoteTimeoutError: Failed to establish connection"
> > FAIL functional.test_a2dp::test_a2dp_transport_created[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_a2dp::test_a2dp_transport_acquire[hosts0-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_obex::test_obex_ftp_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_obex::test_obex_ftp_get[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_obex::test_obexctl_list[hosts12-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_agent::test_agent_pair_bredr[accept-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_agent::test_agent_pair_bredr[reject-hosts2-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_avrcp::test_avrcp_GHSA_m2vx_pw5f_rc8v[hosts3-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_unicast_transport_created[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_unicast_transport_acquire[hosts4-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_broadcast_transport_created[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_broadcast_transport_created[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_broadcast_transport_acquire[lc3-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bap_broadcast_transport_acquire[pbp-hosts5-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bap::test_bass_past_transport_acquire[hosts6-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_bredr[hosts8-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > FAIL functional.test_bluetoothctl::test_bluetoothctl_pair_le[hosts9-vm2]: failed on setup with "RuntimeError: Process exited unexpectedly"
> > 
> > 
> > https://github.com/bluez/bluez/pull/2528
> 
> Any idea how to fix the errors above? Locally they seem to work just
> fine, so perhaps this is something related to the CI environment.

The runner does not appear to pass /dev/kvm to the Docker image:

2026-09-15 01:29:28,720:DEBUG :> 2026-09-15 01:26:20.908511 OUT host.0.0 : qemu-system-x86_64: failed to initialize kvm: No such file or directory
2026-09-15 01:29:28,720:DEBUG :> 2026-09-15 01:26:20.909088 OUT host.0.0 : qemu-system-x86_64: falling back to tcg

Didn't figure out yet how to do, GPT suggests it's

https://github.com/pv/bluez-action-ci/commit/452d3471ab4bdb5ef2020ac24cd9e7ae87ea550d

I'll try to test if that works now.

-- 
Pauli Virtanen

Re: [PATCH BlueZ v1 1/2] doc: test-runner: document the virtual machine architecture

[patchwork-bot+bluetooth]

Hello:

This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon, 14 Sep 2026 13:51:33 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> 
> Add an ARCHITECTURE section describing how the virtual machine instance
> is created and how it communicates with the launcher.
> 
> Document that the tool is both the launcher and the guest init, that
> there is no disk image and the launcher root filesystem is shared
> read-only over 9p, the TEST* variables passed on the kernel command
> line, the sandbox mounts and the writable overlays needed on top of the
> read-only root.
> 
> [...]

Here is the summary with links:
  - [BlueZ,v1,1/2] doc: test-runner: document the virtual machine architecture
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=b4176324909d
  - [BlueZ,v1,2/2] doc: test-functional: document the test environment architecture
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=6dc064623c57

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html