[Qemu-commits] [qemu/qemu] 3579d6: spapr: Remove unnecessary instance_size specificat...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 3579d606a091eb698cd53cef64e48cfa08cd7805
      
https://github.com/qemu/qemu/commit/3579d606a091eb698cd53cef64e48cfa08cd7805
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Remove unnecessary instance_size specifications from DRC subtypes

All the DRC subtypes explicitly list instance_size in TypeInfo (all as
sizeof(sPAPRDRConnector).  This isn't necessary, since if it's not listed
it will be derived from the parent type.

Worse, this is dangerous, because if a subtype is changed in future to
have a larger structure, then subtypes of that subtype also need to have
instance_size changed, or it will lead to hard to track memory corruption
bugs.

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


  Commit: fd38804b388fdd5f3abd108f260d3e9d625ff7ad
      
https://github.com/qemu/qemu/commit/fd38804b388fdd5f3abd108f260d3e9d625ff7ad
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: migrate pending_events of spapr state

In racing situations between hotplug events and migration operation,
a rtas hotplug event could have not yet be delivered to the source
guest when migration is started. In this case the pending_events of
spapr state need be transmitted to the target so that the hotplug
event can be finished on the target.

To achieve the minimal VMSD possible to migrate the pending_events list,
this patch makes the changes in spapr_events.c:

- 'log_type' of sPAPREventLogEntry struct deleted. This information can be
derived by inspecting the rtas_error_log summary field. A new function
called 'spapr_event_log_entry_type' was added to retrieve the type of
a given sPAPREventLogEntry.

- sPAPREventLogEntry, epow_log_full and hp_log_full were redesigned. The
only data we're going to migrate in the VMSD is the event log data itself,
which can be divided in two parts: a rtas_error_log header and an extended
event log field. The rtas_error_log header contains information about the
size of the extended log field, which can be used inside VMSD as the size
parameter of the VBUFFER_ALOC field that will store it. To allow this use,
the header.extended_length field must be exposed inline to the VMSD instead
of embedded into a 'data' field that holds everything. With this in mind,
the following changes were done:

    * a new 'header' field was added to sPAPREventLogEntry. This field holds a
a struct rtas_error_log inline.
    * the declaration of the 'rtas_error_log' struct was moved to spapr.h
to be visible to the VMSD macros.
    * 'data' field of sPAPREventLogEntry was renamed to 'extended_log' and
now holds only the contents of the extended event log.
   *  'struct rtas_error_log hdr' were taken away from both epow_log_full
and hp_log_full. This information is now available at the header field of
sPAPREventLogEntry.
   * epow_log_full and hp_log_full were renamed to epow_extended_log and
hp_extended_log respectively. This rename makes it clearer to understand
the new purpose of both structures: hold the information of an extended
event log field.
    * spapr_powerdown_req and spapr_hotplug_req_event now creates a
sPAPREventLogEntry structure that contains the full rtas log entry.
    * rtas_event_log_queue and rtas_event_log_dequeue now receives a
sPAPREventLogEntry pointer as a parameter instead of a void pointer.

- the endianess of the sPAPREventLogEntry header is now native instead
of be32. We can use the fields in native endianess internally and write
them in be32 in the guest physical memory inside 'check_exception'. This
allows the VMSD inside spapr.c to read the correct size of the
entended_log field.

- inside spapr.c, pending_events is put in a subsection in the spapr state
VMSD to make sure migration across different versions is not broken.

A small change in rtas_event_log_queue and rtas_event_log_dequeue were also
made: instead of calling qdev_get_machine(), both functions now receive
a pointer to the sPAPRMachineState. This pointer is already available in
the callers of these functions and we don't need to waste resources
calling qdev() again.

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


  Commit: 5341258e863e8e8503ca0e01306cfb0d8f4b8e63
      
https://github.com/qemu/qemu/commit/5341258e863e8e8503ca0e01306cfb0d8f4b8e63
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Minor cleanups to events handling

The rtas_error_log structure is marked packed, which strongly suggests its
precise layout is important to match an external interface.  Along with
that one could expect it to have a fixed endianness to match the same
interface.  That used to be the case - matching the layout of PAPR RTAS
event format and requiring BE fields.

Now, however, it's only used embedded within sPAPREventLogEntry with the
fields in native order, since they're processed internally.

Clear that up by removing the nested structure in sPAPREventLogEntry.
struct rtas_error_log is moved back to spapr_events.c where it is used as
a temporary to help convert the fields in sPAPREventLogEntry to the correct
in memory format when delivering an event to the guest.

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


  Commit: 94fd9cbaa319049d43107fc2128fae803f8a6989
      
https://github.com/qemu/qemu/commit/94fd9cbaa319049d43107fc2128fae803f8a6989
  Author: Laurent Vivier <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Treat devices added before inbound migration as coldplugged

When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.

This causes problems for the management of spapr DRC state.  Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence.  However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.

If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.

In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.

In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.

To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management.  We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).

