[Qemu-commits] [qemu/qemu] 618239: s390x: add compat machine for 2.8

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 61823988df67eba82d59bd9d2cfd643aeac92826
      
https://github.com/qemu/qemu/commit/61823988df67eba82d59bd9d2cfd643aeac92826
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c
    M include/hw/compat.h

  Log Message:
  -----------
  s390x: add compat machine for 2.8

Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 0d36d791927753599e9ca36e344f9fb272126e3d
      
https://github.com/qemu/qemu/commit/0d36d791927753599e9ca36e344f9fb272126e3d
  Author: Yi Min Zhao <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: return directly if create zpci failed

In the case that zpci is automatically created, we did not return
immediately on failure, which would lead to NULL pointer dereferencing.
Let's fix it.

Signed-off-by: Yi Min Zhao <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 0c2a16a4dc56fbdbe7f619e2a860214dc6f89ec6
      
https://github.com/qemu/qemu/commit/0c2a16a4dc56fbdbe7f619e2a860214dc6f89ec6
  Author: Yi Min Zhao <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: assert zpci always existing

If one pci device is plugged successfully, there must be a zpci device
existing. This means that during hot-unplugging a pci device, its
corresponding zpci device must be found. Therefore we use an assert to
replace current code.

Signed-off-by: Yi Min Zhao <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 989fd865f5e306a0b1ff10713a678b1fc4cab08f
      
https://github.com/qemu/qemu/commit/989fd865f5e306a0b1ff10713a678b1fc4cab08f
  Author: Christian Borntraeger <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390/sclp: cache the sclp device

With the current code a simple sclp command takes about 13000 ns
The biggest part seems to be the resolver of the object model. By
caching the sclp device the time for an sclp command goes down to
2500ns. Talking about real life scenarios, this change doubles
the speed of the sclp console when sending single bytes outputs
to /dev/console.

Signed-off-by: Christian Borntraeger <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: f2cab7f1480b20adf32e13aa79be1fe225ba7790
      
https://github.com/qemu/qemu/commit/f2cab7f1480b20adf32e13aa79be1fe225ba7790
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/intc/s390_flic_kvm.c

  Log Message:
  -----------
  s390x: wrap flic savevm calls into vmstate

Just a simple conversion to get rid of register_savevm.

Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 5759db1936b52a7f5d0cd4e1377ed74054d555f9
      
https://github.com/qemu/qemu/commit/5759db1936b52a7f5d0cd4e1377ed74054d555f9
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M target-s390x/ioinst.c

  Log Message:
  -----------
  s390x/ioinst: advertise fcs facility

As we provide format 1 chsc scpd data (and don't support any ficon
channels), we de facto already have the ficon-cascaded-switch
facility.

Reviewed-by: Pierre Morel <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 882b3b97697affb36ca3d174f42f846232008979
      
https://github.com/qemu/qemu/commit/882b3b97697affb36ca3d174f42f846232008979
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M hw/s390x/css.c
    M include/hw/s390x/css.h

  Log Message:
  -----------
  s390x/css: handle cssid 255 correctly

The cssid 255 is reserved but still valid from an architectural
point of view. However, feeding a bogus schid of 0xffffffff into
the virtio hypercall will lead to a crash:

Stack trace of thread 138363:
  #0  0x00000000100d168c css_find_subch (qemu-system-s390x)
  #1  0x00000000100d3290 virtio_ccw_hcall_notify
  #2  0x00000000100cbf60 s390_virtio_hypercall
  #3  0x000000001010ff7a handle_hypercall
  #4  0x0000000010079ed4 kvm_cpu_exec (qemu-system-s390x)
  #5  0x00000000100609b4 qemu_kvm_cpu_thread_fn
  #6  0x000003ff8b887bb4 start_thread (libpthread.so.0)
  #7  0x000003ff8b78df0a thread_start (libc.so.6)

This is because the css array was only allocated for 0..254
instead of 0..255.

Let's fix this by bumping MAX_CSSID to 255 and fencing off the
reserved cssid of 255 during css image allocation.

