[Qemu-commits] [qemu/qemu] a36593: target/ppc: Yet another fix for KVM-HV HPTE access...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: a36593e16757e524c1596d93914155bd8acbb90a
      
https://github.com/qemu/qemu/commit/a36593e16757e524c1596d93914155bd8acbb90a
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M target/ppc/kvm.c

  Log Message:
  -----------
  target/ppc: Yet another fix for KVM-HV HPTE accessors

As stated in the 1ad9f0a464fe commit log, the returned entries are not
a whole PTEG. It was not a problem before 1ad9f0a464fe as it would read
a single record assuming it contains a whole PTEG but now the code tries
reading the entire PTEG and "if ((n - i) < invalid)" produces negative
values which then are converted to size_t for memset() and that throws
seg fault.

This fixes the math.

While here, fix the last @i increment as well.

Fixes: 1ad9f0a464fe "target/ppc: Fix KVM-HV HPTE accessors"
Signed-off-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 33face6b8981add8eba1f7cdaf4cf6cede415d2e
      
https://github.com/qemu/qemu/commit/33face6b8981add8eba1f7cdaf4cf6cede415d2e
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/Makefile.objs
    M hw/ppc/spapr.c
    A hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Capabilities infrastructure

Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor.  PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.

In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.

Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.

We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability.  But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.

This introduces an infrastructure for defining "sPAPR capabilities".  These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.

The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations).  If not we simply fail, rather than silently modifying the
advertised featureset to the guest.

This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.

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


  Commit: ee76a09fc72cfbfab2bb5529320ef7e460adffd8
      
https://github.com/qemu/qemu/commit/ee76a09fc72cfbfab2bb5529320ef7e460adffd8
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

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

  Log Message:
  -----------
  spapr: Treat Hardware Transactional Memory (HTM) as an optional capability

This adds an spapr capability bit for Hardware Transactional Memory.  It is
enabled by default for pseries-2.11 and earlier machine types. with POWER8
or later CPUs (as it must be, since earlier qemu versions would implicitly
allow it).  However it is disabled by default for the latest pseries-2.12
machine type.

This means that with the latest machine type, HTM will not be available,
regardless of CPU, unless it is explicitly enabled on the command line.
That change is made on the basis that:

 * This way running with -M pseries,accel=tcg will start with whatever cpu
   and will provide the same guest visible model as with accel=kvm.
     - More specifically, this means existing make check tests don't have
       to be modified to use cap-htm=off in order to run with TCG

 * We hope to add a new "HTM without suspend" feature in the not too
   distant future which could work on both POWER8 and POWER9 cpus, and
   could be enabled by default.

 * Best guesses suggest that future POWER cpus may well only support the
   HTM-without-suspend model, not the (frankly, horribly overcomplicated)
   POWER8 style HTM with suspend.

 * Anecdotal evidence suggests problems with HTM being enabled when it
   wasn't wanted are more common than being missing when it was.

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


  Commit: be85537d654565e35e359a74b46fc08b7956525c
      
https://github.com/qemu/qemu/commit/be85537d654565e35e359a74b46fc08b7956525c
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

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

  Log Message:
  -----------
  spapr: Validate capabilities on migration

Now that the "pseries" machine type implements optional capabilities (well,
one so far) there's the possibility of having different capabilities
available at either end of a migration.  Although arguably a user error,
it would be nice to catch this situation and fail as gracefully as we can.

This adds code to migrate the capabilities flags.  These aren't pulled
directly into the destination's configuration since what the user has
specified on the destination command line should take precedence.  However,
they are checked against the destination capabilities.

If the source was using a capability which is absent on the destination,
we fail the migration, since that could easily cause a guest crash or other
bad behaviour.  If the source lacked a capability which is present on the
destination we warn, but allow the migration to proceed.

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


  Commit: 3f2ca480eb872b4946baf77f756236b637a5b15a
      
https://github.com/qemu/qemu/commit/3f2ca480eb872b4946baf77f756236b637a5b15a
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h

  Log Message:
  -----------
  target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM

When constructing the "host" cpu class we modify whether the VMX and VSX
vector extensions and DFP (Decimal Floating Point) are available
based on whether KVM can support those instructions.  This can depend on
policy in the host kernel as well as on the actual host cpu capabilities.

