[Qemu-commits] [qemu/qemu] 9acc95: target/ppc: Fix TCG temporary leaks in gen_bcond()

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 9acc95cdd309f1bd4655219887676c332f945204
      
https://github.com/qemu/qemu/commit/9acc95cdd309f1bd4655219887676c332f945204
  Author: Greg Kurz <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Fix TCG temporary leaks in gen_bcond()

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Tested-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: fa200c95f7f99ce14b8af25ea0be478c722d3cec
      
https://github.com/qemu/qemu/commit/fa200c95f7f99ce14b8af25ea0be478c722d3cec
  Author: Greg Kurz <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Enable "decrement and test CTR" version of bcctr

Even if all ISAs up to v3 indeed mention:

    If the "decrement and test CTR" option is specified (BO2=0), the
    instruction form is invalid.

The UMs of all existing 64-bit server class processors say:

    If BO[2] = 0, the contents of CTR (before any update) are used as the
    target address and for the test of the contents of CTR to resolve the
    branch. The contents of the CTR are then decremented and written back
    to the CTR.

The linux kernel has spectre v2 mitigation code that relies on a
BO[2] = 0 variant of bcctr, which is now activated by default on
spapr, even with TCG. This causes linux guests to panic with
the default machine type under TCG.

Since any CPU model can provide its own behaviour for invalid forms,
we could possibly introduce a new instruction flag to handle this.
In practice, since the behaviour is shared by all 64-bit server
processors starting with 970 up to POWER9, let's reuse the
PPC_SEGMENT_64B flag. Caveat: this may have to be fixed later if
POWER10 introduces a different behaviour.

The existing behaviour of throwing a program interrupt is kept for
all other CPU models.

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Tested-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d0db7caddb1939e103a7bc6bbf09b3cd58dcf092
      
https://github.com/qemu/qemu/commit/d0db7caddb1939e103a7bc6bbf09b3cd58dcf092
  Author: Greg Kurz <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M hw/ppc/ppc.c
    M target/ppc/cpu.h
    M target/ppc/helper_regs.h
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Consolidate 64-bit server processor detection in a helper

We use PPC_SEGMENT_64B in various places to guard code that is specific
to 64-bit server processors compliant with arch 2.x. Consolidate the
logic in a helper macro with an explicit name.

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Tested-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 15d68c5e1d910498d38c219565b56a1b3dace95d
      
https://github.com/qemu/qemu/commit/15d68c5e1d910498d38c219565b56a1b3dace95d
  Author: Greg Kurz <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Improve comment of bcctr used for spectre v2 mitigation

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 3e5365b7aa6cb2593665c201e1b37681ac25c55d
      
https://github.com/qemu/qemu/commit/3e5365b7aa6cb2593665c201e1b37681ac25c55d
  Author: Greg Kurz <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M target/ppc/translate/vsx-impl.inc.c

  Log Message:
  -----------
  target/ppc: Fix QEMU crash with stxsdx

I've been hitting several QEMU crashes while running a fedora29 ppc64le
guest under TCG. Each time, this would occur several minutes after the
guest reached login:

Fedora 29 (Twenty Nine)
Kernel 4.20.6-200.fc29.ppc64le on an ppc64le (hvc0)

Web console: https://localhost:9090/

localhost login:
tcg/tcg.c:3211: tcg fatal error

This happens because a bug crept up in the gen_stxsdx() helper when it
was converted to use VSR register accessors by commit 8b3b2d75c7c04
"target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers
for VSR register access".

The code creates a temporary, passes it directly to gen_qemu_st64_i64()
and then to set_cpu_vrsh()... which looks like this was mistakenly
coded as a load instead of a store.

Reverse the logic: read the VSR to the temporary first and then store
it to memory.

Fixes: 8b3b2d75c7c0481544e277dad226223245e058eb
Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Mark Cave-Ayland <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0a794529bd1109aeea0c407784b40a2605e808b9
      
https://github.com/qemu/qemu/commit/0a794529bd1109aeea0c407784b40a2605e808b9
  Author: David Gibson <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M hw/ppc/spapr.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Simplify handling of host-serial and host-model values

27461d69a0f "ppc: add host-serial and host-model machine attributes
(CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine
properties for spapr to explicitly control the values advertised to the
guest in device tree properties with the same names.

The previous behaviour on KVM was to unconditionally populate the device
tree with the real host serial number and model, which leaks possibly
sensitive information about the host to the guest.

To maintain compatibility for old machine types, we allowed those props
to be set to "passthrough" to take the value from the host as before.  Or
they could be set to "none" to explicitly omit the device tree items.

Special casing specific values on what's otherwise a user supplied string
is very ugly.  So, this patch simplifies things by implementing the
backwards compatibility in a different way: we have a machine class flag
set for the older machines, and we only load the host values into the
device tree if A) they're not set by the user and B) we have that flag set.

This does mean that the "passthrough" functionality is no longer available
with the current machine type.  That's ok though: if a user or management
layer really wants the information passed through they can read it
themselves (OpenStack Nova already does something similar for x86).

