[Qemu-commits] [qemu/qemu] 6d034b: hw/ppc/prep: Remove superfluous call to soundhw_in...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 6d034b7bf8d1c20f193b00fd6434adf399d701da
      
https://github.com/qemu/qemu/commit/6d034b7bf8d1c20f193b00fd6434adf399d701da
  Author: Thomas Huth <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/prep.c

  Log Message:
  -----------
  hw/ppc/prep: Remove superfluous call to soundhw_init()

When using the 40p machine, soundhw_init() is currently called twice,
one time from vl.c and one time from ibm_40p_init(). The call in
ibm_40p_init() was likely just a copy-and-paste from a old version
of the prep machine - but there the call to audio_init() (which was
the previous name of this function) has been removed many years ago
already, with commit b3e6d591b05538056d665572f3e3bbfb3cbb70e7
("audio: enable PCI audio cards for all PCI-enabled targets"), so
we certainly also do not need the soundhw_init() in the 40p function
anymore nowadays.

Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Sahid Ferdjaoui <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Reviewed-by: Hervé Poussineau <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: a733371214b68881d84725a3c71f60e2faf3b8e2
      
https://github.com/qemu/qemu/commit/a733371214b68881d84725a3c71f60e2faf3b8e2
  Author: Greg Kurz <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M qapi/string-input-visitor.c
    M qapi/string-output-visitor.c

  Log Message:
  -----------
  qapi: add explicit null to string input and output visitors

This may be used for deprecated object properties that are kept for
backwards compatibility.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Tested-by: Andrea Bolognani <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 7843c0d60db694b6d97e14ec5538fb97424016c1
      
https://github.com/qemu/qemu/commit/7843c0d60db694b6d97e14ec5538fb97424016c1
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_hcall.c
    M include/hw/ppc/spapr.h
    M target/ppc/compat.c
    M target/ppc/cpu.h
    M target/ppc/translate_init.c

  Log Message:
  -----------
  pseries: Move CPU compatibility property to machine

Server class POWER CPUs have a "compat" property, which is used to set the
backwards compatibility mode for the processor.  However, this only makes
sense for machine types which don't give the guest access to hypervisor
privilege - otherwise the compatibility level is under the guest's control.

To reflect this, this removes the CPU 'compat' property and instead
creates a 'max-cpu-compat' property on the pseries machine.  Strictly
speaking this breaks compatibility, but AFAIK the 'compat' option was
never (directly) used with -device or device_add.

The option was used with -cpu.  So, to maintain compatibility, this
patch adds a hack to the cpu option parsing to strip out any compat
options supplied with -cpu and set them on the machine property
instead of the now deprecated cpu property.

Signed-off-by: David Gibson <address@hidden>
Tested-by: Suraj Jitindar Singh <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Tested-by: Andrea Bolognani <address@hidden>


  Commit: 66d5c492dd3a92fbb6f01f3957fbe3fe5a18613e
      
https://github.com/qemu/qemu/commit/66d5c492dd3a92fbb6f01f3957fbe3fe5a18613e
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  pseries: Reset CPU compatibility mode

Currently, the CPU compatibility mode is set when the cpu is initialized,
then again when the guest negotiates features.  This means if a guest
negotiates a compatibility mode, then reboots, that compatibility mode
will be retained across the reset.