This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.

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


  Commit: 82a93a1d307064f35c363f79b04b0a0149ac53d9
      
https://github.com/qemu/qemu/commit/82a93a1d307064f35c363f79b04b0a0149ac53d9
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Remove 'awaiting_allocation' DRC flag

The awaiting_allocation flag in the DRC was introduced by aab9913
"spapr_drc: Prevent detach racing against attach for CPU DR", allegedly to
prevent a guest crash on racing attach and detach.  Except.. information
from the BZ actually suggests a qemu crash, not a guest crash.  And there
shouldn't be a problem here anyway: if the guest has already moved the DRC
away from UNUSABLE state, the detach would already be deferred, and if it
hadn't it should be safe to detach it (the guest should fail gracefully
when it attempts to change the allocation state).

I think this was probably just a bandaid for some other problem in the
state management.  So, remove awaiting_allocation and associated code.

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


  Commit: 765d1bdda5282cb38445c6dd82fa8aa0802cc904
      
https://github.com/qemu/qemu/commit/765d1bdda5282cb38445c6dd82fa8aa0802cc904
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Simplify unplug path

spapr_lmb_release() and spapr_core_release() call hotplug_handler_unplug()
which after a bunch of indirection calls spapr_memory_unplug() or
spapr_core_unplug().  But we already know which is the appropriate thing
to call here, so we can just fold it directly into the release function.

Once that's done, there's no need for an hc->unplug method in the spapr
machine at all: since we also have an hc->unplug_request method, the
hotplug core will never use ->unplug.

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


  Commit: ba50822ff835c197563423b688afc6d0fe50f7d0
      
https://github.com/qemu/qemu/commit/ba50822ff835c197563423b688afc6d0fe50f7d0
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Abort on delete failure in spapr_drc_release()

We currently ignore errors from the object_property_del() in
spapr_drc_release().  But the only way that could fail is if the property
doesn't exist, in which case it's a bug that we're in spapr_drc_release()
at all.  So change from ignoring to abort()ing on errors.

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


  Commit: a8dc47fd8249cca45f6314bfd8cf195dc3fbd36b
      
https://github.com/qemu/qemu/commit/a8dc47fd8249cca45f6314bfd8cf195dc3fbd36b
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Refactor spapr_drc_detach()

This function has two unused parameters - remove them.

It also sets awaiting_release on all paths, except one.  On that path
setting it is harmless, since it will be immediately cleared by
spapr_drc_release().  So factor it out of the if statements.

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


  Commit: f1c52354e5bdab6983d13a4c174759c585e834b3
      
https://github.com/qemu/qemu/commit/f1c52354e5bdab6983d13a4c174759c585e834b3
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Cleanups relating to DRC awaiting_release field

'awaiting_release' indicates that the host has requested an unplug of the
device attached to the DRC, but the guest has not (yet) put the device
into a state where it is safe to complete removal.

1. Rename it to 'unplug_requested' which to me at least is clearer

2. Remove the ->release_pending() method used to check this from outside
spapr_drc.c.  The method only plausibly has one implementation, so use
a plain function (spapr_drc_unplug_requested()) instead.