However, the way we probe for this is not very nice: we explicitly check
the host's device tree.  That works in practice, but it's not really
correct, since the device tree is a property of the host kernel's platform
which we don't really know about.  We get away with it because the only
modern POWER platforms happen to encode VMX, VSX and DFP availability in
the device tree in the same way.

Arguably we should have an explicit KVM capability for this, but we haven't
needed one so far.  Barring specific KVM policies which don't yet exist,
each of these instruction classes will be available in the guest if and
only if they're available in the qemu userspace process.  We can determine
that from the ELF AUX vector we're supplied with.

Once reworked like this, there are no more callers for kvmppc_get_vmx() and
kvmppc_get_dfp() so remove them.

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


  Commit: 2938664286499c0c30d6e455a7e2e5d3e6c3f63d
      
https://github.com/qemu/qemu/commit/2938664286499c0c30d6e455a7e2e5d3e6c3f63d
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

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

  Log Message:
  -----------
  spapr: Handle VMX/VSX presence as an spapr capability flag

We currently have some conditionals in the spapr device tree code to decide
whether or not to advertise the availability of the VMX (aka Altivec) and
VSX vector extensions to the guest, based on whether the guest cpu has
those features.

This can lead to confusion and subtle failures on migration, since it makes
a guest visible change based only on host capabilities.  We now have a
better mechanism for this, in spapr capabilities flags, which explicitly
depend on user options rather than host capabilities.

Rework the advertisement of VSX and VMX based on a new VSX capability.  We
no longer bother with a conditional for VMX support, because every CPU
that's ever been supported by the pseries machine type supports VMX.

NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on
availability of VSX in libc, so using cap-vsx=off may lead to a fatal
SIGILL in init.

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


  Commit: 2d1fb9bc8e6e78931d8e1bfeb0ed7a4d223b0480
      
https://github.com/qemu/qemu/commit/2d1fb9bc8e6e78931d8e1bfeb0ed7a4d223b0480
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

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

  Log Message:
  -----------
  spapr: Handle Decimal Floating Point (DFP) as an optional capability

Decimal Floating Point has been available on POWER7 and later (server)
cpus.  However, it can be disabled on the hypervisor, meaning that it's
not available to guests.

We currently handle this by conditionally advertising DFP support in the
device tree depending on whether the guest CPU model supports it - which
can also depend on what's allowed in the host for -cpu host.  That can lead
to confusion on migration, since host properties are silently affecting
guest visible properties.

This patch handles it by treating it as an optional capability for the
pseries machine type.

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


  Commit: 4e5fe3688e23d61b45cc549ff1322aff8f50ef45
      
https://github.com/qemu/qemu/commit/4e5fe3688e23d61b45cc549ff1322aff8f50ef45
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

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

  Log Message:
  -----------
  hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation

Currently spapr_caps are tied to boolean values (on or off). This patch
reworks the caps so that they can have any uint8 value. This allows more
capabilities with various values to be represented in the same way
internally. Capabilities are numbered in ascending order. The internal
representation of capability values is an array of uint8s in the
sPAPRMachineState, indexed by capability number.

Capabilities can have their own name, description, options, getter and
setter functions, type and allow functions. They also each have their own
section in the migration stream. Capabilities are only migrated if they
were explictly set on the command line, with the assumption that
otherwise the default will match.

On migration we ensure that the capability value on the destination
is greater than or equal to the capability value from the source. So
long at this remains the case then the migration is considered
compatible and allowed to continue.

This patch implements generic getter and setter functions for boolean
capabilities. It also converts the existings cap-htm, cap-vsx and
cap-dfp capabilities to this new format.

Signed-off-by: David Gibson <address@hidden>


  Commit: 895d5cd620d358c2623c639a150d9320d581b4f8
      
https://github.com/qemu/qemu/commit/895d5cd620d358c2623c639a150d9320d581b4f8
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/spapr_caps.c

  Log Message:
  -----------
  spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo

The options field here is intended to list the available values for the
capability.  It's not used yet, because the existing capabilities are
boolean.

We're going to add capabilities that aren't, but in that case the info on
the possible values can be folded into the .description field.