Usually that will get overridden when features are negotiated on the next
boot, but it's still not really correct.  This patch moves the initial set
up of the compatibility mode from cpu init to reset time.  The mode *is*
retained if the reboot was caused by the feature negotiation (it might
be important in that case, though it's unlikely).

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Reviewed-by: Michael Roth <address@hidden>
Tested-by: Andrea Bolognani <address@hidden>


  Commit: d5fc133eed862b815a5eb421ad60cc73ed13c74c
      
https://github.com/qemu/qemu/commit/d5fc133eed862b815a5eb421ad60cc73ed13c74c
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  ppc: Rework CPU compatibility testing across migration

Migrating between different CPU versions is a bit complicated for ppc.
A long time ago, we ensured identical CPU versions at either end by
checking the PVR had the same value.  However, this breaks under KVM
HV, because we always have to use the host's PVR - it's not
virtualized.  That would mean we couldn't migrate between hosts with
different PVRs, even if the CPUs are close enough to compatible in
practice (sometimes identical cores with different surrounding logic
have different PVRs, so this happens in practice quite often).

So, we removed the PVR check, but instead checked that several flags
indicating supported instructions matched.  This turns out to be a bad
idea, because those instruction masks are not architected information, but
essentially a TCG implementation detail.  So changes to qemu internal CPU
modelling can break migration - this happened between qemu-2.6 and
qemu-2.7.  That was addressed by 146c11f1 "target-ppc: Allow eventual
removal of old migration mistakes".

Now, verification of CPU compatibility across a migration basically doesn't
happen.  We simply ignore the PVR of the incoming migration, and hope the
cpu on the destination is close enough to work.

Now that we've cleaned up handling of processor compatibility modes
for pseries machine type, we can do better.  For new machine types
(pseries-2.10+) We allow migration if:

    * The source and destination PVRs are for the same type of CPU, as
      determined by CPU class's pvr_match function
OR  * When the source was in a compatibility mode, and the destination CPU
      supports the same compatibility mode

For older machine types we retain the existing behaviour - current CAS
code will usually set a compat mode which would break backwards
migration if we made them use the new behaviour. [Fixed from an
earlier version by Greg Kurz].

Signed-off-by: David Gibson <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Suraj Jitindar Singh <address@hidden>
Tested-by: Andrea Bolognani <address@hidden>


  Commit: 3a38429748aa4f74abaecf16c4c087e8a325e12a
      
https://github.com/qemu/qemu/commit/3a38429748aa4f74abaecf16c4c087e8a325e12a
  Author: Bharata B Rao <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Add a "no HPT" encoding to HTAB migration stream

Add a "no HPT" encoding (using value -1) to the HTAB migration
stream (in the place of HPT size) when the guest doesn't allocate HPT.
This will help the target side to match target HPT with the source HPT
and thus enable successful migration.

Suggested-by: David Gibson <address@hidden>
Signed-off-by: Bharata B Rao <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d39c90f5f3ae23a6c8202eb6e1204ea84991e7f5
      
https://github.com/qemu/qemu/commit/d39c90f5f3ae23a6c8202eb6e1204ea84991e7f5
  Author: Bharata B Rao <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Fix migration of Radix guests

Fix migration of radix guests by ensuring that we issue
KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.

Reported-by: Nageswara R Sastry <address@hidden>
Signed-off-by: Bharata B Rao <address@hidden>
Reviewed-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: f1c29ebc51be77bd64178c8d9fc98a8f91a69d25
      
https://github.com/qemu/qemu/commit/f1c29ebc51be77bd64178c8d9fc98a8f91a69d25
  Author: Thomas Huth <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M target/ppc/excp_helper.c

  Log Message:
  -----------
  target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Since the introduction of MTTCG, using the msgsnd instruction
abort()s if being called without holding the BQL. So let's protect
that part of the code now with qemu_mutex_lock_iothread().

Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 35068bd15eec80844699173b9e7d5ccb09a6bb87
      
https://github.com/qemu/qemu/commit/35068bd15eec80844699173b9e7d5ccb09a6bb87
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M target/ppc/mmu-radix64.c

  Log Message:
  -----------
  target/ppc: Fix return value in tcg radix mmu fault handler

The mmu fault handler should return 0 if it was able to successfully
handle the fault and a positive value otherwise.

Currently the tcg radix mmu fault handler will return 1 after
successfully handling a fault in virtual mode. This is incorrect
so fix it so that it returns 0 in this case.

The handler already correctly returns 0 when a fault was handled
in real mode and 1 if an interrupt was generated.

Fixes: d5fee0bbe68d ("target/ppc: Implement ISA V3.00 radix page fault handler")

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


  Commit: c95f6161de0b92efbdd64c9ddfdad58843b8760e
      
https://github.com/qemu/qemu/commit/c95f6161de0b92efbdd64c9ddfdad58843b8760e
  Author: Greg Kurz <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/intc/xics.c

  Log Message:
  -----------
  xics: directly register ICPState objects to vmstate

The ICPState objects are currently registered to vmstate as qdev objects.
Their instance ids are hence computed automatically in the migration code,
and thus depends on the order the CPU cores were plugged.

If the destination had its CPU cores plugged in a different order than the
source, then ICPState objects will have different instance_ids and load
the wrong state.

Since CPU objects have a reliable cpu_index which is already used as
instance_id in vmstate, let's use it for ICPState as well.

Please note that this doesn't break migration. Older machine types used to
allocate and realize all ICPState objects at machine init time, for the whole
lifetime of the machine. The qdev instance ids are thus 0,1,2... nr_servers
and happen to map to the vCPU indexes.

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


  Commit: 46f7afa3709664c7fbc643b2221fd27d5d7762d3
      
https://github.com/qemu/qemu/commit/46f7afa3709664c7fbc643b2221fd27d5d7762d3
  Author: Greg Kurz <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  spapr: fix migration of ICPState objects from/to older QEMU

Commit 5bc8d26de20c ("spapr: allocate the ICPState object from under
sPAPRCPUCore") moved ICPState objects from the machine to CPU cores.
This is an improvement since we no longer allocate ICPState objects
that will never be used. But it has the side-effect of breaking
migration of older machine types from older QEMU versions.

This patch allows spapr to register dummy "icp/server" entries to vmstate.
These entries use a dedicated VMStateDescription that can swallow and
discard state of an incoming migration stream, and that don't send anything
on outgoing migration.

As for real ICPState objects, the instance_id is the cpu_index of the
corresponding vCPU, which happens to be equal to the generated instance_id
of older machine types.

The machine can unregister/register these entries when CPUs are dynamically
plugged/unplugged.

This is only available for pseries-2.9 and older machines, thanks to a
compat property.

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


  Commit: fd356563683216cf3668a79388450747f6d1373b
      
https://github.com/qemu/qemu/commit/fd356563683216cf3668a79388450747f6d1373b
  Author: Bharata B Rao <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M target/ppc/translate_init.c

  Log Message:
  -----------
  target/ppc: Proper cleanup when ppc_cpu_realizefn fails

If ppc_cpu_realizefn() fails after cpu_exec_realizefn() has been
called, we will have to undo whatever cpu_exec_realizefn() did
by explicitly calling cpu_exec_unrealizeffn() which is currently
missing. Failure to do this proper cleanup will result in CPU
which was never fully realized to linger on the cpus list causing
SIGSEGV later (for eg when running "info cpus").

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


  Commit: 6595ab31583ed3ca4a7820dc888fe2de3c37c8a2
      
https://github.com/qemu/qemu/commit/6595ab31583ed3ca4a7820dc888fe2de3c37c8a2
  Author: Bharata B Rao <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr_cpu_core.c

  Log Message:
  -----------
  spapr: prevent QEMU crash when CPU realization fails

ICPState objects were being allocated before CPU thread realization.
However commit 9ed656631d73 (xics: setup cpu at realize time) reversed it
by allocating ICPState objects after CPU thread is realized. But it
didn't take care to fix the error path because of which we observe
a SIGSEGV when CPU thread realization fails during cold/hotplug.

Fix this by ensuring that we do object_unparent() of ICPState object
only in case when is was created earlier.

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


  Commit: aca8bf9f1cbc90da82554c43ef843887ed0ab1ff
      
https://github.com/qemu/qemu/commit/aca8bf9f1cbc90da82554c43ef843887ed0ab1ff
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  hw/ppc/spapr.c: consecutive 'spapr->patb_entry = 0' statements

In ppc_spapr_reset(), if the guest is using HPT, the code was executing:

    } else {
  spapr->patb_entry = 0;
  spapr_setup_hpt_and_vrma(spapr);
    }

And, at the end of spapr_setup_hpt_and_vrma:

    /* We're setting up a hash table, so that means we're not radix */
    spapr->patb_entry = 0;

Resulting in spapr->patb_entry being assigned to 0 twice in a row.

Given that 'spapr_setup_hpt_and_vrma' is also called inside
'spapr_check_setup_free_hpt' of spapr_hcall.c, this trivial patch removes
the 'patb_entry = 0' assignment from the 'else' clause inside ppc_spapr_reset
to avoid this behavior.

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


  Commit: ddd5140b1a0ffca777bb6e845912bc0d700f1f80
      
https://github.com/qemu/qemu/commit/ddd5140b1a0ffca777bb6e845912bc0d700f1f80
  Author: Aaron Larson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/intc/openpic.c

  Log Message:
  -----------
  target-ppc: Enable open-pic timers to count and generate interrupts

Previously QEMU open-pic implemented the 4 open-pic timers including
all timer registers, but the timers did not "count" or generate any
interrupts.  The patch makes the timers both count and generate
interrupts.  The timer clock frequency is fixed at 25MHZ.

--

Responding to V2 patch comments.
- Simplify clock frequency logic and commentary.
- Remove camelCase variables.
- Timer objects now created at init rather than lazily.

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


  Commit: af8ad96bd0119ec8ac3300372fa07349e60d2178
      
https://github.com/qemu/qemu/commit/af8ad96bd0119ec8ac3300372fa07349e60d2178
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Start hotplugged PCI devices in ISOLATED state

PCI DRCs, and only PCI DRCs, are immediately moved to UNISOLATED isolation
state once the device is attached.  This has been there from the initial
implementation, and it's not clear why.

The state diagram in PAPR 13.4 suggests PCI devices should start in
ISOLATED state until the guest moves them into UNISOLATED, and the code in
the guest-side drmgr tool seems to work that way too.

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


  Commit: 307b7715d0256c95444cada36a02882e46bada2f
      
https://github.com/qemu/qemu/commit/307b7715d0256c95444cada36a02882e46bada2f
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_events.c
    M include/hw/ppc/spapr_drc.h

  Log Message:
  -----------
  spapr: Eliminate DRC 'signalled' state variable

The 'signalled' field in the DRC appears to be entirely a torturous
workaround for the fact that PCI devices were started in UNISOLATED state
for unclear reasons.

1) 'signalled' is already meaningless for logical (so far, all non PCI)
DRCs.  It's always set to true (at least at any point it might be tested),
and can't be assigned any real meaning due to the way signalling works for
logical DRCs.

