[Qemu-commits] [qemu/qemu] d6f144: ppc: Define the PSPB register on POWER8

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d6f1445fafa8dcb578c90e7b475fd4728abd99da
      
https://github.com/qemu/qemu/commit/d6f1445fafa8dcb578c90e7b475fd4728abd99da
  Author: Thomas Huth <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M target-ppc/cpu.h
    M target-ppc/translate_init.c

  Log Message:
  -----------
  ppc: Define the PSPB register on POWER8

POWER8 / PowerISA 2.07 has a new special purpose register called PSPB
("Problem State Priority Boost Register"). The contents of this register
are currently lost during migration. To be able to migrate this register,
too, we've got to define this SPR along with the other SPRs of POWER8.

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


  Commit: 1e440cbc99d810ac8153619e6fbee3d7dfaf1893
      
https://github.com/qemu/qemu/commit/1e440cbc99d810ac8153619e6fbee3d7dfaf1893
  Author: Thomas Huth <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M target-ppc/translate_init.c

  Log Message:
  -----------
  ppc: Fix migration of the TAR SPR

The TAR special purpose register currently does not get migrated
under KVM because it does not get synchronized with the kernel.
Use spr_register_kvm() instead of spr_register() to fix this issue.

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


  Commit: 14646457ae79628b797ff8da8842e7d4bad92458
      
https://github.com/qemu/qemu/commit/14646457ae79628b797ff8da8842e7d4bad92458
  Author: Benjamin Herrenschmidt <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M target-ppc/cpu.h
    M target-ppc/translate_init.c

  Log Message:
  -----------
  ppc: Add a few more P8 PMU SPRs

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


  Commit: a88dced8eb69730df39cb04bb3e262e5b98d5f5c
      
https://github.com/qemu/qemu/commit/a88dced8eb69730df39cb04bb3e262e5b98d5f5c
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M target-ppc/cpu-models.c
    M target-ppc/cpu-models.h
    M target-ppc/translate_init.c

  Log Message:
  -----------
  target-ppc: Add PVR for POWER8NVL processor

This adds a new POWER8+NVLink CPU PVR which core is identical to POWER8
but has a different PVR. The only available machine now has PVR
pvr 004c 0100 so this defines "POWER8NVL" alias as v1.0.

The corresponding kernel commit is
https://github.com/torvalds/linux/commit/ddee09c099c3
"powerpc: Add PVR for POWER8NVL processor"

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


  Commit: 788d2599def0e26d92802593b07ec76e8701ccce
      
https://github.com/qemu/qemu/commit/788d2599def0e26d92802593b07ec76e8701ccce
  Author: Michael Roth <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci: fix multifunction hotplug

Since 3f1e147, QEMU has adopted a convention of supporting function
hotplug by deferring hotplug events until func 0 is hotplugged.
This is likely how management tools like libvirt would expose
such support going forward.

Since sPAPR guests rely on per-func events rather than
slot-based, our protocol has been to hotplug func 0 *first* to
avoid cases where devices appear within guests without func 0
present to avoid undefined behavior.

To remain compatible with new convention, defer hotplug in a
similar manner, but then generate events in 0-first order as we
did in the past. Once func 0 present, fail any attempts to plug
additional functions (as we do with PCIe).

For unplug, defer unplug operations in a similar manner, but
generate unplug events such that function 0 is removed last in guest.

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


  Commit: a7a00a729a98e41501904dd26e8535571b3e9579
      
https://github.com/qemu/qemu/commit/a7a00a729a98e41501904dd26e8535571b3e9579
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M target-ppc/kvm.c

  Log Message:
  -----------
  target-ppc: Split out SREGS get/put functions

Currently the getting and setting of Power MMU registers (sregs) take up
large inline chunks of the kvm_arch_get_registers() and
kvm_arch_put_registers() functions.  Especially since there are two
variants (for Book-E and Book-S CPUs), only one of which will be used in
practice, this is pretty hard to read.

This patch splits these out into helper functions for clarity.  No
functional change is expected.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>


  Commit: e5c0d3ce40e40c903a7e65ded61d8742af947655
      
https://github.com/qemu/qemu/commit/e5c0d3ce40e40c903a7e65ded61d8742af947655
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h
    M target-ppc/mmu-hash64.c
    M target-ppc/mmu-hash64.h
    M target-ppc/mmu_helper.c

  Log Message:
  -----------
  target-ppc: Add helpers for updating a CPU's SDR1 and external HPT

