I don't see how the default cpu model could not be "host" if qemu was
started with "--enable-kvm"
I guess the problem could be that QEMU capabilities probing in libvirt
is done with -machine none. We first probe with KVM enabled and then for
a few specific commands reprobe with TCG only. We could do it with
query-machines too to get different default CPU models depending on the
accelerator, but it wouldn't actually help.
The full command line used for capabilities probing is
qemu-system-s390x \
-S \
-no-user-config \
-nodefaults \
-nographic \
-machine none,accel=kvm:tcg \
-qmp unix:/tmp/qmp-ivG4UN/qmp.monitor,server,nowait \
-pidfile /tmp/qmp-ivG4UN/qmp.pid \
-daemonize
One of the command we send is
{"execute":"query-kvm","id":"libvirt-5"}
and the reply is
{"return": {"enabled": true, "present": true}, "id": "libvirt-5"}
Which means KVM is usable and enabled, but still query-machines returns
{
"return": [
{
"hotpluggable-cpus": true,
"name": "s390-ccw-virtio-4.0",
"numa-mem-supported": false,
"default-cpu-type": "qemu-s390x-cpu",
"cpu-max": 248,
"deprecated": false
},
{
"hotpluggable-cpus": true,
"name": "s390-ccw-virtio-3.1",
"numa-mem-supported": false,
"default-cpu-type": "qemu-s390x-cpu",
"cpu-max": 248,
"deprecated": false
},
...
]
}
So it seems the code is run during the machine initialization and thus
it doesn't affect what query-machines returns with -machine none.