2) For PCI DRCs, the only time signalled would be false is when non-zero
functions of a multifunction device are hotplugged, followed by function
zero (the other way around is explicitly not permitted). In that case the
secondary function DRCs are attached, but the notification isn't sent to
the guest until function 0 is plugged.

3) signalled being false is used to allow a DRC detach to switch mode
back to ISOLATED state, which allows a secondary function to be hotplugged
then unplugged with function 0 never inserted.  Without this a secondary
function starting in UNISOLATED state couldn't be detached again without
function 0 being inserted, all the functions configured by the guest, then
sent back to ISOLATED state.

4) But now that PCI DRCs start in ISOLATED state, there's nothing to be
done.  If the guest doesn't get the notification, it won't switch the
device to UNISOLATED state, so nothing prevents it from being unplugged.
If the guest does move it to UNISOLATED state without the signal (due to
a manual drmgr call, for instance) then it really isn't safe to unplug it.

So, this patch removes the signalled variable and all code related to it.

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


  Commit: 9c914e53702354bc681dedef2e1e6b43fc349043
      
https://github.com/qemu/qemu/commit/9c914e53702354bc681dedef2e1e6b43fc349043
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Split DRC release from DRC detach

spapr_drc_detach() is called when qemu generic code requests a device be
unplugged.  It makes a number of tests, which could well delay further
action until later, before actually detach the device from the DRC.

