On 9/14/2026 4:17 AM, Daniel P. Berrangé wrote: > On Mon, Sep 14, 2026 at 11:41:51AM +0200, Paolo Bonzini wrote: >> Il lun 14 set 2026, 07:54 Pierrick Bouvier < >> [email protected]> ha scritto: >> >>> On 9/13/26 9:57 PM, Paolo Bonzini wrote: >>>> >>>> >>>> Il ven 11 set 2026, 19:49 Alex Bennée <[email protected] >>>> <mailto:[email protected]>> ha scritto: >>>> >>>> Thanks for pointing this out. I hadn't noticed the issue as I guess >>> we >>>> don't build firmware in the CI. That said on my current tree: >>>> >>>> cd /home/alex/lsrc/qemu.git/builds/all/pc-bios/s390-ccw >>>> make >>>> -Wno-stringop-overflow detected >>>> -fno-stack-protector detected >>>> -Wno-array-bounds detected >>>> -Wno-gnu detected >>>> -march=z900 detected >>>> Assembling start.o >>>> Compiling main.o >>>> Compiling bootmap.o >>>> Compiling jump2ipl.o >>>> Compiling sclp.o >>>> Compiling menu.o >>>> Compiling netmain.o >>>> Compiling virtio.o >>>> Compiling virtio-net.o >>>> Compiling virtio-scsi.o >>>> Compiling virtio-blkdev.o >>>> Compiling cio.o >>>> Compiling dasd-ipl.o >>>> Compiling virtio-ccw.o >>>> Compiling clp.o >>>> Compiling pci.o >>>> Compiling virtio-pci.o >>>> Compiling secure-ipl.o >>>> Linking s390-ccw.elf >>>> Stripping s390-ccw.elf into s390-ccw.img >>>> >>>> So it seems to be working. How do you usually invoke the build? >>>> >>>> > Fearing the worst, I started converting to use meson directly >>> (which >>>> > is probably a noble goal anyway). I still don't have a workable >>>> image, >>>> > as inheriting the common meson cc/ld flags exposes a bunch of >>> other >>>> > problems. Will keep poking, but I'd like to know if there's an >>>> > easier/better option here? >>>> >>>> I suspect the easiest way would be to move the rom specific cross >>>> compiler detection into a configure script within pc-bios. Paolo >>> wdyt? >>>> >>>> >>>> I would prefer to revert this and load the config file from meson >>> instead. >>>> >>>> Paolo >>>> >>> >>> I would be happy to see only the related part reverted if possible, and >>> not all the patch. That said, no strong opinion, just a preference to >>> avoid seeing people start depending on this config file for other >>> things, instead of doing things properly in meson. >>> >> >> This is documented as a task for configure, so I don't think it's a problem >> not to do it in meson. In fact creating containers is not done by meson >> (it's done by make) so there is no real reason to do it outside configure. > > Are you referring to the tests/docker/Makefile.include targets ? > > Pierrick's series here directly invokes docker.py from meson instead > of the targets from tests/docker/Makefile. >
There might be some confusion with what the series introduced. To make it clear, it does not touch, nor use tests/docker/Makefile.include. Each tests/tcg/arch declares which container it depends on, and we have tests/tcg/meson.build that automatically builds it if needed for tests. Reverting that will not be very easy to be honest, as it's a core part of the new logic. > IMHO it would be nice to replace tests/docker/Makefile.include with > a meson.build too. Yes, that would make it rely on a configured > build tree, but IMHO that's an acceptable tradeoff to get more > stuff into meson natively. > That's easy, and would allow us to get rid of tests/docker/Makefile.include completely, by adding matching targets make container-image-debian-*. Also, we can have a top target 'container-images'. With this, people can build them with ninja or make. As Daniel mentioned, the trade off is to run configure first, and I feel it's quite acceptable. What do you think Paolo? >> >> Having firmware have its own configure script is also bad, since you end up >> having code duplication. >> >> Overall, I don't see the big issue in reverting this patch. > > NB, if this is reverted then we'll need to pull back in the fix I > dropped: > > https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg01624.html > > With regards, > Daniel