When a Power cpu with 64-bit hash MMU has it's hash page table (HPT)
pointer updated by a write to the SDR1 register we need to update some
derived variables.  Likewise, when the cpu is configured for an external
HPT (one not in the guest memory space) some derived variables need to be
updated.

Currently the logic for this is (partially) duplicated in ppc_store_sdr1()
and in spapr_cpu_reset().  In future we're going to need it in some other
places, so make some common helpers for this update.

In addition the new ppc_hash64_set_external_hpt() helper also updates
SDR1 in KVM - it's not updated by the normal runtime KVM <-> qemu CPU
synchronization.  In a sense this belongs logically in the
ppc_hash64_set_sdr1() helper, but that is called from
kvm_arch_get_registers() so can't itself call cpu_synchronize_state()
without infinite recursion.  In practice this doesn't matter because
the only other caller is TCG specific.

Currently there aren't situations where updating SDR1 at runtime in KVM
matters, but there are going to be in future.

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


  Commit: c18ad9a54b75495ce61e8b28d353f8eec51768fc
      
https://github.com/qemu/qemu/commit/c18ad9a54b75495ce61e8b28d353f8eec51768fc
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M target-ppc/mmu-hash64.c
    M target-ppc/mmu-hash64.h

  Log Message:
  -----------
  target-ppc: Eliminate kvmppc_kern_htab global

fa48b43 "target-ppc: Remove hack for ppc_hash64_load_hpte*() with HV KVM"
purports to remove a hack in the handling of hash page tables (HPTs)
managed by KVM instead of qemu.  However, it actually went in the wrong
direction.

That patch requires anything looking for an external HPT (that is one not
managed by the guest itself) to check both env->external_htab (for a qemu
managed HPT) and kvmppc_kern_htab (for a KVM managed HPT).  That's a
problem because kvmppc_kern_htab is local to mmu-hash64.c, but some places
which need to check for an external HPT are outside that, such as
kvm_arch_get_registers().  The latter was subtly broken by the earlier
patch such that gdbstub can no longer access memory.

Basically a KVM managed HPT is much more like a qemu managed HPT than it is
like a guest managed HPT, so the original "hack" was actually on the right
track.

This partially reverts fa48b43, so we again mark a KVM managed external HPT
by putting a special but non-NULL value in env->external_htab.  It then
goes further, using that marker to eliminate the kvmppc_kern_htab global
entirely.  The ppc_hash64_set_external_hpt() helper function is extended
to set that marker if passed a NULL value (if you're setting an external
HPT, but don't have an actual HPT to set, the assumption is that it must
be a KVM managed HPT).

This also has some flow-on changes to the HPT access helpers, required by
the above changes.

Reported-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Tested-by: Greg Kurz <address@hidden>


  Commit: f1a6cf3ef734aab142d5f7ce52e219474ababf6b
      
https://github.com/qemu/qemu/commit/f1a6cf3ef734aab142d5f7ce52e219474ababf6b
  Author: Greg Kurz <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_rng.c

  Log Message:
  -----------
  spapr_rng: fix race with main loop

Since commit "60253ed1e6ec rng: add request queue support to rng-random",
the use of a spapr_rng device may hang vCPU threads.

The following path is taken without holding the lock to the main loop mutex:

h_random()
  rng_backend_request_entropy()
    rng_random_request_entropy()
      qemu_set_fd_handler()

The consequence is that entropy_available() may be called before the vCPU
thread could even queue the request: depending on the scheduling, it may
happen that entropy_available() does not call random_recv()->qemu_sem_post().
The vCPU thread will then sleep forever in h_random()->qemu_sem_wait().

This could not happen before 60253ed1e6ec because entropy_available() used
to call random_recv() unconditionally.

This patch ensures the lock is held to avoid the race.

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


  Commit: 3153119e9bb79ebd82e08d2fde80d1c3a039b6b2
      
https://github.com/qemu/qemu/commit/3153119e9bb79ebd82e08d2fde80d1c3a039b6b2
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/vfio/common.c
    M include/hw/vfio/vfio.h

  Log Message:
  -----------
  vfio: Start improving VFIO/EEH interface

At present the code handling IBM's Enhanced Error Handling (EEH) interface
on VFIO devices operates by bypassing the usual VFIO logic with
vfio_container_ioctl().  That's a poorly designed interface with unclear
semantics about exactly what can be operated on.

