Re: [PATCH v2 5/6] automation/qtb: add QTB framework README

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

On 2026-10-27 18:32 +0100, Oleksii Kurochko wrote:
>
>
> On 8/27/26 11:42 AM, Baptiste Le Duc wrote:
> > Document the qtb riscv64 test framework in a README.
>
> I understand that you are trying to introduce things so they could be
> traceble. But probaly it makes mentioned in cover letter or somewhere
> else that thre is README which probably should be read first for easier
> understanding of the patch series.

Agreed, v3's cover letter will point to the README as the place to
start.

Note that in v3 the framework will run with pytest: the CLI, config.yaml, the
<type>.yaml files and the timeout/attempts logic are gone, and the
README is rewritten accordingly. Answers on the points that still apply
below.

> > +  config.yaml                The machine catalog (shared across test types)
> > +  dts/                       Jinja2 device-tree templates (host, common)
>
> There is only one template, qemu-host.dts.j2, nothing "common".

Right, the README now only describes qemu-host.dts.j2.

> > +- `qemu.qtb`, QEMU's Python package (`python/` in the QEMU tree)
>
> qemu.qtb isn't in QEMU's python/ (it isn't upstream yet, as the cover
> letter says), so this sends people to the wrong place. Please point to
> the fork and the commit used by the container in patch 1, or better,
> say that the simplest way to get all prerequisites is that container,
> and show how to run a test in it with containerize.

Done: the README says it is not upstream, points to the fork and the
commit pinned in the container's dockerfile, and recommends the
container, with a new "Running in the container" section showing how to
build it and run the tests through containerize.

> > +Run from `automation/scripts/`, or give the full path from the Xen tree 
> > root
> > +(`./automation/scripts/qemu_smoke_riscv64.py ...`), which is what CI does.
>
> Neither works without QTB_BINARIES_DIR unless xen is copied to
> automation/scripts/qtb/riscv/binaries/ (see my reply to patch 3), and
> the README doesn't say where to put it.

There is no default location any more: the directory holding the xen
binary is given with a required --binaries-dir option, which the README
documents and the container example uses. A test run without it fails
at setup with an explicit message.

> > +`--log-dir` (run only) collects the QEMU process log, the qtest log, and 
> > each
> > +console as `con<N>.log`: `con0.log` is Xen's own console, the only one 
> > wired
>
> There is no qtest log: QtbMachine passes "-qtest-log none". The
> riscv64-qtest-<pid>.log file is QEMU's stdout/stderr; "qtest" comes
> from the machine name.

Right, the README now describes riscv64-qtest-<pid>.log as QEMU's
stdout/stderr, named after the machine.

> > +`config.yaml` is the machine catalog. `binaries:` are build artifacts 
> > resolved
> > +under `binaries/` (overridable with `$QTB_BINARIES_DIR`); absolute paths 
> > pass
> > +through.
>
> This reads as binaries/ at the top of the tree, while it is actually
> automation/scripts/qtb/riscv/binaries/.

Gone with --binaries-dir, see above.

> > +- `mmu_type` (default `sv48`): Xen host MMU type.
>
> See my reply to patch 2: Xen doesn't use this.

Right, Xen only reads mmu-type from dom0less guest nodes. I dropped it
for host in MachineConfig and in dts in v3.

> > +3. bound each wait by `timeout` seconds, retrying a timed-out wait up to
> > +   `attempts` times
>
> See my reply to patch 3: nothing is retried, attempts only multiplies
> the timeout.

attempts is gone in v3: console-test waits for each expected string
with a single timeout.

Thanks,
Baptiste

-- 
Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>