This splits out the part which actually removes the device from the DRC
into spapr_drc_release().  This will be useful for further cleanups.

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


  Commit: 4f9242fc931ab5e5b1b753c8e5a76c50c0b0612e
      
https://github.com/qemu/qemu/commit/4f9242fc931ab5e5b1b753c8e5a76c50c0b0612e
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  spapr: Make DRC reset force DRC into known state

The reset handler for DRCs attempts several state transitions which are
subject to various checks and restrictions.  But at reset time we know
there is no guest, so we can ignore most of the usual sequencing rules and
just set the DRC back to a known state.  In fact, it's safer to do so.

The existing code also has several redundant checks for
drc->awaiting_release inside a block which has already tested that.  This
patch removes those and sets the DRC to a fixed initial state based only
on whether a device is currently plugged or not.

With DRCs correctly reset to a state based on device presence, we don't
need to force state transitions as cold plugged devices are processed.
This allows us to remove all the callers of the set_*_state() methods from
outside spapr_drc.c.

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


  Commit: 617367321ed6c66118fa981cf61c897f679ab021
      
https://github.com/qemu/qemu/commit/617367321ed6c66118fa981cf61c897f679ab021
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  spapr: Clean up DRC set_allocation_state path

The allocation-state indicator should only actually be implemented for
"logical" DRCs, not physical ones.  Factor a check for this, and also for
valid indicator state values into rtas_set_allocation_state().  Because
they don't exist for physical DRCs, there's no reason that we'd ever want
more than one method implementation, so it can just be a plain function.