It also means the user can't explicitly ask for the values to be omitted
on the old machine types.  I think that's an acceptable trade-off: if you
care enough about not leaking the host information you can either move to
the new machine type, or use a dummy value for the properties.

For the new machine type, this also removes an odd inconsistency
between running on a POWER and non-POWER (or non-Linux) hosts: if the
host information couldn't be read from where we expect (in the host's
device tree as exposed by Linux), we'd fallback to omitting the guest
device tree items.

While we're there, improve some poorly worded comments, and the help text
for the properties.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Daniel P. Berrangé <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Tested-by: Greg Kurz <address@hidden>


  Commit: 273fef83f6c669f76fe25f419502ed123dfe15d2
      
https://github.com/qemu/qemu/commit/273fef83f6c669f76fe25f419502ed123dfe15d2
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr/irq: Add XIVE sanity checks on non-P9 machines

On non-P9 machines, the XIVE interrupt mode is not advertised, see
spapr_dt_ov5_platform_support(). Add a couple of checks on the machine
configuration to filter bogus setups and prevent OS failures :

                     Interrupt modes

  CPU/Compat      XICS    XIVE                dual

   P8/P8          OK      QEMU failure (1)    OK (3)
   P9/P8          OK      QEMU failure (2)    OK (3)
   P9/P9          OK      OK                  OK

  (1) CPU exception model is incompatible with XIVE and the presenters
      will fail to realize.

  (2) CPU exception model is compatible with XIVE, but the XIVE CAS
      advertisement is dropped when in POWER8 mode. So we could ended up
      booting with the XIVE DT properties but without the HCALLs. Avoid
      confusing Linux with such settings and fail under QEMU.

  (3) force XICS in machine init

Remove the check on XIVE-only machines in spapr_machine_init(), which
has now become redundant.

Signed-off-by: Cédric Le Goater <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 7d5489e6d15e2922e45a41e4808d03a48457a5ee
      
https://github.com/qemu/qemu/commit/7d5489e6d15e2922e45a41e4808d03a48457a5ee
  Author: David Gibson <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  exec: Only count mapped memory backends for qemu_getrampagesize()

qemu_getrampagesize() works out the minimum host page size backing any of
guest RAM.  This is required in a few places, such as for POWER8 PAPR KVM
guests, because limitations of the hardware virtualization mean the guest
can't use pagesizes larger than the host pages backing its memory.

However, it currently checks against *every* memory backend, whether or not
it is actually mapped into guest memory at the moment.  This is incorrect.

This can cause a problem attempting to add memory to a POWER8 pseries KVM
guest which is configured to allow hugepages in the guest (e.g.
-machine cap-hpt-max-page-size=16m).  If you attempt to add non-hugepage,
you can (correctly) create a memory backend, however it (correctly) will
throw an error when you attempt to map that memory into the guest by
'device_add'ing a pc-dimm.

What's not correct is that if you then reset the guest a startup check
against qemu_getrampagesize() will cause a fatal error because of the new
memory object, even though it's not mapped into the guest.

This patch corrects the problem by adjusting find_max_supported_pagesize()
(called from qemu_getrampagesize() via object_child_foreach) to exclude
non-mapped memory backends.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Acked-by: David Hildenbrand <address@hidden>


  Commit: 94c01767aa9577aac17f7a68935c7d86a1be69ad
      
https://github.com/qemu/qemu/commit/94c01767aa9577aac17f7a68935c7d86a1be69ad
  Author: Peter Maydell <address@hidden>
  Date:   2019-03-29 (Fri, 29 Mar 2019)

  Changed paths:
    M exec.c
    M hw/ppc/ppc.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr.h
    M target/ppc/cpu.h
    M target/ppc/helper_regs.h
    M target/ppc/translate.c
    M target/ppc/translate/vsx-impl.inc.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190329' into 
staging

ppc patch queue 2019-03-29

Here's a set of bugfixes for ppc, aimed at qemu-4.0 during hard freeze.

We have one cleanup that's not strictly a bugfix, but will avoid an
ugly external interface making it to a released version.

We have one change to generic code to tweak the semantics of
qemu_getrampagesize() which fixes a bug for ppc.  This does have a
possible impact on s390x which uses this function for a different
purpose.  I've discussed with David Hildenbrand and Igor Mammedov,
however and we think it won't immediately break anything due to some
existing bugs in the s390 usage.  David H will be following up with
some s390 fixes in that area.

# gpg: Signature made Fri 29 Mar 2019 03:27:49 GMT
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>" [full]
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>" [full]
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>" 
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-4.0-20190329:
  exec: Only count mapped memory backends for qemu_getrampagesize()
  spapr/irq: Add XIVE sanity checks on non-P9 machines
  spapr: Simplify handling of host-serial and host-model values
  target/ppc: Fix QEMU crash with stxsdx
  target/ppc: Improve comment of bcctr used for spectre v2 mitigation
  target/ppc: Consolidate 64-bit server processor detection in a helper
  target/ppc: Enable "decrement and test CTR" version of bcctr
  target/ppc: Fix TCG temporary leaks in gen_bcond()

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


Compare: https://github.com/qemu/qemu/compare/a04d91c70125...94c01767aa95