Reported-by: Christian Borntraeger <address@hidden>
Tested-by: Christian Borntraeger <address@hidden>
Cc: address@hidden
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: dbdfea9226c9d0bdd149272514f47862e03f4ebe
      
https://github.com/qemu/qemu/commit/dbdfea9226c9d0bdd149272514f47862e03f4ebe
  Author: Cornelia Huck <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M include/standard-headers/linux/input-event-codes.h
    M include/standard-headers/linux/input.h
    M include/standard-headers/linux/virtio_config.h
    M include/standard-headers/linux/virtio_ids.h
    M include/standard-headers/linux/virtio_net.h
    A include/standard-headers/linux/virtio_vsock.h
    M linux-headers/asm-arm/kvm.h
    M linux-headers/asm-arm64/kvm.h
    M linux-headers/asm-s390/kvm.h
    M linux-headers/asm-x86/unistd_x32.h
    M linux-headers/linux/kvm.h
    M linux-headers/linux/vhost.h

  Log Message:
  -----------
  linux-headers: update

Update headers against 4.8-rc2.

Signed-off-by: Cornelia Huck <address@hidden>


  Commit: b60fae32ff33cbaab76d14cc5f55b979cf58516d
      
https://github.com/qemu/qemu/commit/b60fae32ff33cbaab76d14cc5f55b979cf58516d
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M target-s390x/cpu.h
    M target-s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: 2 byte software breakpoint support

Diag 501 (4 bytes) was used until now for software breakpoints on s390.
As instructions on s390 might be 2 bytes long, temporarily overwriting them
with 4 bytes is evil and can result in very strange guest behaviour.

We make use of invalid instruction 0x0000 as new sw breakpoint instruction.
We have to enable interception of that instruction in KVM using a
capability.

If no software breakpoint has been inserted at the reported position, an
operation exception has to be injected into the guest. Otherwise a
breakpoint has been hit and the pc has to be rewound.

If KVM doesn't yet support interception of instruction 0x0000 the
existing mechanism exploiting diag 501 is used. To keep overhead low,
interception of instruction 0x0000 will only be enabled if sw breakpoints
are really used.

Reviewed-by: Christian Borntraeger <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: fc4b84b1c68a0dc2905d379f0f6a5305e4ebe0b3
      
https://github.com/qemu/qemu/commit/fc4b84b1c68a0dc2905d379f0f6a5305e4ebe0b3
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-05 (Mon, 05 Sep 2016)

  Changed paths:
    M qapi-schema.json

  Log Message:
  -----------
  qmp: details about CPU definitions in query-cpu-definitions

It might be of interest for tooling whether a CPU definition can be safely
used when migrating, or if e.g. CPU features might get lost during
migration when migrationg from/to a different QEMU version or host, even if
the same compatibility machine is used.

Also, we want to know if a CPU definition is static and will never change.
Beause these definitions can then be used independantly of a compatibility
machine and will always have the same feature set, they can e.g. be used
to indicate the "host" model in libvirt later on.

Let's add two return values to query-cpu-definitions, stating for each
returned CPU definition, if it is migration-safe and if it is static.

While "migration-safe" is optional, "static" will be set to "false"
automatically by all implementing architectures. If a model really was
static all the time and will be in the future, this can simply be changed
later.

Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 41868f846d2ca5865c1706dc6529964bfa3dac6c
      
https://github.com/qemu/qemu/commit/41868f846d2ca5865c1706dc6529964bfa3dac6c
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/s390-virtio.c
    M target-s390x/Makefile.objs
    M target-s390x/cpu-qom.h
    M target-s390x/cpu.c
    M target-s390x/cpu.h
    A target-s390x/cpu_models.c
    M target-s390x/helper.c

  Log Message:
  -----------
  s390x/cpumodel: "host" and "qemu" as CPU subclasses

This patch introduces two CPU models, "host" and "qemu".
"qemu" is used as default when running under TCG. "host" is used
as default when running under KVM. "host" cannot be used without KVM.
"host" is not migration-safe. They both inherit from the base s390x CPU,
which is turned into an abstract class.