3. Remove it from the migration stream.  Attempting to migrate mid-unplug
is broken not just for spapr - in general management has no good way to
determine if the device should be present on the destination or not.  So,
until that's fixed, there's no point adding extra things to the stream.

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


  Commit: 9d4c0f4f0a71e74fd7e04d73620268484d693adf
      
https://github.com/qemu/qemu/commit/9d4c0f4f0a71e74fd7e04d73620268484d693adf
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Consolidate DRC state variables

Each DRC has three fields describing its state: isolation_state,
allocation_state and configured.  At first this seems like a reasonable
representation, since its based directly on the PAPR defined
isolation-state and allocation-state indicators.  However:
  * Only a few combinations of the two fields' values are permitted
  * allocation_state isn't used at all for physical DRCs
  * The indicators are write only so they don't really have a well
    defined current value independent of each other

This replaces these variables with a single state variable, whose names
and numbers are based on the diagram in LoPAPR section 13.4.  Along with
this we add code to check the current state on various operations and make
sure the requested transition is permitted.

Strictly speaking, this makes guest visible changes to behaviour (since we
probably allowed some transitions we shouldn't have before).  However, a
hypothetical guest broken by that wasn't PAPR compliant, and probably
wouldn't have worked under PowerVM.

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


  Commit: 4445b1d27ee65ceee12b71bc20242996c8eb5cf8
      
https://github.com/qemu/qemu/commit/4445b1d27ee65ceee12b71bc20242996c8eb5cf8
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Remove sPAPRConfigureConnectorState sub-structure

Most of the time, the state of a DRC object is contained in the single
'state' variable.  However, during the transition from UNISOLATE to
CONFIGURED state requires multiple calls to the ibm,configure-connector
RTAS call to retrieve the device tree for the attached device.  We need
some extra state to keep track of where we're up to in delivering the
device tree information to the guest.

Currently that extra state is in a sPAPRConfigureConnectorState
substructure which is only allocated when we're in the middle of the
configure connector process.  That sounds like a good idea, but the extra
state is only two integers - on many platforms that will take up the same
room as the (maybe NULL) ccs pointer even before malloc() overhead.  Plus
it's another object whose lifetime we need to manage.  In short, it's not
worth it.

So, fold the sPAPRConfigureConnectorState substructure directly into the
DRC object.

Previously the structure was allocated lazily when the configure-connector
call discovers it's not there.  Now, we need to initialize the subfields
pre-emptively, as soon as we enter UNISOLATE state.

Although it's not strictly necessary (the field values should only ever
be consulted when in UNISOLATE state), we try to keep them at -1 when in
other states, as a debugging aid.

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


  Commit: 67fea71bf3be579ad0be5abe34cd6fa1bc65ad5b
      
https://github.com/qemu/qemu/commit/67fea71bf3be579ad0be5abe34cd6fa1bc65ad5b
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  spapr: Implement DR-indicator for physical DRCs only

According to PAPR, the DR-indicator should only be valid for physical DRCs,
not logical DRCs.  At the moment we implement it for all DRCs, so restrict
it to physical ones only.

We move the state to the physical DRC subclass, which means adding some
QOM boilerplate to handle the newly distinct type.

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


  Commit: e49c63d5b3234da0debf53cab7ee67de3a4a6a80
      
https://github.com/qemu/qemu/commit/e49c63d5b3234da0debf53cab7ee67de3a4a6a80
  Author: Greg Kurz <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: fix potential memory leak in spapr_core_plug()

