qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 25bcb4: s390x/tcg: Fix VERIM with 32/64 bit e


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 25bcb4: s390x/tcg: Fix VERIM with 32/64 bit elements
Date: Fri, 23 Aug 2019 08:11:14 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 25bcb45d1b81d22634daa2b1a2d8bee746ac129b
      
https://github.com/qemu/qemu/commit/25bcb45d1b81d22634daa2b1a2d8bee746ac129b
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/translate_vx.inc.c

  Log Message:
  -----------
  s390x/tcg: Fix VERIM with 32/64 bit elements

Wrong order of operands. The constant always comes last. Makes QEMU crash
reliably on specific git fetch invocations.

Reported-by: Stefano Brivio <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Fixes: 5c4b0ab460ef ("s390x/tcg: Implement VECTOR ELEMENT ROTATE AND INSERT 
UNDER MASK")
Cc: address@hidden
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 24332523f15aca16d974a9e4a353a6e09043815d
      
https://github.com/qemu/qemu/commit/24332523f15aca16d974a9e4a353a6e09043815d
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/mmu_helper.c

  Log Message:
  -----------
  s390x/mmu: Trace the right value if setting/getting the storage key fails

We want to trace the actual return value, not "0".

Fixes: 0f5f669147b5 ("s390x: Enable new s390-storage-keys device")
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: c36709e45d5f636bcdf6bfb78f95e27260018ef5
      
https://github.com/qemu/qemu/commit/c36709e45d5f636bcdf6bfb78f95e27260018ef5
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/helper.c

  Log Message:
  -----------
  s390x/mmu: ASC selection in s390_cpu_get_phys_page_debug()

Let's select the ASC before calling the function. This is a prepararion
to remove the ASC magic depending on the access mode from mmu_translate.

There is currently no way to distinguish if we have code or data access.
For now, we were using code access, because especially when debugging with
the gdbstub, we want to read and disassemble what we single-step.

Note: KVM guest can now no longer be crashed using qmp/hmp/gdbstub if they
happen to be in AR mode.

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


  Commit: 3096ffd3684684a91a9190d3f93c0fc45dd2b856
      
https://github.com/qemu/qemu/commit/3096ffd3684684a91a9190d3f93c0fc45dd2b856
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/cpu.h
    M target/s390x/mmu_helper.c

  Log Message:
  -----------
  s390x/tcg: Rework MMU selection for instruction fetches

Instructions are always fetched from primary address space, except when
in home address mode. Perform the selection directly in cpu_mmu_index().

get_mem_index() is only used to perform data access, instructions are
fetched via cpu_lduw_code(), which translates to cpu_mmu_index(env, true).

We don't care about restricting the access permissions of the TLB
entries anymore, as we no longer enter PRIMARY entries into the
SECONDARY MMU. Cleanup related code a bit.

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


  Commit: 5b773a1107e7ca6f51e3447cc066f255a7fd8cca
      
https://github.com/qemu/qemu/commit/5b773a1107e7ca6f51e3447cc066f255a7fd8cca
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/mem_helper.c

  Log Message:
  -----------
  s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

Whenever we modify a storage key, we should flush the TLBs of all CPUs,
so the MMU fault handling code can properly consider the changed storage
key (to e.g., properly set the reference and change bit on the next
accesses).

These functions are barely used in modern Linux guests, so the performance
implications are neglectable for now.

This is a preparation for better reference and change bit handling for
TCG, which will require more MMU changes.

Reviewed-by: Cornelia Huck <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Acked-by: Alex Bennée <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 2d3bb388ad93dce9a9454af67f43d3aaaa5b9b1a
      
https://github.com/qemu/qemu/commit/2d3bb388ad93dce9a9454af67f43d3aaaa5b9b1a
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/mmu_helper.c

  Log Message:
  -----------
  s390x/mmu: Better storage key reference and change bit handling

Any access sets the reference bit. In case we have a read-fault, we
should not allow writes to the TLB entry if the change bit was not
already set.

This is a preparation for proper storage-key reference/change bit handling
in TCG and a fix for KVM whereby read accesses would set the change
bit (old KVM versions without the ioctl to carry out the translation).

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


  Commit: 065fe80fe03ff0f36a0cbebbd2d4b3c05110d96d
      
https://github.com/qemu/qemu/commit/065fe80fe03ff0f36a0cbebbd2d4b3c05110d96d
  Author: David Hildenbrand <address@hidden>
  Date:   2019-08-22 (Thu, 22 Aug 2019)

  Changed paths:
    M target/s390x/mmu_helper.c

  Log Message:
  -----------
  s390x/mmu: Factor out storage key handling

Factor it out, add a comment how it all works, and also use it in the
REAL MMU.

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


  Commit: 586f3dced9f2b354480c140c070a3d02a0c66a1e
      
https://github.com/qemu/qemu/commit/586f3dced9f2b354480c140c070a3d02a0c66a1e
  Author: Peter Maydell <address@hidden>
  Date:   2019-08-23 (Fri, 23 Aug 2019)

  Changed paths:
    M target/s390x/cpu.h
    M target/s390x/helper.c
    M target/s390x/mem_helper.c
    M target/s390x/mmu_helper.c
    M target/s390x/translate_vx.inc.c

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

s390x updates:
- fix a bug in tcg vector handling
- improved skey handling

# gpg: Signature made Thu 22 Aug 2019 14:43:30 BST
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Cornelia Huck <address@hidden>" [unknown]
# gpg:                 aka "Cornelia Huck <address@hidden>" [full]
# gpg:                 aka "Cornelia Huck <address@hidden>" [full]
# gpg:                 aka "Cornelia Huck <address@hidden>" [unknown]
# gpg:                 aka "Cornelia Huck <address@hidden>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20190822:
  s390x/mmu: Factor out storage key handling
  s390x/mmu: Better storage key reference and change bit handling
  s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE
  s390x/tcg: Rework MMU selection for instruction fetches
  s390x/mmu: ASC selection in s390_cpu_get_phys_page_debug()
  s390x/mmu: Trace the right value if setting/getting the storage key fails
  s390x/tcg: Fix VERIM with 32/64 bit elements

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


Compare: https://github.com/qemu/qemu/compare/45db1ac15753...586f3dced9f2



reply via email to

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