This patch also changes CPU creation to take care of the passed CPU string
and reuses common code parse_features() function for that purpose. Unknown
CPU definitions are now reported. The "-cpu ?" and "query-cpu-definition"
commands are changed to list all CPU subclasses automatically, including
migration-safety and whether static.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
[CH: fix up self-assignments in s390_cpu_list, as spotted by clang]
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 6efadc905038ac21e7a5e67392c88368932ec5a9
      
https://github.com/qemu/qemu/commit/6efadc905038ac21e7a5e67392c88368932ec5a9
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu.c
    M target-s390x/cpu.h
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: expose CPU class properties

Let's expose the description and migration safety and whether a definition
is static, as class properties, this can be helpful in the future.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 782417446279717aa85320191a519b51f6d5dd31
      
https://github.com/qemu/qemu/commit/782417446279717aa85320191a519b51f6d5dd31
  Author: Michael Mueller <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/Makefile.objs
    A target-s390x/cpu_features.c
    A target-s390x/cpu_features.h
    A target-s390x/cpu_features_def.h

  Log Message:
  -----------
  s390x/cpumodel: introduce CPU features

The patch introduces s390x CPU features (most of them refered to as
facilities) along with their discription and some functions that will be
helpful when working with the features later on.

Please note that we don't introduce all known CPU features, only the
ones currently supported by KVM + QEMU. We don't want to enable later
on blindly any facilities, for which we don't know yet if we need QEMU
support to properly support them (e.g. migrate additional state when
active). We can update QEMU later on.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: Michael Mueller <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
[reworked to include non-stfle features, added definitions]
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: dced7eec3c60154408296dda8641ecc54978f5d6
      
https://github.com/qemu/qemu/commit/dced7eec3c60154408296dda8641ecc54978f5d6
  Author: Michael Mueller <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M Makefile.target
    M rules.mak
    M target-s390x/Makefile.objs
    A target-s390x/gen-features.c

  Log Message:
  -----------
  s390x/cpumodel: generate CPU feature lists for CPU models

This patch introduces the helper "gen-features" which allows to generate
feature list definitions at compile time. Its flexibility is better and the
error-proneness is lower when compared to static programming time added
statements.

The helper includes "target-s390x/cpu_features.h" to be able to use named
facility bits instead of numbers. The generated defines will be used for
the definition of CPU models.

We generate feature lists for each HW generation and GA for EC models. BC
models are always based on a EC version and have no separate definitions.

Base features: Features we expect to be always available in sane setups.
Migration safe - will never change. Can be seen as "minimum features
required for a CPU model".

Default features: Features we expect to be stable and around in latest
setups (e.g. having KVM support) - not migration safe.

Max features: All supported features that are theoretically allowed for a
CPU model. Exceeding these features could otherwise produce problems with
IBC (instruction blocking controls) in KVM.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: Michael Mueller <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
[generate base, default and models. renaming and cleanup]
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 90229ebbad508ba604f215e90c7c5cc0fbc3559a
      
https://github.com/qemu/qemu/commit/90229ebbad508ba604f215e90c7c5cc0fbc3559a
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/gen-features.c

  Log Message:
  -----------
  s390x/cpumodel: generate CPU feature group lists

Feature groups will be very helpful to reduce the amount of features
typically available in sane configurations. E.g. the MSA facilities
introduced loads of subfunctions, which could - in theory - go away
in the future, but we want to avoid reporting hundrets of features to
the user if usually all of them are in place.

Groups only contain features that were introduced in one shot, not just
random features. Therefore, groups can never change. This is an important
property regarding migration.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 8b3d6cb1fa6ae12e80ed8c266a637468b52835c7
      
https://github.com/qemu/qemu/commit/8b3d6cb1fa6ae12e80ed8c266a637468b52835c7
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu_features.c
    M target-s390x/cpu_features.h

  Log Message:
  -----------
  s390x/cpumodel: introduce CPU feature group definitions

Let's use the generated groups to create feature group representations for
the user. These groups can later be used to enable/disable multiple
features in one shot and will be used to reduce the amount of reported
features to the user if all subfeatures are in place.

