Re: [PULL v2 000/105] move check-tcg into the meson build

["Alex Bennée" <alex.bennee@linaro.org>]

John Snow <jsnow@redhat.com> writes:

> On Tue, Sep 15, 2026 at 4:19 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> John Snow <jsnow@redhat.com> writes:
>>
>> > On Fri, Sep 4, 2026 at 2:04 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>> >>
>> >> On Fri, 4 Sept 2026 at 16:08, Alex Bennée <alex.bennee@linaro.org> wrote:
>> >> >
>> >> > The following changes since commit d2843fbf80260e4346c856819e8cea11768c9d0e:
>> >> >
>> >> >   Merge tag 'pull-riscv-to-apply-20260904' of https://github.com/alistair23/qemu into staging (2026-09-04 09:43:27 +0100)
>> >> >
>> >> > are available in the Git repository at:
>> >> >
>> >> >   https://gitlab.com/stsquad/qemu.git tags/pull-11.1-check-tcg-meson-040926-2
>> >> >
>> >> > for you to fetch changes up to 7a485176838e6b6044e73f925d308bb4b3002597:
>> >> >
>> >> >   MAINTAINERS: add maintainer for tcg/tests meson infrastructure (2026-09-04 16:06:22 +0100)
>> >> >
>> >> > ----------------------------------------------------------------
>> >> > tests/tcg: conversion to meson
>> >> >
>> >> >   - remove unused variable from multiarch/memory
>> >> >   - standardise checking plugin output
>> >> >   - bump minimal meson to 1.6.0
>> >> >   - introduce meson plumbing for check-tcg
>> >> >   - return error code if docker probe fails
>> >> >   - add CI/self/mem test to gdbstub prot-none tests
>> >> >   - use raw opcode for fprcvt test in arm
>> >> >   - remove unused variables from gpc-test
>> >> >   - teach probe-gdb-support about mips
>> >> >   - identify or1k pc register
>> >> >   - port check-tcg logic to meson (all targets)
>> >> >   - update documentation
>> >> >   - add Pierrick as a maintainer for tests/tcg
>> >
>> > Hi, I'm having difficulties building after this PR, after eb7f0c14 in
>> > particular.
>> >
>> > I keep seeing stuff like this:
>> >
>> > FAILED: [code=1] tests/tcg/x86_64-softmmu-hello.test
>> > /home/jsnow/src/qemu/tests/tcg/../docker/docker.py --command podman
>> > run --run-as-current-user -w /home/jsnow/src/qemu/build -v
>> > /home/jsnow/src/qemu:/home/jsnow/src/qemu debian-amd64-cross
>> > x86_64-linux-gnu-gcc
>> > /home/jsnow/src/qemu/tests/tcg/multiarch/system/hello.c -o
>> > tests/tcg/x86_64-softmmu-hello.test -static -MMD -MF
>> > tests/tcg/x86_64-softmmu-hello.d -Wall -Werror -O0 -g
>> > -fno-strict-aliasing -nostdlib -ffreestanding -Wa,--noexecstack -I
>> > /home/jsnow/src/qemu/tests/tcg/x86_64/system/../../minilib
>> > /home/jsnow/src/qemu/tests/tcg/x86_64/system/../../minilib/printf.c
>> > ../tests/tcg/x86_64/system/boot.S -Wl,-T
>> > ../tests/tcg/x86_64/system/kernel.ld -Wl,-melf_x86_64
>> > -Wl,--no-warn-rwx-segments -Wl,--build-id=none -lgcc
>> > cc1: fatal error:
>> > /home/jsnow/src/qemu/tests/tcg/multiarch/system/hello.c: Permission
>> > denied
>> > compilation terminated.
>> > cc1: fatal error:
>> > /home/jsnow/src/qemu/tests/tcg/x86_64/system/../../minilib/printf.c:
>> > Permission denied
>> > compilation terminated.
>> > cc1: fatal error: ../tests/tcg/x86_64/system/boot.S: Permission denied
>> > compilation terminated.
>>
>> Try the v2 I've just posted. That fixed up the handling of mapping your
>> host user id into the container so there are less surprises when it
>> writes to the mapped volume.
>>
>>   https://patchew.org/QEMU/20260915201601.1207839-1-alex.bennee@linaro.org/
>>
>
> No dice there. Fully rebooted my machine just in case there were
> permission issues lingering in my session; still getting perm errors:
>
> jsnow@jsnow-thinkpadp16vgen1 ~/s/q/build (review)> cat /etc/subuid
> jsnow:100000:65536
> jsnow@jsnow-thinkpadp16vgen1 ~/s/q/build (review)> cat /etc/subgid
> jsnow:100000:65536
>
> jsnow@jsnow-thinkpadp16vgen1 ~/s/q/build (review)> ls -lahZ
> ../tests/tcg/multiarch/system/hello.c
> -rw-r--r--. 1 jsnow jsnow unconfined_u:object_r:user_home_t:s0 229 May
>  7  2025 ../tests/tcg/multiarch/system/hello.c
>
> Setting the dreaded `setenforce 0` it does seem to work, so I suppose
> the issue is that my source tree is not labeled in a way that permits
> it to be mapped into a container.
>
> I'd like to ask that we have a hello world style check that tests to
> see if it can access your source tree and, if not, proposes some
> solutions:
>
> (1) Prompt user to check that rootless podman is functioning
> correctly, check your subuid/subgid etc

Perhaps we should just run the same compile test when we detect
containers.

> (2) Prompt user to check selinux labels
> (3) Suggest that container builds can be disabled with --disable-containers
>
> Possibly even as part of configure we do a simple hello-world test and
> if it works, enable containers by default and if it does not, we
> disable them. If you pass --enable-containers and the hello world
> fails, configure exits with an error.
>
> Or some other such thing.
>
> --js

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro