qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default CPU models on s390x and ppc64


From: David Hildenbrand
Subject: Re: Default CPU models on s390x and ppc64
Date: Thu, 17 Oct 2019 17:35:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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.

We use query-cpu-definitions for translating the default CPU type to the
actual CPU model we need to pass to -cpu by looking up the CPU model
with matching typename.

However, all this seems to work only with TCG on both s390x and ppc64.
The issues I met with KVM on each architecture are described below.

On ppc64 the default CPU type reported by query-machines is
power*-powerpc64-cpu, while IIUC QEMU would effectively use -cpu host by
default. In fact -cpu power8 is mostly just a fancy alias to -cpu host
on a Power8 machine. But QEMU even rewrites typename of the current host
CPU model to host-powerpc64-cpu. Which means on a Power8 host the power8
CPU model would have typename=host-powerpc64-cpu while the default CPU
type would still use power8*-powerpc64-cpu. Thus we may just fail to
find any CPU model corresponding to the default CPU model.

And to make it even worse, the default CPU model changes with machine
type. E.g., pseries-3.1 uses power8_v2.0-powerpc64-cpu while pseries-4.2
uses power9_v2.0-powerpc64-cpu. However, starting QEMU with pseries-4.2
machine type and the reported default -cpu power9 fails on any
non-Power9 host. That said QEMU just lies about the default CPU model.

So for all combinations of (pseries-3.1, pseries-4.2) machine types and
(Power8, Power9) hosts, one will get the following mixed results:

- pseries-3.1 on Power8: no default CPU model will be detected, QEMU
     starts fine with it's own default
- pseries-4.2 on Power9: same as above
- pseries-3.1 on Power9: -cpu power8 (not sure if this works, though)
- pseries-4.2 on Power8: -cpu power9, QEMU doesn't start


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?


... 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"

--

Thanks,

David / dhildenb



reply via email to

[Prev in Thread] Current Thread [Next in Thread]