Since commit 5c1da81215c7 ("spapr: Remove unnecessary differences between
hotplug and coldplug paths"), the CPU DT for the DRC is always allocated.
This causes a memory leak for pseries-2.6 and older machine types, that
don't support CPU hotplug and don't allocate DRCs for CPUs.

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


  Commit: 2ee77040f53b7720579d897544604e45b3d41963
      
https://github.com/qemu/qemu/commit/2ee77040f53b7720579d897544604e45b3d41963
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M include/hw/ppc/pnv_psi.h

  Log Message:
  -----------
  ppc/pnv: Remove unused XICSState reference

e6f7e110ee70 "ppc/xics: remove the XICSState classes" got rid of
XICSState, this is just an leftover.

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


  Commit: 30f4b05bd090564181554d0890605eb2c143e4ea
      
https://github.com/qemu/qemu/commit/30f4b05bd090564181554d0890605eb2c143e4ea
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M hw/ppc/trace-events
    M include/hw/ppc/spapr.h
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h

  Log Message:
  -----------
  pseries: Stubs for HPT resizing

This introduces stub implementations of the H_RESIZE_HPT_PREPARE and
H_RESIZE_HPT_COMMIT hypercalls which we hope to add in a PAPR
extension to allow run time resizing of a guest's hash page table.  It
also adds a new machine property for controlling whether this new
facility is available.

For now we only allow resizing with TCG, allowing it with KVM will require
kernel changes as well.

Finally, it adds a new string to the hypertas property in the device
tree, advertising to the guest the availability of the HPT resizing
hypercalls.  This is a tentative suggested value, and would need to be
standardized by PAPR before being merged.

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


  Commit: 0b0b831016ae93bc14698a5d7202eb77feafea75
      
https://github.com/qemu/qemu/commit/0b0b831016ae93bc14698a5d7202eb77feafea75
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  pseries: Implement HPT resizing

This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table.  This will eventually allow for more flexible memory
hotplug.

The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function.  The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.

The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion.  If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.

The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT.  The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).

For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT.  This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).

In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs.  That's a project for another day, but should be possible
without any changes to the guest interface.

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


  Commit: 52b81ab5e95a64cb6973fc4d60d2319c4305ddf8
      
https://github.com/qemu/qemu/commit/52b81ab5e95a64cb6973fc4d60d2319c4305ddf8
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  pseries: Enable HPT resizing for 2.10

We've now implemented a PAPR extensions which allows PAPR guests (i.e.
"pseries" machine type) to resize their hash page table during runtime.

However, that extension is only enabled if explicitly chosen on the
command line.  This patch enables it by default for spapr-2.10, but leaves
it disabled (by default) for older machine types.

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


  Commit: 2772cf6be90e39919d0557ba3c57a77313ca9edf
      
https://github.com/qemu/qemu/commit/2772cf6be90e39919d0557ba3c57a77313ca9edf
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  pseries: Use smaller default hash page tables when guest can resize

We've now implemented a PAPR extension allowing PAPR guest to resize
their hash page table (HPT) during runtime.

This patch makes use of that facility to allocate smaller HPTs by default.
Specifically when a guest is aware of the HPT resize facility, qemu sizes
the HPT to the initial memory size, rather than the maximum memory size on
the assumption that the guest will resize its HPT if necessary for hot
plugged memory.

When the initial memory size is much smaller than the maximum memory size
(a common configuration with e.g. oVirt / RHEV) then this can save
significant memory on the HPT.

