qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 715ff2: hw/s390x/css: Remove double initializ


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 715ff2: hw/s390x/css: Remove double initialization
Date: Fri, 02 Oct 2020 08:30:38 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 715ff23ef2c49685da416f0233cd38d72bf4045e
      
https://github.com/qemu/qemu/commit/715ff23ef2c49685da416f0233cd38d72bf4045e
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/css.c

  Log Message:
  -----------
  hw/s390x/css: Remove double initialization

Fix eventual copy/paste mistake introduced in commit bc994b74ea
("s390x/css: Use static initialization for channel_subsys fields").

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200907024020.854465-1-philmd@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 912d70d2755cb9b3144eeed4014580ebc5485ce6
      
https://github.com/qemu/qemu/commit/912d70d2755cb9b3144eeed4014580ebc5485ce6
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390/sclp: get machine once during read scp/cpu info

Functions within read scp/cpu info will need access to the machine
state. Let's make a call to retrieve the machine state once and
pass the appropriate data to the respective functions.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-2-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: db13387ca01a69d870cc16dd232375c2603596f2
      
https://github.com/qemu/qemu/commit/db13387ca01a69d870cc16dd232375c2603596f2
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390/sclp: rework sclp boundary checks

Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowing different boundary sizes.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-3-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: c1db53a5910f988eeb32f031c53a50f3373fd824
      
https://github.com/qemu/qemu/commit/c1db53a5910f988eeb32f031c53a50f3373fd824
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/event-facility.c
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h

  Log Message:
  -----------
  s390/sclp: read sccb from mem based on provided length

The header contained within the SCCB passed to the SCLP service call
contains the actual length of the SCCB. Instead of allocating a static
4K size for the work sccb, let's allow for a variable size determined
by the value in the header. The proper checks are already in place to
ensure the SCCB length is sufficent to store a full response and that
the length does not cross any explicitly-set boundaries.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-4-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 0260b97824495ebfacfa8bbae0be10b0ef986bf6
      
https://github.com/qemu/qemu/commit/0260b97824495ebfacfa8bbae0be10b0ef986bf6
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390/sclp: check sccb len before filling in data

The SCCB must be checked for a sufficient length before it is filled
with any data. If the length is insufficient, then the SCLP command
is suppressed and the proper response code is set in the SCCB header.

While we're at it, let's cleanup the length check by placing the
calculation inside a macro.

Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-5-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 1a7a568859473b1cda39a015493c5c82bb200281
      
https://github.com/qemu/qemu/commit/1a7a568859473b1cda39a015493c5c82bb200281
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c

  Log Message:
  -----------
  s390/sclp: use cpu offset to locate cpu entries

The start of the CPU entry region in the Read SCP Info response data is
denoted by the offset_cpu field. As such, QEMU needs to begin creating
entries at this address.

This is in preparation for when Read SCP Info inevitably introduces new
bytes that push the start of the CPUEntry field further away.

Read CPU Info is unlikely to ever change, so let's not bother
accounting for the offset there.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-6-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 1ecd6078f587cfadda8edc93d45b5072e35f2d17
      
https://github.com/qemu/qemu/commit/1ecd6078f587cfadda8edc93d45b5072e35f2d17
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h
    M target/s390x/cpu_features_def.h.inc
    M target/s390x/gen-features.c
    M target/s390x/kvm.c

  Log Message:
  -----------
  s390/sclp: add extended-length sccb support for kvm guest

As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.

With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.

The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.

This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.

When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.

In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.

Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: fabdada9357b9cfd980c7744ddce47e34600bbef
      
https://github.com/qemu/qemu/commit/fabdada9357b9cfd980c7744ddce47e34600bbef
  Author: Collin Walling <walling@linux.ibm.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/sclp.c
    M include/hw/s390x/sclp.h
    M target/s390x/cpu.h
    M target/s390x/cpu_features.h
    M target/s390x/cpu_features_def.h.inc
    M target/s390x/cpu_models.c
    M target/s390x/gen-features.c
    M target/s390x/kvm.c
    M target/s390x/machine.c

  Log Message:
  -----------
  s390: guest support for diagnose 0x318

DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
of diagnostic information that is collected by the firmware in the case
of hardware/firmware service events.

QEMU handles the instruction by storing the info in the CPU state. A
subsequent register sync will communicate the data to the hypervisor.