We want to work on features using ordinary bitmap operations, however we
can't initialize a bitmap statically (unsigned long[] ...). Therefore
we store the generated feature lists in separate arrays and convert
them to a proper bitmaps before they will ever be used.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 6c064de1e08f425e2852ea9b38ea0723994aa4fd
      
https://github.com/qemu/qemu/commit/6c064de1e08f425e2852ea9b38ea0723994aa4fd
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu-qom.h
    M target-s390x/cpu_models.c
    A target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/cpumodel: register defined CPU models as subclasses

This patch adds the CPU model definitions that are known on s390x -
like z900, zBC12 or z13. For each definition, introduce two CPU models:

1. Base model (e.g. z13-base): Minimum feature set we expect to be around
   on all z13 systems. These models are migration-safe and will never
   change.
2. Flexible models (e.g. z13): Models that can change between QEMU versions
   and will be extended over time as we implement further features that
   are already part of such a model in real hardware of certain
   configurations.

We want to work on features using ordinary bitmap operations, however we
can't initialize a bitmap statically (unsigned long[] ...). Therefore we
store the generated feature lists in separate arrays and convert them to
proper bitmaps before registering all our CPU model classes.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: ad5afd07b628cd0610ea322ad60b5ad03aa250c8
      
https://github.com/qemu/qemu/commit/ad5afd07b628cd0610ea322ad60b5ad03aa250c8
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu.h
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/cpumodel: store the CPU model in the CPU instance

A CPU model consists of a CPU definition, to which delta changes are
applied - features added or removed (e.g. z13-base,vx=on). In addition,
certain properties (e.g. cpu id) can later on change during migration
but belong into the CPU model. This data will later be filled from the
host model in the KVM case.

Therefore, store the configured CPU model inside the CPU instance, so
we can later on perform delta changes using properties.

For the "qemu" model, we emulate in TCG a z900. "host" will be
uninitialized (cpu->model == NULL) unless we have CPU model support in KVM
later on. The other models are all initialized from their definitions.
Only the "host" model can have a cpu->model == NULL.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 0754f6042995c77ef8843d34df873461353febcd
      
https://github.com/qemu/qemu/commit/0754f6042995c77ef8843d34df873461353febcd
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu.c
    M target-s390x/cpu.h
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: expose features and feature groups as properties

Let's add all features and feature groups as properties to all CPU models.
If the "host" CPU model is unknown, we can neither query nor change
features. KVM will just continue to work like it did until now.

We will not allow to enable features that were not part of the original
CPU model, because that could collide with the IBC in KVM.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 7c72ac49ae9f38fa0125296e05988655157decb5
      
https://github.com/qemu/qemu/commit/7c72ac49ae9f38fa0125296e05988655157decb5
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h
    M target-s390x/kvm.c
    M target-s390x/machine.c

  Log Message:
  -----------
  s390x/cpumodel: let the CPU model handle feature checks

If we have certain features enabled, we have to migrate additional state
(e.g. vector registers or runtime-instrumentation registers). Let the
CPU model control that unless we have no "host" CPU model in the KVM
case. This will later on be the case for compatibility machines, so
migration from QEMU versions without the CPU model will still work.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 80560137cfbb88ba40eb3b933741c63bd43b5fe3
      
https://github.com/qemu/qemu/commit/80560137cfbb88ba40eb3b933741c63bd43b5fe3
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: check and apply the CPU model

We have to test if a configured CPU model is runnable in the current
configuration, and if not report why that is the case. This is done by
comparing it to the maximum supported model (host for KVM or z900 for TCG).
Also, we want to do some base sanity checking for a configured CPU model.

We'll cache the maximum model and the applied model (for performance
reasons and because KVM can only be configured before any VCPU is created).

For unavailable "host" model, we have to make sure that we inform KVM,
so it can do some compatibility stuff (enable CMMA later on to be precise).

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 026546e6c362278db7c14d4cd5165fa5214c18fa
      
https://github.com/qemu/qemu/commit/026546e6c362278db7c14d4cd5165fa5214c18fa
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390x/sclp: factor out preparation of cpu entries

Let's factor out the common code of "read cpu info" and "read scp
info". This will make the introduction of new cpu entry fields easier.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 1c07e01b61daeba0204ee14dd0e21ea0218d0578
      