In particular it operates on a single vfio container internally (hence the
name), but takes an address space and group id, from which it deduces the
container in a rather roundabout way.  groupids are something that code
outside vfio shouldn't even be aware of.

This patch creates new interfaces for EEH operations.  Internally we
have vfio_eeh_container_op() which takes a VFIOContainer object
directly.  For external use we have vfio_eeh_as_ok() which determines
if an AddressSpace is usable for EEH (at present this means it has a
single container with exactly one group attached), and vfio_eeh_as_op()
which will perform an operation on an AddressSpace in the unambiguous case,
and otherwise returns an error.

This interface still isn't great, but it's enough of an improvement to
allow a number of cleanups in other places.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: 76a9e9f6803f097d8e37afae239c9638ee95dd39
      
https://github.com/qemu/qemu/commit/76a9e9f6803f097d8e37afae239c9638ee95dd39
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci_vfio.c

  Log Message:
  -----------
  spapr_pci: Switch to vfio_eeh_as_op() interface

This switches all EEH on VFIO operations in spapr_pci_vfio.c from the
broken vfio_container_ioctl() interface to the new vfio_as_eeh_op()
interface.

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


  Commit: fbb4e983415dc5a15e167dd00bc4564c57121915
      
https://github.com/qemu/qemu/commit/fbb4e983415dc5a15e167dd00bc4564c57121915
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_pci_vfio.c
    M include/hw/pci-host/spapr.h

  Log Message:
  -----------
  spapr_pci: Eliminate class callbacks

The EEH operations in the spapr-vfio-pci-host-bridge no longer rely on the
special groupid field in sPAPRPHBVFIOState.  So we can simplify, removing
the class specific callbacks with direct calls based on a simple
spapr_phb_eeh_enabled() helper.  For now we implement that in terms of
a boolean in the class, but we'll continue to clean that up later.

On its own this is a rather strange way of doing things, but it's a useful
intermediate step to further cleanups.

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


  Commit: c1fa017c7e9b017ec0a75f8added7f9c4864fe8a
      
https://github.com/qemu/qemu/commit/c1fa017c7e9b017ec0a75f8added7f9c4864fe8a
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_pci_vfio.c
    M include/hw/pci-host/spapr.h

  Log Message:
  -----------
  spapr_pci: Allow EEH on spapr-pci-host-bridge

Now that the EEH code is independent of the special
spapr-vfio-pci-host-bridge device, we can allow it on all spapr PCI
host bridges instead.  We do this by changing spapr_phb_eeh_available()
to be based on the vfio_eeh_as_ok() call instead of the host bridge class.

Because the value of vfio_eeh_as_ok() can change with devices being
hotplugged or unplugged, this can potentially lead to some strange edge
cases where the guest starts using EEH, then it starts failing because
of a change in status.

However, it's not really any worse than the current situation.  Cases that
would have worked previously will still work (i.e. VFIO devices from at
most one VFIO IOMMU group per vPHB), it's just that it's no longer
necessary to use spapr-vfio-pci-host-bridge with the groupid pre-specified.

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


  Commit: 72700d7e733948fa7fbb735ccdf2209931c88476
      
https://github.com/qemu/qemu/commit/72700d7e733948fa7fbb735ccdf2209931c88476
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci_vfio.c
    M include/hw/pci-host/spapr.h

  Log Message:
  -----------
  spapr_pci: (Mostly) remove spapr-pci-vfio-host-bridge

Now that the regular spapr-pci-host-bridge can handle EEH, there are only
two things that spapr-pci-vfio-host-bridge does differently:
    1. automatically sizes its DMA window to match the host IOMMU
    2. checks if the attached VFIO container is backed by the
       VFIO_SPAPR_TCE_IOMMU type on the host

(1) is not particularly useful, since the default window used by the
regular host bridge will work with the host IOMMU configuration on all
current systems anyway.

Plus, automatically changing guest visible configuration (such as the DMA
window) based on host settings is generally a bad idea.  It's not
definitively broken, since spapr-pci-vfio-host-bridge is only supposed to
support VFIO devices which can't be migrated anyway, but still.

(2) is not really useful, because if a guest tries to configure EEH on a
different host IOMMU, the first call will fail and that will be that.

