On 5/11/2026 8:36 PM, Philippe Mathieu-Daudé wrote: > On 11/5/26 23:07, Pierrick Bouvier wrote: >> On 5/11/2026 1:46 PM, Cédric Le Goater wrote: >>> On 5/11/26 19:59, Pierrick Bouvier wrote: >>>> On 5/11/2026 10:48 AM, Philippe Mathieu-Daudé wrote: >>>>> On 11/5/26 17:48, Cédric Le Goater wrote: >>>>>> Hello, >>>>>> >>>>>> On 5/6/26 15:55, Philippe Mathieu-Daudé wrote: >>>>>>> Introduce a source set common to system / user. Start it >>>>>>> with the files built in both sets: 'cpu_models_user.c' >>>>>>> and 'gdbstub.c' No logical change intended. >>>>>>> >>>>>>> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> >>>>>>> Reviewed-by: Ilya Leoshkevich <[email protected]> >>>>>>> Message-Id: <[email protected]> >>>>>> >>>>>> This change introduced a regression with PCI passthrough which >>>>>> stopped working. Guest kernel reports : >>>>>> >>>>>> [ 0.156501] zpci: PCI is not supported because CPU >>>>>> facilities 69 >>>>>> or 71 are not available >>>>>> >>>>>> and other devices (ap, ccw) are impacted too I think. >>>>> >>>>> Is it something we could test with the mainstream CI, or does this >>>>> requires specific hardware? >>>>> >>>> >>>> It could be tested with a tcg arm vm + nested VM with PCI passthrough. >>> >>> Yes, adding VFIO tests to the QEMU upstream CI would be great. >>> >>>> However, the problem is that you need to cross-compile QEMU in CI to >>>> test current version to launch the nested VM. > > I guess remember one of your scripts close to that setup, mounting > the same directory in nested guest with: > > -virtfs \ > local,path=$(pwd),mount_tag=host,security_model=mapped,readonly=off > > Same could be used with s390x / x86 I suppose.
Yes, it's another possibility. I just like the idea of generating the image on the fly, and not have to host it/update it anywhere. Considering this, it's "free" to include a binary at creation vs a mount network. For reference, this is the script to create an ext4 image from container [1], and the custom init booting [2] and running a custom command. [1] https://github.com/p-b-o/qemu-linux-stack/blob/master/build_rootfs.sh [2] https://github.com/p-b-o/qemu-linux-stack/blob/master/rootfs/common/init The scripts in themselves are not important, but it shows how small they are, and thus, easy to develop and maintain.