Signed-off-by: David Gibson <address@hidden>


  Commit: 03ee51d3548f5f553a3089f466483c1c6d5c666b
      
https://github.com/qemu/qemu/commit/03ee51d3548f5f553a3089f466483c1c6d5c666b
  Author: Jose Ricardo Ziviani <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M target/ppc/compat.c

  Log Message:
  -----------
  ppc: Change Power9 compat table to support at most 8 threads/core

Increases the max smt mode to 8 for Power9. That's because KVM supports
smt emulation in this platform so QEMU should allow users to use it as
well.

Today if we try to pass -smp ...,threads=8, QEMU will silently truncate
it to smt4 mode and may cause a crash if we try to perform a cpu
hotplug.

Signed-off-by: Jose Ricardo Ziviani <address@hidden>
[dwg: Added an explanatory comment]
Signed-off-by: David Gibson <address@hidden>


  Commit: abbc124753896f72e3715813ea20dd1924202ff0
      
https://github.com/qemu/qemu/commit/abbc124753896f72e3715813ea20dd1924202ff0
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M target/ppc/compat.c
    M target/ppc/cpu.h

  Log Message:
  -----------
  target/ppc: Clarify compat mode max_threads value

We recently had some discussions that were sidetracked for a while, because
nearly everyone misapprehended the purpose of the 'max_threads' field in
the compatiblity modes table.  It's all about guest expectations, not host
expectations or support (that's handled elsewhere).

In an attempt to avoid a repeat of that confusion, rename the field to
'max_vthreads' and add an explanatory comment.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Jose Ricardo Ziviani <address@hidden>


  Commit: 1f20f2e0ee61d91abff4e86ed1cda1b5244647d3
      
https://github.com/qemu/qemu/commit/1f20f2e0ee61d91abff4e86ed1cda1b5244647d3
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Allow some cases where we can't set VSMT mode in the kernel

At present if we require a vsmt mode that's not equal to the kernel's
default, and the kernel doesn't let us change it (e.g. because it's an old
kernel without support) then we always fail.

But in fact we can cope with the kernel having a different vsmt as long as
  a) it's >= the actual number of vthreads/vcore (so that guest threads
     that are supposed to be on the same core act like it)
  b) it's a submultiple of the requested vsmt mode (so that guest threads
     spaced by the vsmt value will act like they're on different cores)

Allowing this case gives us a bit more freedom to adjust the vsmt behaviour
without breaking existing cases.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>


  Commit: 8904e5a75005fe579c28806003892d8ae4a27dfa
      
https://github.com/qemu/qemu/commit/8904e5a75005fe579c28806003892d8ae4a27dfa
  Author: David Gibson <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Adjust default VSMT value for better migration compatibility

fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the
"vsmt" parameter for the pseries machine type, which controls the spacing
of the vcpu ids of thread 0 for each virtual core.  This was done to bring
some consistency and stability to how that was done, while still allowing
backwards compatibility for migration and otherwise.

The default value we used for vsmt was set to the max of the host's
advertised default number of threads and the number of vthreads per vcore
in the guest.  This was done to continue running without extra parameters
on older KVM versions which don't allow the VSMT value to be changed.

Unfortunately, even that smaller than before leakage of host configuration
into guest visible configuration still breaks things.  Specifically a guest
with 4 (or less) vthread/vcore will get a different vsmt value when
running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host.  That means the
vcpu ids don't line up so you can't migrate between them, though you should
be able to.

Long term we really want to make vsmt == smp_threads for sufficiently
new machine types.  However, that means that qemu will then require a
sufficiently recent KVM (one which supports changing VSMT) - that's still
not widely enough deployed to be really comfortable to do.

In the meantime we need some default that will work as often as
possible.  This patch changes that default to 8 in all circumstances.
This does change guest visible behaviour (including for existing
machine versions) for many cases - just not the most common/important
case.

Following is case by case justification for why this is still the least
worst option.  Note that any of the old behaviours can still be duplicated
after this patch, it's just that it requires manual intervention by
setting the vsmt property on the command line.

KVM HV on POWER8 host:
   This is the overwhelmingly common case in production setups, and is
   unchanged by design.  POWER8 hosts will advertise a default VSMT mode
   of 8, and > 8 vthreads/vcore isn't permitted

