Default CPU models on s390x and ppc64

Default CPU models on s390x and ppc64

[Jiri Denemark]

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.


So what do you suggest we should do? Currently I just restricted all the
default CPU model staff to TCG on both s390x and ppc64. So either we can
be happy with the current state or we need to come up with a solution
that would allow us to enable this even for KVM.

Thanks,
Jirka

[1] https://www.redhat.com/archives/libvir-list/2019-October/msg00872.html

Re: Default CPU models on s390x and ppc64

[David Hildenbrand]

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?

> 
> 
> So what do you suggest we should do? Currently I just restricted all the
> default CPU model staff to TCG on both s390x and ppc64. So either we can
> be happy with the current state or we need to come up with a solution
> that would allow us to enable this even for KVM.
> 
> Thanks,
> Jirka
> 
> [1] https://www.redhat.com/archives/libvir-list/2019-October/msg00872.html
> 


-- 

Thanks,

David / dhildenb

Re: Default CPU models on s390x and ppc64

[David Hildenbrand]

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.

-- 

Thanks,

David / dhildenb

Re: Default CPU models on s390x and ppc64

[David Hildenbrand]

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

Re: Default CPU models on s390x and ppc64

[Jiri Denemark]

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

Re: Default CPU models on s390x and ppc64

[David Hildenbrand]

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

Right.

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

I can see what's going on. kvm_arch_init() will only modify the single, 
current machine, not all machines. That means, we would actually have to 
overwrite the default model in all machines, not just the one we are 
starting with (here:none).

Hm....

-- 

Thanks,

David / dhildenb

Re: Default CPU models on s390x and ppc64

[Peter Maydell]

On Thu, 17 Oct 2019 at 17:09, David Hildenbrand <david@redhat.com> wrote:
> 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 ...

Possibly a tangent, but on Arm the approach we used to deal
with "'-cpu host' only works for kvm" was to define a "-cpu max"
meaning "best thing you can give me", which is an alias for
-cpu host with KVM and an alias for a CPU with all the extra
features we have emulation support under TCG. Then users can
use '-cpu max' and have something that generally will DTRT
regardless of accelerator.

thanks
-- PMM

Re: Default CPU models on s390x and ppc64

[David Hildenbrand]

On 17.10.19 18:13, Peter Maydell wrote:
> On Thu, 17 Oct 2019 at 17:09, David Hildenbrand <david@redhat.com> wrote:
>> 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 ...
> 
> Possibly a tangent, but on Arm the approach we used to deal
> with "'-cpu host' only works for kvm" was to define a "-cpu max"
> meaning "best thing you can give me", which is an alias for
> -cpu host with KVM and an alias for a CPU with all the extra
> features we have emulation support under TCG. Then users can
> use '-cpu max' and have something that generally will DTRT
> regardless of accelerator.
> 

We do have "-cpu max" on s390x as well. (under TCG, it enables some 
additional features over "qemu", under KVM it is basically "host).

-- 

Thanks,

David / dhildenb

Re: Default CPU models on s390x and ppc64

[Jiri Denemark]

On Thu, Oct 17, 2019 at 17:13:10 +0100, Peter Maydell wrote:
> On Thu, 17 Oct 2019 at 17:09, David Hildenbrand <david@redhat.com> wrote:
> > 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 ...
> 
> Possibly a tangent, but on Arm the approach we used to deal
> with "'-cpu host' only works for kvm" was to define a "-cpu max"
> meaning "best thing you can give me", which is an alias for
> -cpu host with KVM and an alias for a CPU with all the extra
> features we have emulation support under TCG. Then users can
> use '-cpu max' and have something that generally will DTRT
> regardless of accelerator.

This thread is not really about a CPU model that users could universally
use for both TCG or KVM. It's about checking what CPU model is used by
QEMU if no CPU model is specified on the command line.

BTW, I was told aarch64 is a bit different and QEMU fails to start with
KVM unless -cpu host is explicitly specified. Is that correct?

Jirka

Re: Default CPU models on s390x and ppc64

[Peter Maydell]

On Fri, 18 Oct 2019 at 15:02, Jiri Denemark <jdenemar@redhat.com> wrote:
>
> On Thu, Oct 17, 2019 at 17:13:10 +0100, Peter Maydell wrote:
> > On Thu, 17 Oct 2019 at 17:09, David Hildenbrand <david@redhat.com> wrote:
> > > 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 ...
> >
> > Possibly a tangent, but on Arm the approach we used to deal
> > with "'-cpu host' only works for kvm" was to define a "-cpu max"
> > meaning "best thing you can give me", which is an alias for
> > -cpu host with KVM and an alias for a CPU with all the extra
> > features we have emulation support under TCG. Then users can
> > use '-cpu max' and have something that generally will DTRT
> > regardless of accelerator.
>
> This thread is not really about a CPU model that users could universally
> use for both TCG or KVM. It's about checking what CPU model is used by
> QEMU if no CPU model is specified on the command line.

Yes, but the default CPU model if none is specified should ideally
not be one which only works with one accelerator (among other
things, that makes it more complicated to implement and to probe for
because you need to ensure it's set after the accelerator is
selected and that if you're probing that you've told QEMU what
the accelerator type is).

> BTW, I was told aarch64 is a bit different and QEMU fails to start with
> KVM unless -cpu host is explicitly specified. Is that correct?

Either -cpu host or -cpu max will work. If your host is a real
Cortex-A57 then I think -cpu cortex-a57 will work; similarly
with -cpu cortex-a53 on a host A53. (The underlying constraint
here is that the kernel doesn't support "claim to the guest
that it is running on some different CPU than the host CPU",
so you can't use command line options or defaults that would
require that.) 32-bit arm is similar. The other point to note
is that the "virt" board's default CPU is Cortex-A15 for
historical reasons, which means that in practice if you want
to use 64-bit KVM you don't want the default value.

thanks
-- PMM

Re: Default CPU models on s390x and ppc64

[Christian Borntraeger]

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?

I would prefer it libvirt would use the equivalent of mode=host-model by
default. Is this what this series is all about?