QEMU handles the migration via a VM State Description.

This feature depends on the Extended-Length SCCB (els) feature. If
els is not present, then a warning will be printed and the SCLP bit
that allows the Linux kernel to execute the instruction will not be
set.

Availability of this instruction is determined by byte 134 (aka fac134)
bit 0 of the SCLP Read Info block. This coincidentally expands into the
space used for CPU entries, which means VMs running with the diag318
capability may not be able to read information regarding all CPUs
unless the guest kernel supports an extended-length SCCB.

This feature is not supported in protected virtualization mode.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-9-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 20d143e2cab8b597bbdb7a15f123d9704fa8db18
      
https://github.com/qemu/qemu/commit/20d143e2cab8b597bbdb7a15f123d9704fa8db18
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/excp_helper.c
    M target/s390x/helper.h
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement MONITOR CALL

Recent upstream Linux uses the MONITOR CALL instruction for things like
BUG_ON() and WARN_ON(). We currently inject an operation exception when
we hit a MONITOR CALL instruction - which is wrong, as the instruction
is not glued to specific CPU features.

Doing a simple WARN_ON_ONCE() currently results in a panic:
  [   18.162801] illegal operation: 0001 ilc:2 [#1] SMP
  [   18.162889] Modules linked in:
  [...]
  [   18.165476] Kernel panic - not syncing: Fatal exception: panic_on_oops

With a proper implementation, we now get:
  [   18.242754] ------------[ cut here ]------------
  [   18.242855] WARNING: CPU: 7 PID: 1 at init/main.c:1534 [...]
  [   18.242919] Modules linked in:
  [...]
  [   18.246262] ---[ end trace a420477d71dc97b4 ]---
  [   18.259014] Freeing unused kernel memory: 4220K

Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200918085122.26132-1-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: c8726f7b24be9384a148f3dc212036398193441c
      
https://github.com/qemu/qemu/commit/c8726f7b24be9384a148f3dc212036398193441c
  Author: Cornelia Huck <cohuck@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/vfio/ccw.c

  Log Message:
  -----------
  vfio-ccw: plug memory leak while getting region info

vfio_get_dev_region_info() unconditionally allocates memory
for a passed-in vfio_region_info structure (and does not re-use
an already allocated structure). Therefore, we have to free
the structure we pass to that function in vfio_ccw_get_region()
for every region we successfully obtained information for.

Fixes: 8fadea24de4e ("vfio-ccw: support async command subregion")
Fixes: 46ea3841edaf ("vfio-ccw: Add support for the schib region")
Fixes: f030532f2ad6 ("vfio-ccw: Add support for the CRW region and IRQ")
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200928101701.13540-1-cohuck@redhat.com>


  Commit: 98998cda5da8adcdab2eacac5a8531f24226a542
      
https://github.com/qemu/qemu/commit/98998cda5da8adcdab2eacac5a8531f24226a542
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

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

  Log Message:
  -----------
  s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> 
S390_FEAT_MISC_INSTRUCTION_EXT2

Let's avoid confusion with the "Miscellaneous-Instruction-Extensions
Facility 1"

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20200928122717.30586-2-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 87d7d93170fdc5749dd631c95e65c449fc30c3a9
      
https://github.com/qemu/qemu/commit/87d7d93170fdc5749dd631c95e65c449fc30c3a9
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement ADD HALFWORD (AGH)

Easy, just like ADD HALFWORD IMMEDIATE (AGHI).

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-3-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 3c3ea1afaec12600b76559a5fb4c1d2f59c35b61
      
https://github.com/qemu/qemu/commit/3c3ea1afaec12600b76559a5fb4c1d2f59c35b61
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/insn-data.def

  Log Message:
  -----------
  s390x/tcg: Implement SUBTRACT HALFWORD (SGH)

Easy to wire up.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-4-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: fa5e82ccb4ffb9bd6c0fa98636679dad07e9a91f
      
https://github.com/qemu/qemu/commit/fa5e82ccb4ffb9bd6c0fa98636679dad07e9a91f
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement MULTIPLY (MG, MGRK)

Multiply two signed 64bit values and store the 128bit result in r1 (0-63)
and r1 + 1 (64-127).

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-5-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 6645e4542fa2fcbd43f0df8c3a185e25edb366aa
      
https://github.com/qemu/qemu/commit/6645e4542fa2fcbd43f0df8c3a185e25edb366aa
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/insn-data.def

  Log Message:
  -----------
  s390x/tcg: Implement MULTIPLY HALFWORD (MGH)

Just like MULTIPLY HALFWORD IMMEDIATE (MGHI), only the second operand
(signed 16 bit) comes from memory.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-6-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: 9131bd01eceb2458abf89796d52c0eb8c5d5dace
      
https://github.com/qemu/qemu/commit/9131bd01eceb2458abf89796d52c0eb8c5d5dace
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)