It's possible there are scripts or tools out there which expect
spapr-pci-vfio-host-bridge, so we don't remove it entirely.  This patch
reduces it to just a stub for backwards compatibility.

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


  Commit: a36304fdca8ae38f756f2c86158ce1f0831e7fbc
      
https://github.com/qemu/qemu/commit/a36304fdca8ae38f756f2c86158ce1f0831e7fbc
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr_pci.c
    M include/hw/pci-host/spapr.h

  Log Message:
  -----------
  spapr_pci: Remove finish_realize hook

Now that spapr-pci-vfio-host-bridge is reduced to just a stub, there is
only one implementation of the finish_realize hook in sPAPRPHBClass.  So,
we can fold that implementation into its (single) caller, and remove the
hook.  That's the last thing left in sPAPRPHBClass, so that can go away as
well.

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


  Commit: 3356128cd13d7ec7689b7cddd3efbfbc5339a262
      
https://github.com/qemu/qemu/commit/3356128cd13d7ec7689b7cddd3efbfbc5339a262
  Author: David Gibson <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/vfio/common.c
    M include/hw/vfio/vfio.h

  Log Message:
  -----------
  vfio: Eliminate vfio_container_ioctl()

vfio_container_ioctl() was a bad interface that bypassed abstraction
boundaries, had semantics that sat uneasily with its name, and was unsafe
in many realistic circumstances.  Now that spapr-pci-vfio-host-bridge has
been folded into spapr-pci-host-bridge, there are no more users, so remove
it.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: f235538e38f45f010be9f16834273c2143e0cc77
      
https://github.com/qemu/qemu/commit/f235538e38f45f010be9f16834273c2143e0cc77
  Author: Peter Maydell <address@hidden>
  Date:   2016-03-16 (Wed, 16 Mar 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_pci_vfio.c
    M hw/ppc/spapr_rng.c
    M hw/vfio/common.c
    M include/hw/pci-host/spapr.h
    M include/hw/vfio/vfio.h
    M target-ppc/cpu-models.c
    M target-ppc/cpu-models.h
    M target-ppc/cpu.h
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h
    M target-ppc/mmu-hash64.c
    M target-ppc/mmu-hash64.h
    M target-ppc/mmu_helper.c
    M target-ppc/translate_init.c

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

ppc patch queue for 2016-03-16

Accumulated patches for target-ppc, pseries machine type and related
devices.  As we are now in soft freeze, these are mostly fixes.
   * Fix KVM migration for several SPRs that qemu didn't handle
   * Clean up handling of SDR1, which allows a fix to the gdbstub
   * Fix a race in spapr_rng
   * Fix a bug with multifunction hotplug

The exception is the 7 patches to allow EEH on spapr-pci-host-bridge
devices (rather than the special and poorly designed
spapr-vfio-pci-host-bridge device).  I believe these are low risk of
breaking non-EEH cases, and EEH cases were little used in practice
previously (since libvirt did not support the special device amongst
other things).  It did have a draft posted before the soft freeze,
removes a very ugly VFIO interface, and removes device we'd like to
deprecate sooner rather than later.  So, I'm hoping we can squeeze
these in during the soft freeze.

This includes two patches to the VFIO code, which Alex Williamson has
indicated he's ok with coming through my tree.

# gpg: Signature made Wed 16 Mar 2016 05:04:52 GMT using RSA key ID 20D9B392
# 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: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.6-20160316:
  vfio: Eliminate vfio_container_ioctl()
  spapr_pci: Remove finish_realize hook
  spapr_pci: (Mostly) remove spapr-pci-vfio-host-bridge
  spapr_pci: Allow EEH on spapr-pci-host-bridge
  spapr_pci: Eliminate class callbacks
  spapr_pci: Switch to vfio_eeh_as_op() interface
  vfio: Start improving VFIO/EEH interface
  spapr_rng: fix race with main loop
  target-ppc: Eliminate kvmppc_kern_htab global
  target-ppc: Add helpers for updating a CPU's SDR1 and external HPT
  target-ppc: Split out SREGS get/put functions
  spapr_pci: fix multifunction hotplug
  target-ppc: Add PVR for POWER8NVL processor
  ppc: Add a few more P8 PMU SPRs
  ppc: Fix migration of the TAR SPR
  ppc: Define the PSPB register on POWER8

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


Compare: https://github.com/qemu/qemu/compare/af1d3ebbef56...f235538e38f4