In addition, the setting to USABLE and setting to UNUSABLE paths in
set_allocation_state() don't actually have much in common.  So, split the
method separate functions for each parameter value (drc_set_usable()
and drc_set_unusable()).

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


  Commit: 0dfabd39d523fc3f6f0f8c441f41c013cc429b52
      
https://github.com/qemu/qemu/commit/0dfabd39d523fc3f6f0f8c441f41c013cc429b52
  Author: David Gibson <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

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

  Log Message:
  -----------
  spapr: Clean up DRC set_isolation_state() path

There are substantial differences in the various paths through
set_isolation_state(), both for setting to ISOLATED versus UNISOLATED
state and for logical versus physical DRCs.

So, split the set_isolation_state() method into isolate() and unisolate()
methods, and give it different implementations for the two DRC types.

Factor some minimal common checks, including for valid indicator values
(which we weren't previously checking) into rtas_set_isolation_state().

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


  Commit: 36f87b4513373b3cd79c87c9197d17face95d4ac
      
https://github.com/qemu/qemu/commit/36f87b4513373b3cd79c87c9197d17face95d4ac
  Author: Peter Maydell <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M hw/intc/openpic.c
    M hw/intc/xics.c
    M hw/ppc/prep.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_hcall.c
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_drc.h
    M qapi/string-input-visitor.c
    M qapi/string-output-visitor.c
    M target/ppc/compat.c
    M target/ppc/cpu.h
    M target/ppc/excp_helper.c
    M target/ppc/machine.c
    M target/ppc/mmu-radix64.c
    M target/ppc/translate_init.c

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

ppc patch queue 2017-06-30

  * More DRC cleanups, these now actually fix a few bugs
  * Properly implements the openpic timers (they now count and
    generate interrupts)
  * Fixes for XICS migration
  * Fixes for migration of POWER9 RPT guests
  * The last of the compatibility mode rework

# gpg: Signature made Fri 30 Jun 2017 10:52:25 BST
# 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.10-20170630: (21 commits)
  spapr: Clean up DRC set_isolation_state() path
  spapr: Clean up DRC set_allocation_state path
  spapr: Make DRC reset force DRC into known state
  spapr: Split DRC release from DRC detach
  spapr: Eliminate DRC 'signalled' state variable
  spapr: Start hotplugged PCI devices in ISOLATED state
  target-ppc: Enable open-pic timers to count and generate interrupts
  hw/ppc/spapr.c: consecutive 'spapr->patb_entry = 0' statements
  spapr: prevent QEMU crash when CPU realization fails
  target/ppc: Proper cleanup when ppc_cpu_realizefn fails
  spapr: fix migration of ICPState objects from/to older QEMU
  xics: directly register ICPState objects to vmstate
  target/ppc: Fix return value in tcg radix mmu fault handler
  target/ppc/excp_helper: Take BQL before calling cpu_interrupt()
  spapr: Fix migration of Radix guests
  spapr: Add a "no HPT" encoding to HTAB migration stream
  ppc: Rework CPU compatibility testing across migration
  pseries: Reset CPU compatibility mode
  pseries: Move CPU compatibility property to machine
  qapi: add explicit null to string input and output visitors
  ...

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


Compare: https://github.com/qemu/qemu/compare/c5eb5846d2d2...36f87b451337