Comment 12 for bug 1861125

I think the discussion went already further with David explaining why we might just consider this unsupported/Won't-Fix in his opinion - but for completeness let me report the info that Jiri asked for.

Just running on QMP:
{ "execute": "qmp_capabilities" }
{ "execute": "query-machines" }
And reporting the section about s390-ccw-virtio-2.5 used in the reported case.

Old qemu 2.5:
{"name": "s390-ccw-virtio-2.5", "cpu-max": 255}

New qemu 4.2:
{"hotpluggable-cpus": true, "name": "s390-ccw-virtio-2.5", "numa-mem-supported": false, "default-cpu-type": "host-s390x-cpu", "cpu-max": 248, "deprecated": false}

So the assumption that the old type now reports "default-cpu-type": "host-s390x-cpu" was correct.

@David: while "Migration without CPU model support is not guaranteed to work either way - especially when migrating between different HW/Hypervisors" is true, it was working quite well the last few years as long as you stayed on the same machine (which is common and trivial on s390x due to the LPARs as you know).
And about "weren't any real enterprise users", you know how this works on the mainframe - you have very few early adopters and if you burn them too much no one is left :-)

I agree that the current QMP answer of "host-s390x-cpu" seems correct and adding a new interface definitely seems too much for this.
But if a quirk in libvirt to detect the set of older machine-types to handle them differently wouldn't be too hard I'd appreciate that solution (vs a Won't Fix) for sure.