If the guest does *not* advertise HPT resize awareness when it makes the
ibm,client-architecture-support call, qemu resizes the HPT for maxmimum
memory size (unless it's been configured not to allow such guests at all).

For now we make that reallocation assuming the guest has not yet used the
HPT at all.  That's true in practice, but not, strictly, an architectural
or PAPR requirement.  If we need to in future we can fix this by having
the client-architecture-support call reboot the guest with the revised
HPT size (the client-architecture-support call is explicitly permitted to
trigger a reboot in this way).

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


  Commit: b55d295e3ec98e46f5b39d50e4a3a9725b4289b3
      
https://github.com/qemu/qemu/commit/b55d295e3ec98e46f5b39d50e4a3a9725b4289b3
  Author: David Gibson <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

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

  Log Message:
  -----------
  pseries: Allow HPT resizing with KVM

So far, qemu implements the PAPR Hash Page Table (HPT) resizing extension
with TCG.  The same implementation will work with KVM PR, but we don't
currently allow that.  For KVM HV we can only implement resizing with the
assistance of the host kernel, which needs a new capability and ioctl()s.

This patch adds support for testing the new KVM capability and implementing
the resize in terms of KVM facilities when necessary.  If we're running on
a kernel which doesn't have the new capability flag at all, we fall back to
testing for PR vs. HV KVM using the same hack that we already use in a
number of places for older kernels.

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


  Commit: df8658de43db242ea82183d75cc957c2b0fa013a
      
https://github.com/qemu/qemu/commit/df8658de43db242ea82183d75cc957c2b0fa013a
  Author: Greg Kurz <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: fix memory leak in spapr_core_pre_plug()

In case of error, we must ensure the dynamically allocated base_core_type
is freed, like it is done everywhere else in this function.

This is a regression introduced in QEMU 2.9 by commit 8149e2992f78.

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


  Commit: 346ebfc6fbf1a0c07cbdfc52beef0f0b9b5180d4
      
https://github.com/qemu/qemu/commit/346ebfc6fbf1a0c07cbdfc52beef0f0b9b5180d4
  Author: Cédric Le Goater <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M target/ppc/translate_init.c

  Log Message:
  -----------
  target/ppc: fix CPU hotplug when radix is enabled (TCG)

But when a guest initializes radix mode, it issues a H_REGISTER_PROC_TBL
to update the LPCR of all CPUs. Hot-plugged CPUs inherit from the same
setting under KVM but not under TCG. So, Let's check for radix and update
the default LPCR to keep new CPUs in sync.

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


  Commit: 77031ee1ce4c7e5f4b4941535c4912eb2eb3503c
      
https://github.com/qemu/qemu/commit/77031ee1ce4c7e5f4b4941535c4912eb2eb3503c
  Author: Peter Maydell <address@hidden>
  Date:   2017-07-17 (Mon, 17 Jul 2017)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_hcall.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/trace-events
    M include/hw/ppc/pnv_psi.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_drc.h
    M include/hw/ppc/spapr_ovec.h
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/mmu-hash64.h
    M target/ppc/translate_init.c

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

ppc patch queue 2017-07-17

This pull requests supersedes the one from 2017-07-14.  That one had a
couple of subtle regressions: there was a build error for mingw32, and
an instance_size which was theoretically wrong everywhere, but only
actually bit on the Travis OSX build.

There are two major batches in this set, rather than the usual
collection of assorted fixes.

    * More DRC cleanup.  This gets the state management into a state
      which should fix many of the hotplug+migration problems we've
      had.  Plus it gets the migration stream format into something
      well defined and pretty minimal which we can reasonably support
      into the future.

    * Hashed Page Table resizing.  It's been a while since this was
      posted, but it's been through several previous rounds of review.
      The kernel parts (both guest and host) are merged in 4.11, so
      this is the only remaining piece left to allow resizing of the
      HPT in a running guest.

There are also a handful of unrelated fixes.

# gpg: Signature made Mon 17 Jul 2017 07:36:52 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-20170717: (21 commits)
  target/ppc: fix CPU hotplug when radix is enabled (TCG)
  spapr: fix memory leak in spapr_core_pre_plug()
  pseries: Allow HPT resizing with KVM
  pseries: Use smaller default hash page tables when guest can resize
  pseries: Enable HPT resizing for 2.10
  pseries: Implement HPT resizing
  pseries: Stubs for HPT resizing
  ppc/pnv: Remove unused XICSState reference
  spapr: fix potential memory leak in spapr_core_plug()
  spapr: Implement DR-indicator for physical DRCs only
  spapr: Remove sPAPRConfigureConnectorState sub-structure
  spapr: Consolidate DRC state variables
  spapr: Cleanups relating to DRC awaiting_release field
  spapr: Refactor spapr_drc_detach()
  spapr: Abort on delete failure in spapr_drc_release()
  spapr: Simplify unplug path
  spapr: Remove 'awaiting_allocation' DRC flag
  spapr: Treat devices added before inbound migration as coldplugged
  spapr: Minor cleanups to events handling
  spapr: migrate pending_events of spapr state
  ...

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


Compare: https://github.com/qemu/qemu/compare/6632f6ff96f0...77031ee1ce4c