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. > > Intel comes to mind first :) >
I just mentioned Arm because I'm more familiar with what is implemented for emulating nested virtualization, but any other arch would be welcome of course! > Couldn't we install the QEMU CI build artifacts into a VM matching > the configuration in which they were built ? I assume the artifacts > remain available for some time. > We could totally do that. We just need to agree on one environment, with a list of dependencies preinstalled. Ideally, it should be what we have in our cross containers, which are based on debian. It would mean there is zero additional maintenance burden. Only question is where to get the kernel, and if we should take the one from distro, or compile our own. I don't have the bandwith to implement this at the moment, but if anyone has time and want more details, I would be happy to talk about it. > We could then install them in an L1 VM with a predefined emulated > igb device and assigned that device to an L2 VM. > > I think this would also benefit the QEMU CI in other ways, as > nested setups allow tests to run with higher privileges. > >> This would imply to have a "standard" target environment (like debian >> with X,Y,Z deps preinstalled) which CI does not have at the moment. > > Why one "standard" target ? All arch are impacted, as well as various > distro flavors. > I was using the word "target" for the environment it will target (i.e. which distro), and not referring to arch. Probably a poor choice of words, given that target already has too many meanings in QEMU :). >> So in practice, it's hard to test it. > > It is. > > Thanks, > > C. >
