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. 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. > > 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 -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