Just like BRANCH ON CONDITION - however the address is read from memory
(always 8 bytes are read), we have to wrap the address manually. The
address is read using current CPU DAT/address-space controls, just like
ordinary data.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-7-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: b1feeb8760a1801a4681d3d198bc931f0ffddce9
      
https://github.com/qemu/qemu/commit/b1feeb8760a1801a4681d3d198bc931f0ffddce9
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/cc_helper.c
    M target/s390x/helper.c
    M target/s390x/insn-data.def
    M target/s390x/internal.h
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)

We need new CC handling, determining the CC based on the intermediate
result (64bit for MSC and MSRKC, 128bit for MSGC and MSGRKC).

We want to store out2 ("low") after muls128 to r1, so add
"wout_out2_r1".

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-8-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: e0f28bb210e4d07fba739ff6433f0d72835d88a5
      
https://github.com/qemu/qemu/commit/e0f28bb210e4d07fba739ff6433f0d72835d88a5
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

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

  Log Message:
  -----------
  s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2

We implement all relevant instructions.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-9-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: be2b567018d987591647935a7c9648e9c45e05e8
      
https://github.com/qemu/qemu/commit/be2b567018d987591647935a7c9648e9c45e05e8
  Author: David Hildenbrand <david@redhat.com>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M target/s390x/gen-features.c
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)

As with the other crypto functions, we only implement subcode 0 (query)
and no actual encryption/decryption. We now implement S390_FEAT_MSA_EXT_8.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-10-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>


  Commit: dd8c1e808f1ca311e1f50bff218c3ee3198b1f02
      
https://github.com/qemu/qemu/commit/dd8c1e808f1ca311e1f50bff218c3ee3198b1f02
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-10-02 (Fri, 02 Oct 2020)

  Changed paths:
    M hw/s390x/css.c
    M hw/s390x/event-facility.c
    M hw/s390x/sclp.c
    M hw/vfio/ccw.c
    M include/hw/s390x/sclp.h
    M target/s390x/cc_helper.c
    M target/s390x/cpu.h
    M target/s390x/cpu_features.h
    M target/s390x/cpu_features_def.h.inc
    M target/s390x/cpu_models.c
    M target/s390x/excp_helper.c
    M target/s390x/gen-features.c
    M target/s390x/helper.c
    M target/s390x/helper.h
    M target/s390x/insn-data.def
    M target/s390x/internal.h
    M target/s390x/kvm.c
    M target/s390x/machine.c
    M target/s390x/translate.c

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

s390x update
- support extended sccb and diagnose 0x318
- implement additional instructions in tcg
- bug fixes

# gpg: Signature made Fri 02 Oct 2020 13:05:16 BST
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown]
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>" [unknown]
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20201002:
  s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)
  s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2
  s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)
  s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)
  s390x/tcg: Implement MULTIPLY HALFWORD (MGH)
  s390x/tcg: Implement MULTIPLY (MG, MGRK)
  s390x/tcg: Implement SUBTRACT HALFWORD (SGH)
  s390x/tcg: Implement ADD HALFWORD (AGH)
  s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> 
S390_FEAT_MISC_INSTRUCTION_EXT2
  vfio-ccw: plug memory leak while getting region info
  s390x/tcg: Implement MONITOR CALL
  s390: guest support for diagnose 0x318
  s390/sclp: add extended-length sccb support for kvm guest
  s390/sclp: use cpu offset to locate cpu entries
  s390/sclp: check sccb len before filling in data
  s390/sclp: read sccb from mem based on provided length
  s390/sclp: rework sclp boundary checks
  s390/sclp: get machine once during read scp/cpu info
  hw/s390x/css: Remove double initialization

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/0d2a4545bf7e...dd8c1e808f1c



reply via email to

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