Re: [PATCH v2 1/6] Add a QTB container to run the Xen riscv64 tests

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 8/27/26 11:42 AM, Baptiste Le Duc wrote:
> QTB (QEMU Test Bench) is a Python framework, developed as part of AMD's Xen
> safety initiative, that drives a live QEMU instance over qtest and QMP. It
> gives a test full access to the machine while the emulation runs: read and
> write the consoles, inspect the registers and the memory, inject interrupts.
>
> For now the riscv64 CI tests only use it to read the Xen console in the
> smoke test, since DomU is not supported yet. Once it is, the same
> framework will read and write the DomU consoles and inject IRQs, so the
> tests can assert an interrupt reaches the expected guest and vCPU.
>
> QTB is not upstream in QEMU yet, though it is planned to be, so get the
> framework from AMD's fork gitlab.com/xen-project/people/amd/qemu and
> pip-installs qemu.qtb from it.
s/pip-installs/pip-install/

It would also be good to say explicitly that only the Python package
comes from the fork, while the emulator itself is Debian's
qemu-system-riscv64.

> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
> ---
>   containerize                            |  1 +
>   images/debian/13-qtb-riscv64.dockerfile | 45 +++++++++++++++++++++++++
This is more a question for the CI maintainers: should this container
live in test-artifacts at all?

So far test-artifacts only holds containers for building its own
artifacts (kernels, rootfs, microcode), which xen.git then pulls in via
cross-project needs:. The containers the xen.git test jobs run in,
including debian:13-riscv64, which already carries
qemu-system-riscv64 for the test phase, and the hardware runner ones,
are all built from automation/build/ in xen.git and pulled from
XEN_REGISTRY.

Having it as automation/build/debian/13-qtb-riscv64.dockerfile in
xen.git would keep the container next to its only user, avoid the new
ARTIFACTS_REGISTRY variable and the image: override in patch 6, and
drop the "must land first" ordering between two repositories.

>   2 files changed, 46 insertions(+)
>   create mode 100644 images/debian/13-qtb-riscv64.dockerfile
>
> diff --git a/containerize b/containerize
> index dad9afa..477b670 100755
> --- a/containerize
> +++ b/containerize
> @@ -31,6 +31,7 @@ case "_${CONTAINER}" in
>       _alpine-3.24-arm64-base) CONTAINER="${BASE}/alpine:3.24-arm64-base" ;;
>       _alpine-3.24-arm64-build) CONTAINER="${BASE}/alpine:3.24-arm64-build" ;;
>       _alpine-3.24-x86_64-base) CONTAINER="${BASE}/alpine:3.24-x86_64-base" ;;
> +    _debian-13-qtb-riscv64) CONTAINER="${BASE}/debian:13-qtb-riscv64" ;;
>       _alpine-3.24-x86_64-build|_) CONTAINER="${BASE}/alpine:3.24-x86_64-build" 
> ;;
It seems like these lines are sorted/grouped by architecture name. So I 
think it will be better to put _debian-13-qtb-riscv64 here.

>   esac
>   
> diff --git a/images/debian/13-qtb-riscv64.dockerfile b/images/debian/13-qtb-riscv64.dockerfile
> new file mode 100644
> index 0000000..86215d3
> --- /dev/null
> +++ b/images/debian/13-qtb-riscv64.dockerfile
> @@ -0,0 +1,45 @@
> +# syntax=docker/dockerfile:1
> +FROM --platform=linux/amd64 debian:trixie-slim
> +LABEL maintainer.name="The Xen Project"
> +LABEL maintainer.email="xen-devel@xxxxxxxxxxxxxxxxxxxx"
> +
> +ENV DEBIAN_FRONTEND=noninteractive
> +
> +ARG QEMU_REPO=https://gitlab.com/xen-project/people/amd/qemu.git
> +ARG QEMU_COMMIT=24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab
> +
This commit is currently the tip of the 'safety' branch, and no tag
points to it. If that branch gets rebased, the commit may become
unreachable and the container will no longer rebuild. Could a tag be
created for it in the fork?

> +RUN <<EOF
> +#!/bin/bash
> +    set -eu
> +
> +    useradd --create-home user
> +
> +    apt-get update
> +
> +    DEPS=(# Base environment
> +        ca-certificates
> +        device-tree-compiler
> +        git
> +        python3-jinja2
> +        python3-minimal
> +        python3-pip
> +        python3-yaml
> +
> +        # Qemu for test phase
> +        qemu-system-riscv64
> +    )
> +
> +    apt-get -y --no-install-recommends install "${DEPS[@]}"
> +
> +    # QTB framework
> +    git init /tmp/qemu
> +    git -C /tmp/qemu fetch --depth 1 "$QEMU_REPO" "$QEMU_COMMIT"
> +    git -C /tmp/qemu checkout FETCH_HEAD
> +    pip install --break-system-packages /tmp/qemu/python[qtb]
Please quote the argument: unquoted, /tmp/qemu/python[qtb] is a glob
matching /tmp/qemu/python{q,t,b}, and it works only because none of
them exists.

Also, this fetches qemu.qmp, pexpect, pygdbmi and ptyprocess from PyPI
with only lower bounds, so the result depends on when the container is
built: building it now installs qemu.qmp 0.0.6, while the fork ships
0.0.5. The fork already bundles wheels for all of the [qtb]
dependencies in python/wheels/, so they can be installed offline. I've
checked that the following works, with python3-setuptools added to
DEPS:

    pip install --break-system-packages --no-index --no-build-isolation \
        --find-links /tmp/qemu/python/wheels "/tmp/qemu/python[qtb]"

Minor: python3-pytest isn't installed, so the unit tests from patch 4
can't be run in this container, although the README asks only for
"the prerequisites above plus pytest". It would be convenient to have
it here.

FWIW, I've built the container and run the smoke test from this series
in it against a locally built riscv64 Xen (console-test run
dom0less-1smp-0domu-1vcpu-aplic-imsic-null): it passes.

~ Oleksii

> +
> +    rm -rf /tmp/qemu
> +    rm -rf /var/lib/apt/lists/*
> +EOF
> +
> +USER user
> +WORKDIR /build