https://github.com/qemu/qemu/commit/1c07e01b61daeba0204ee14dd0e21ea0218d0578
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M include/hw/s390x/sclp.h

  Log Message:
  -----------
  s390x/sclp: introduce sclp feature blocks

The sclp "read cpu info" and "read scp info" commands can include
features for the cpu info and configuration characteristics (extended),
decribing some advanced features available in the configuration.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 4dd4200ee7b4bc4b383932720bc53accf85cc8b2
      
https://github.com/qemu/qemu/commit/4dd4200ee7b4bc4b383932720bc53accf85cc8b2
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/sclp: indicate sclp features

We have three different blocks in the SCLP read-SCP information response
that indicate sclp features. Let's prepare propagation.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 059be520d519565636f73496c20b2b8d331fa865
      
https://github.com/qemu/qemu/commit/059be520d519565636f73496c20b2b8d331fa865
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/sclp: propagate the ibc val (lowest and unblocked ibc)

If we have a lowest ibc, we can indicate the ibc to the guest.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 3fad3252a362515a44003434cab3766b6b57c985
      
https://github.com/qemu/qemu/commit/3fad3252a362515a44003434cab3766b6b57c985
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/sclp: propagate the mha via sclp

The mha is provided in the CPU model, so get any CPU and extract the value.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: a366930780a75027bf44fa8b1efa03372f71e17d
      
https://github.com/qemu/qemu/commit/a366930780a75027bf44fa8b1efa03372f71e17d
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h

  Log Message:
  -----------
  s390x/sclp: propagate hmfai

hmfai is provided on CPU models >= z196. Let's propagate it properly.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 392529cb7747a4226e724c5a59858334f76021e2
      
https://github.com/qemu/qemu/commit/392529cb7747a4226e724c5a59858334f76021e2
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c

  Log Message:
  -----------
  s390x/kvm: allow runtime-instrumentation for "none" machine

To be able to query the correct host model for the "none" machine,
let's allow runtime-instrumentation for that machine.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 3b84c25cc7e4106a588737b2031863994bb86f03
      
https://github.com/qemu/qemu/commit/3b84c25cc7e4106a588737b2031863994bb86f03
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu_models.c
    M target-s390x/cpu_models.h
    M target-s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: implement CPU model support

Let's implement our two hooks so we can support CPU models.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 34821036cd10e8ae9061338bcb6c8777781d07e9
      
https://github.com/qemu/qemu/commit/34821036cd10e8ae9061338bcb6c8777781d07e9
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: disable host model for problematic compat machines

Compatibility machines that touch runtime-instrumentation should not
be used with the CPU model. Otherwise the host model will look different,
depending on the QEMU machine QEMU has been started with.

So let's simply disable the host model for existing compatibility machines
that all disable ri. This, in return, disables the CPU model for these
compat machines completely.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 07059effd14e1cb6497f711e905c55affa525677
      
https://github.com/qemu/qemu/commit/07059effd14e1cb6497f711e905c55affa525677
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/gen-features.c
    M target-s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: let the CPU model control CMM(A)

Starting with recent kernels, if the cmma attributes are available, we
actually have hardware support. Enabling CMMA then means providing the
guest VCPU with CMM, therefore enabling its CMM facility.

Let's not blindly enable CMM anymore but let's control it using CPU models.
For disabled CPU models, CMMA will continue to always get enabled.

Also enable it in the applicable default models.

Please note that CMM doesn't work with hugetlbfs, therefore we will
warn the user and keep it disabled. Migrating from/to a hugetlbfs
configuration works, as it will be disabled on both sides.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: c85d21c73b06064ae2ae7bd49cf36dfaaae2a0a8
      
https://github.com/qemu/qemu/commit/c85d21c73b06064ae2ae7bd49cf36dfaaae2a0a8
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M target-s390x/cpu_models.c
    M target-s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: don't enable key wrapping if msa3 is disabled

As the CPU model now controls msa3, trying to set wrapping keys without
msa3 being around/enable in the kernel will produce misleading errors.