KVM HV on POWER7 host:
   Will break, but POWER7s allowing KVM were never released to the public.

KVM HV on POWER9 host:
   Not yet released to the public, breaking this now will reduce other
   breakage later.

KVM HV on PowerPC 970:
   Will theoretically break it, but it was barely supported to begin with
   and already required various user visible hacks to work.  Also so old
   that I just don't care.

TCG:
   This is the nastiest one; it means migration of TCG guests (without
   manual vsmt setting) will break.  Since TCG is rarely used in production
   I think this is worth it for the other benefits.  It does also remove
   one more barrier to TCG<->KVM migration which could be interesting for
   debugging applications.

KVM PR:
   As with TCG, this will break migration of existing configurations,
   without adding extra manual vsmt options.  As with TCG, it is rare in
   production so I think the benefits outweigh breakages.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Reviewed-by: Jose Ricardo Ziviani <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>


  Commit: 60e58bd9f08a3b91a35850f7501a0a1bcf912b6f
      
https://github.com/qemu/qemu/commit/60e58bd9f08a3b91a35850f7501a0a1bcf912b6f
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M pc-bios/skiboot.lid
    M roms/skiboot

  Log Message:
  -----------
  ppc/pnv: Update skiboot firmware image

This is skiboot 5.9 (commit e0ee24c2). It brings improved POWER9
support among many other things. Built from submodule.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 459bb44cc41932a251fdc6cbd18fd0a681cb84e3
      
https://github.com/qemu/qemu/commit/459bb44cc41932a251fdc6cbd18fd0a681cb84e3
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M tests/boot-serial-test.c

  Log Message:
  -----------
  tests/boot-serial-test: fix powernv support

Recent commit introduced the firmware image skiboot 5.9 which
has a different first line ouput.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 83028a2b2871d3787e2fb55fe3e5cd2dda6cc378
      
https://github.com/qemu/qemu/commit/83028a2b2871d3787e2fb55fe3e5cd2dda6cc378
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/pnv.c
    M tests/pnv-xscom-test.c

  Log Message:
  -----------
  ppc/pnv: use POWER9 DD2 processor

commit 1ed9c8af501f ("target/ppc: Add POWER9 DD2.0 model information")
deprecated the POWER9 model v1.0.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 09279d7e7b08ebfaaa40060843dbc8f33977548f
      
https://github.com/qemu/qemu/commit/09279d7e7b08ebfaaa40060843dbc8f33977548f
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/pnv.c
    M tests/pnv-xscom-test.c

  Log Message:
  -----------
  ppc/pnv: change core mask for POWER9

When addressed by XSCOM, the first core has the 0x20 chiplet ID but
the CPU PIR can start at 0x0.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: b3b066e9d8640a5d143cf9241e00160f30d9a89d
      
https://github.com/qemu/qemu/commit/b3b066e9d8640a5d143cf9241e00160f30d9a89d
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/pnv_xscom.c
    M include/hw/ppc/pnv.h

  Log Message:
  -----------
  ppc/pnv: introduce pnv*_is_power9() helpers

These are useful when instantiating device models which are shared
between the POWER8 and the POWER9 processor families.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: c035851ac0584e1491f6d0fa28d92a8c7a872362
      
https://github.com/qemu/qemu/commit/c035851ac0584e1491f6d0fa28d92a8c7a872362
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/pnv.c
    M hw/ppc/pnv_core.c
    M include/hw/ppc/pnv.h
    M include/hw/ppc/pnv_xscom.h
    M tests/pnv-xscom-test.c

  Log Message:
  -----------
  ppc/pnv: fix XSCOM core addressing on POWER9

The XSCOM base address of the core chiplet was wrongly calculated. Use
the OPAL macros to fix that and do a couple of renames.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: fef592f909e99fc4a4a600879b3d64b3bb130fa5
      
https://github.com/qemu/qemu/commit/fef592f909e99fc4a4a600879b3d64b3bb130fa5
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M hw/ppc/pnv.c

  Log Message:
  -----------
  ppc/pnv: change initrd address

