On Thu, Oct 17, 2019 at 17:35:30 +0200, David Hildenbrand wrote:
> On 17.10.19 17:31, David Hildenbrand wrote:
> > On 17.10.19 17:18, David Hildenbrand wrote:
> >> On 17.10.19 17:16, Jiri Denemark wrote:
> >>> Hi David and David,
> >>>
> >>> I'm working on libvirt's support [1] for query-machines'
> >>> default-cpu-type, which is supposed to return the type of the default
> >>> CPU model that QEMU uses for each machine type. Rather than hard coding
> >>> the default in libvirt (which we currently do on x86), we ask QEMU for
> >>> the default CPU model and use it unless a user asks for a specific CPU
> >>> model explicitly.
> >>>
...
> >>> This situation on s390x is not so complicated, but not really better.
> >>> The default CPU is said to be "qemu" for all machine types, which works
> >>> fine for TCG domains, but it doesn't work on KVM because QEMU complains
> >>> that some features requested in the CPU model are not available. In
> >>> other words the "qemu" CPU model is not runnable on KVM. This a bit
> >>> similar to what happens on x86_64, but QEMU just ignores missing
> >>> features and starts happily there.
> >>
> >> The default model under KVM is "host", under TCG it's "qemu". We should
> >> not use "qemu" under KVM, although it might work on some setups ...
> >>
> >> Where/how is this default model detected?
All this is about probing QEMU capabilities so that we can tell users
what to expect and let them change the default. E.g., qemu64 default CPU
model on x86_64 is never the right one to be used with KVM. By making
the default CPU model visible in the domain XML even before the domain
gets started, we help users detect such suboptimal configurations.
> >
> > ... target/s390x/kvm.c:kvm_arch_init()
> >
> > MachineClass *mc = MACHINE_GET_CLASS(ms);
> >
> > mc->default_cpu_type = S390_CPU_TYPE_NAME("host");
> >
> >
> > I think the call order should make sure that "host" is set after "qemu"
> > is set. I'll go ahead and verify that.kvm_arch_init(
> >
>
> configure_accelerator(current_machine, argv[0]) -> kvm_arch_init()
>
> is called after
>
> current_machine = MACHINE(object_new(object_class_get_name(
> OBJECT_CLASS(machine_class))));
>
> and therefore after the .class_init function of the machine was called.
>
> 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.
Jirka