So let's simply not configure key wrapping if msa3 is not enabled and
make compat machines with disabled CPU model work correctly.

Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: e09484efbc9db8c4554293cdc8aed7a8db378d97
      
https://github.com/qemu/qemu/commit/e09484efbc9db8c4554293cdc8aed7a8db378d97
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M include/sysemu/arch_init.h
    M qapi-schema.json
    M qmp-commands.hx
    M qmp.c
    M stubs/Makefile.objs
    A stubs/arch-query-cpu-model-expansion.c

  Log Message:
  -----------
  qmp: add QMP interface "query-cpu-model-expansion"

Let's provide a standardized interface to expand CPU models. This interface
can be used by tooling to get details about a specific CPU model in a
certain configuration, e.g. about the "host" model.

To take care of all architectures, two detail levels for an expansion
are introduced. Certain architectures might not support all detail levels.
While "full" will expand and indicate all relevant properties/features
of a CPU model, "static" expands to a static base CPU model, that will
never change between QEMU versions and therefore have the same features
when used under different compatibility machines.

Acked-by: Cornelia Huck <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 0031e0d68339e7a919cf927119807ed882da6e4f
      
https://github.com/qemu/qemu/commit/0031e0d68339e7a919cf927119807ed882da6e4f
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M include/sysemu/arch_init.h
    M qapi-schema.json
    M qmp-commands.hx
    M qmp.c
    M stubs/Makefile.objs
    A stubs/arch-query-cpu-model-comparison.c

  Log Message:
  -----------
  qmp: add QMP interface "query-cpu-model-comparison"

Let's provide a standardized interface to compare two CPU models.
"query-cpu-model-compare" takes two models and returns  how they compare
in a specific configuration.

The result will give guarantees about runnability. E.g. if a CPU model A
is a subset of CPU model B, model A is guaranteed to run in configurations
where model B runs, but not the other way around (might or might not run).

Usually, CPU features or CPU generations are used to calculate the result.
If a model is not guaranteed to run in a certain environment (e.g.
incompatible), a  compatible one can be created by "baselining" both models
(follow up patch).

Acked-by: Cornelia Huck <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: b18b6043341dfad46cbda7804424a1604cea065b
      
https://github.com/qemu/qemu/commit/b18b6043341dfad46cbda7804424a1604cea065b
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M include/sysemu/arch_init.h
    M qapi-schema.json
    M qmp-commands.hx
    M qmp.c
    M stubs/Makefile.objs
    A stubs/arch-query-cpu-model-baseline.c

  Log Message:
  -----------
  qmp: add QMP interface "query-cpu-model-baseline"

Let's provide a standardized interface to baseline two CPU models, to
create a third, compatible one. This is especially helpful when two
CPU models are not identical, but a CPU model is required that is
guaranteed to run under both configurations, where the original models run.

"query-cpu-model-baseline" takes two CPU models and returns a third,
compatible model. The result will always be a static CPU model.

Acked-by: Cornelia Huck <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 137974cea30120a80fc8e41c7a64afb0d4d6c2f6
      
https://github.com/qemu/qemu/commit/137974cea30120a80fc8e41c7a64afb0d4d6c2f6
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M qapi-schema.json
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"

In order to expand CPU models, we create temporary cpus that handle the
feature/group parsing. Only CPU feature properties are expanded.

When converting the data structure back, we always fall back to the
static base CPU model, which is by definition migration-safe.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 4e82ef05029f27a39c6259bd967e4f46988d176c
      
https://github.com/qemu/qemu/commit/4e82ef05029f27a39c6259bd967e4f46988d176c
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M qapi-schema.json
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"

Let's implement that interface by reusing our convertion code implemented
for expansion.

We use CPU generations and CPU features to calculate the result. This
means, that a zEC12 cannot simply be converted into a z13 by stripping
of features. This is required, as other magic values (e.g. maximum
address sizes) belong to a CPU generation and cannot simply be
emulated by an older generation.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: f1a47d08effc4f2a33c667942e394c6f32a4f7d6
      
