Thomas Huth <[email protected]> writes: > On 17/03/2026 10.27, Markus Armbruster wrote: >> Thomas Huth <[email protected]> writes: >> >>> On 17/03/2026 08.35, Markus Armbruster wrote: >>>> Thomas Huth <[email protected]> writes: >>>> >>>>> On 12/03/2026 09.15, Markus Armbruster wrote: >>>>>> Markus Armbruster <[email protected]> writes: >>>>> ... >>>>>>> These crashes escape tests/qtest/device-introspect-test, because it >>>>>>> covers only HMP "device_add T,help", not CLI "-device T,help". >>>>>> >>>>>> Anyone wants to cook up a patch to cover -device? > ... >>>> Another idea to conserve cycles: use a unit test instead. >>> >>> Unit tests don't have a way yet to determine which qemu-system-xyz binaries >>> are available, do they? ... so that would need some more logic in the >>> meson.build file there - not sure whether that's worth the effort, I think >>> the device-introspect qtest is likely a better place? >> >> A unit test isn't supposed to run qemu-system-xyz. Instead, it mocks up >> the environment and just runs "the unit". In this case, >> qdev_device_help(). >> >> This is less protection than a qtest, but it can also be a lot faster. > > Ok, fair, but how do you link the code for *all* the devices into that unit > test? ... I guess that would need a lot of function stubbing?
Likely too much, i.e. you're right. >>> Or maybe add it to scripts/device-crash-test ? >> >> That's another option. > > Maybe the best option, since it does already similar things. The only > disadvantage is that we don't run it for all targets by default in the CI. Feels quite acceptable to me. The existing qtest should catch most offenders, and all offenders capable of murdering guests. Letting a -device T,help bug slip through our testing isn't the end of the world.