When skiboot starts, it first clears the CPU structs for all possible
CPUs on a system :

        for (i = 0; i <= cpu_max_pir; i++)
                memset(&cpu_stacks[i].cpu, 0, sizeof(struct cpu_thread));

On POWER9, cpu_max_pir is quite big, 0x7fff, and the skiboot cpu_stacks
array overlaps with the memory region in which QEMU maps the initramfs
file. Move it upwards in memory to keep it safe.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0bfc0cf0af33e5c68b62a3c8bbc5f49238426729
      
https://github.com/qemu/qemu/commit/0bfc0cf0af33e5c68b62a3c8bbc5f49238426729
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M target/ppc/cpu.h
    M target/ppc/excp_helper.c

  Log Message:
  -----------
  target/ppc: add support for POWER9 HILE

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 2e569845bd314fc1dde83d65dc9b87e71b4d29b4
      
https://github.com/qemu/qemu/commit/2e569845bd314fc1dde83d65dc9b87e71b4d29b4
  Author: Luc MICHEL <address@hidden>
  Date:   2018-01-17 (Wed, 17 Jan 2018)

  Changed paths:
    M target/ppc/mmu_helper.c

  Log Message:
  -----------
  target-ppc: Fix booke206 tlbwe TLB instruction

When overwritting a valid TLB entry with a new one, the previous page
were not flushed in QEMU TLB, leading to incoherent mapping. This commit
fixes this.

Signed-off-by: Luc MICHEL <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 6e03cc5cf0dac9ec40dce7e3500b442761bc8e96
      
https://github.com/qemu/qemu/commit/6e03cc5cf0dac9ec40dce7e3500b442761bc8e96
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-18 (Thu, 18 Jan 2018)

  Changed paths:
    M hw/ppc/Makefile.objs
    M hw/ppc/pnv.c
    M hw/ppc/pnv_core.c
    M hw/ppc/pnv_xscom.c
    M hw/ppc/spapr.c
    A hw/ppc/spapr_caps.c
    M include/hw/ppc/pnv.h
    M include/hw/ppc/pnv_xscom.h
    M include/hw/ppc/spapr.h
    M pc-bios/skiboot.lid
    M roms/skiboot
    M target/ppc/compat.c
    M target/ppc/cpu.h
    M target/ppc/excp_helper.c
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/mmu_helper.c
    M tests/boot-serial-test.c
    M tests/pnv-xscom-test.c

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

ppc patch queue 2017-01-17

Another pull request for ppc related patches.  The most interesting
thing here is the new capabilities framework for the pseries machine
type.  This gives us better handling of several existing
incompatibilities between TCG, PR and HV KVM, as well as new ones that
arise with POWER9.  Further, it will allow reasonable handling of the
advertisement of features necessary to mitigate the recent CVEs
(Spectre and Meltdown).

In addition there's:
     * Improvide handling of different "vsmt" modes
     * Significant enhancements to the "pnv" machine type
     * Assorted other bugfixes

# gpg: Signature made Wed 17 Jan 2018 02:21:50 GMT
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.12-20180117: (22 commits)
  target-ppc: Fix booke206 tlbwe TLB instruction
  target/ppc: add support for POWER9 HILE
  ppc/pnv: change initrd address
  ppc/pnv: fix XSCOM core addressing on POWER9
  ppc/pnv: introduce pnv*_is_power9() helpers
  ppc/pnv: change core mask for POWER9
  ppc/pnv: use POWER9 DD2 processor
  tests/boot-serial-test: fix powernv support
  ppc/pnv: Update skiboot firmware image
  spapr: Adjust default VSMT value for better migration compatibility
  spapr: Allow some cases where we can't set VSMT mode in the kernel
  target/ppc: Clarify compat mode max_threads value
  ppc: Change Power9 compat table to support at most 8 threads/core
  spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo
  hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation
  spapr: Handle Decimal Floating Point (DFP) as an optional capability
  spapr: Handle VMX/VSX presence as an spapr capability flag
  target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM
  spapr: Validate capabilities on migration
  spapr: Treat Hardware Transactional Memory (HTM) as an optional capability
  ...

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


Compare: https://github.com/qemu/qemu/compare/ae7313e7fd73...6e03cc5cf0da