https://github.com/qemu/qemu/commit/f1a47d08effc4f2a33c667942e394c6f32a4f7d6
  Author: David Hildenbrand <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M qapi-schema.json
    M target-s390x/cpu_models.c

  Log Message:
  -----------
  s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"

Let's implement that interface by reusing our conversion code and
lookup code for CPU definitions.

In order to find a compatible CPU model, we first detect the maximum
possible CPU generation and then try to find a maximum model, satisfying
all base features (not exceeding the maximum generation).

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: f9ae6bcf1d4659867cfc5e6d90a5e7fdad02280b
      
https://github.com/qemu/qemu/commit/f9ae6bcf1d4659867cfc5e6d90a5e7fdad02280b
  Author: Peter Maydell <address@hidden>
  Date:   2016-09-06 (Tue, 06 Sep 2016)

  Changed paths:
    M Makefile.target
    M hw/intc/s390_flic_kvm.c
    M hw/s390x/css.c
    M hw/s390x/s390-pci-bus.c
    M hw/s390x/s390-virtio-ccw.c
    M hw/s390x/s390-virtio.c
    M hw/s390x/sclp.c
    M include/hw/compat.h
    M include/hw/s390x/css.h
    M include/hw/s390x/sclp.h
    M include/standard-headers/linux/input-event-codes.h
    M include/standard-headers/linux/input.h
    M include/standard-headers/linux/virtio_config.h
    M include/standard-headers/linux/virtio_ids.h
    M include/standard-headers/linux/virtio_net.h
    A include/standard-headers/linux/virtio_vsock.h
    M include/sysemu/arch_init.h
    M linux-headers/asm-arm/kvm.h
    M linux-headers/asm-arm64/kvm.h
    M linux-headers/asm-s390/kvm.h
    M linux-headers/asm-x86/unistd_x32.h
    M linux-headers/linux/kvm.h
    M linux-headers/linux/vhost.h
    M qapi-schema.json
    M qmp-commands.hx
    M qmp.c
    M rules.mak
    M stubs/Makefile.objs
    A stubs/arch-query-cpu-model-baseline.c
    A stubs/arch-query-cpu-model-comparison.c
    A stubs/arch-query-cpu-model-expansion.c
    M target-s390x/Makefile.objs
    M target-s390x/cpu-qom.h
    M target-s390x/cpu.c
    M target-s390x/cpu.h
    A target-s390x/cpu_features.c
    A target-s390x/cpu_features.h
    A target-s390x/cpu_features_def.h
    A target-s390x/cpu_models.c
    A target-s390x/cpu_models.h
    A target-s390x/gen-features.c
    M target-s390x/helper.c
    M target-s390x/ioinst.c
    M target-s390x/kvm.c
    M target-s390x/machine.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20160906-v2' into 
staging

First (big) chunk of s390x updates:
- cpumodel support for s390x
- various fixes and improvements

# gpg: Signature made Tue 06 Sep 2016 16:09:53 BST
# gpg:                using RSA key 0xDECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <address@hidden>"
# gpg:                 aka "Cornelia Huck <address@hidden>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20160906-v2: (38 commits)
  s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"
  s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"
  s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"
  qmp: add QMP interface "query-cpu-model-baseline"
  qmp: add QMP interface "query-cpu-model-comparison"
  qmp: add QMP interface "query-cpu-model-expansion"
  s390x/kvm: don't enable key wrapping if msa3 is disabled
  s390x/kvm: let the CPU model control CMM(A)
  s390x/kvm: disable host model for problematic compat machines
  s390x/kvm: implement CPU model support
  s390x/kvm: allow runtime-instrumentation for "none" machine
  s390x/sclp: propagate hmfai
  s390x/sclp: propagate the mha via sclp
  s390x/sclp: propagate the ibc val (lowest and unblocked ibc)
  s390x/sclp: indicate sclp features
  s390x/sclp: introduce sclp feature blocks
  s390x/sclp: factor out preparation of cpu entries
  s390x/cpumodel: check and apply the CPU model
  s390x/cpumodel: let the CPU model handle feature checks
  s390x/cpumodel: expose features and feature groups as properties
  ...

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/085c9150195b...f9ae6bcf1d46