[libvirt PATCH 0/3] qemu: Fix default CPU for old s390 machine types

Christian Ehrhardt christian.ehrhardt at canonical.com
Fri Feb 7 12:34:13 UTC 2020


On Fri, Feb 7, 2020 at 9:35 AM Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

>
>
> On Thu, Feb 6, 2020 at 11:25 AM Jiri Denemark <jdenemar at redhat.com> wrote:
>
>> See the last patch for detailed description and
>> https://bugzilla.redhat.com/show_bug.cgi?id=1795651 for a discussion
>> about this topic.
>>
>> Jiri Denemark (3):
>>   qemu: Pass machine type to virQEMUCapsIsCPUModeSupported
>>   qemuxml2*test: Add default CPU tests for s390-ccw-virtio-2.7 machines
>>   qemu_capabilities: Disable CPU models on old s390 machine types
>>
>
> Reviewed-by: Christian Ehrhardt <christian.ehrhardt at canonical.com>
>
> I have also set up a build with the changes adding some Ubuntu machine
> types on top.
> I eventually also want to give you a Tested-by, but those tests not be
> completed this week - I beg your pardon for the delay.
>

>
Tests:
- start old common type s390-ccw-virtio-2.5
- start old ubunut type s390-ccw-virtio-xenial
- migrate from old installation that was pre 2.8

Comparing:
a) libvirt 6.0 (6.0.0-0ubuntu2)
b) libvirt 6.0 + this series (6.0.0-0ubuntu3~test1)

a) failed in all cases with the expected
   qemu-system-s390x: CPU models are not available: KVM doesn't support CPU
models
b) all three cases worked fine now

Special case:
If I tried to start the formerly defined "breakme" domains they got added
  <cpu mode='host-model' check='partial'/>
Therefore they now fail with:
  error: Failed to start domain breakme
  error: unsupported configuration: CPU mode 'host-model' for s390x kvm
domain on s390x host is not supported by hypervisor

If I undefine, and define again fromt the template as reported in the BZ
  <domain type='kvm'>
    <name>breakme</name>
    <memory unit='KiB'>524288</memory>
    <os>
      <type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
    </os>
  </domain>
I now get after define:
  <cpu mode='host-passthrough' check='none'/>
So it detected things correctly detecting the old type.

A cross check using a new type like s390-ccw-virtio-4.0 or
s390-ccw-virtio-eoan worked fine and gave me the epxected
  <cpu mode='host-model' check='partial'/>

Tested-by:  Christian Ehrhardt <christian.ehrhardt at canonical.com>

 src/qemu/qemu_capabilities.c                  | 29 ++++++++++++++---
>>  src/qemu/qemu_capabilities.h                  |  3 +-
>>  src/qemu/qemu_domain.c                        |  3 +-
>>  src/qemu/qemu_process.c                       |  2 +-
>>  ...t-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 32 +++++++++++++++++++
>>  .../s390-default-cpu-kvm-ccw-virtio-2.7.xml   | 16 ++++++++++
>>  ...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 32 +++++++++++++++++++
>>  .../s390-default-cpu-tcg-ccw-virtio-2.7.xml   | 16 ++++++++++
>>  tests/qemuxml2argvtest.c                      |  2 ++
>>  ...lt-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml | 24 ++++++++++++++
>>  ...lt-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml | 26 +++++++++++++++
>>  tests/qemuxml2xmltest.c                       |  2 ++
>>  12 files changed, 180 insertions(+), 7 deletions(-)
>>  create mode 100644
>> tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.args
>>  create mode 100644
>> tests/qemuxml2argvdata/s390-default-cpu-kvm-ccw-virtio-2.7.xml
>>  create mode 100644
>> tests/qemuxml2argvdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.args
>>  create mode 100644
>> tests/qemuxml2argvdata/s390-default-cpu-tcg-ccw-virtio-2.7.xml
>>  create mode 100644
>> tests/qemuxml2xmloutdata/s390-default-cpu-kvm-ccw-virtio-2.7.s390x-latest.xml
>>  create mode 100644
>> tests/qemuxml2xmloutdata/s390-default-cpu-tcg-ccw-virtio-2.7.s390x-latest.xml
>>
>> --
>> 2.25.0
>>
>>
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd
>


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200207/52718861/attachment-0001.htm>


More information about the libvir-list mailing list