[Qemu-commits] [qemu/qemu] 613e7a: spapr: Provide an error message when migration fai...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 613e7a764501a236cdfce39561f9bcf60c78cf49
      
https://github.com/qemu/qemu/commit/613e7a764501a236cdfce39561f9bcf60c78cf49
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Provide an error message when migration fails due to htab_shift 
mismatch

Include an error message when migration fails due to mismatch in
htab_shift values at source and target. This should provide a bit more
verbose message in addition to the current migration failure message
that reads like:

qemu-system-ppc64: error while loading state for instance 0x0 of device 
'spapr/htab'

After this patch, the failure message will look like this:

qemu-system-ppc64: htab_shift mismatch: source 29 target 24
qemu-system-ppc64: error while loading state for instance 0x0 of device 
'spapr/htab'

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


  Commit: fb0fc8f62c16b5b0910545f56c64aaafc91533ce
      
https://github.com/qemu/qemu/commit/fb0fc8f62c16b5b0910545f56c64aaafc91533ce
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Create pseries-2.5 machine

Add pseries-2.5 machine version.

Signed-off-by: Bharata B Rao <address@hidden>
[Altered to merge before memory hotplug -- dwg]
[Altered to work with b9f072d01 -- dwg]
Signed-off-by: David Gibson <address@hidden>


  Commit: 2c1aaa819a0d68a51086f5d7e8f9a0114ae0305c
      
https://github.com/qemu/qemu/commit/2c1aaa819a0d68a51086f5d7e8f9a0114ae0305c
  Author: Sam Bobroff <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Add /ibm,partition-name

QEMU has a notion of the guest name, so if it's present we might as
well put that into the device tree as /ibm,partition-name.

This is specificed by PAPR.

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


  Commit: a95f99224c08efcf91b4259c34754f69d962bf23
      
https://github.com/qemu/qemu/commit/a95f99224c08efcf91b4259c34754f69d962bf23
  Author: Sam Bobroff <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Add /rtas/ibm,change-msix-capable

QEMU is MSI-X capable and makes it available via ibm,change-msi, so
we should indicate this by adding /rtas/ibm,change-msix-capable to the
device tree.

This is specificed by PAPR.

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


  Commit: b359bd6a424b8de7db994d7120e87a7465b69337
      
https://github.com/qemu/qemu/commit/b359bd6a424b8de7db994d7120e87a7465b69337
  Author: Sam Bobroff <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Make ibm, change-msi respect 3 return values

Currently, rtas_ibm_change_msi() always returns four values even if
less are specified.

Correct this by only returning the fourth parameter if it was
requested.

This is specified by PAPR.

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


  Commit: e39432282e2d2db42645c2ce183dfcaa1488752b
      
https://github.com/qemu/qemu/commit/e39432282e2d2db42645c2ce183dfcaa1488752b
  Author: Sam Bobroff <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_rtas.c

  Log Message:
  -----------
  spapr: SPLPAR Characteristics

Improve the SPLPAR Characteristics information:

    Add MaxPlatProcs: set to max_cpus, the maximum CPUs that could be
    addded to the system.
    Add DesMem: set to the initial memory of the system.
    Add DesProcs: set to smp_cpus, the inital number of CPUs in the
    system.

These tokens and values are specified by PAPR.

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


  Commit: ad440b4ae0727dbef5cace419d94d774de96886c
      
https://github.com/qemu/qemu/commit/ad440b4ae0727dbef5cace419d94d774de96886c
  Author: Andrew Jones <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: add dumpdtb support

dumpdtb (-machine dumpdtb=<file>) allows one to inspect the generated
device tree of machine types that generate device trees. This is
useful for a) seeing what's there b) debugging/testing device tree
generator patches. It can be used as follows

$QEMU_CMDLINE -machine dumpdtb=dtb
dtc -I dtb -O dts dtb

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


  Commit: 627c2ef7898794a28d706ecdf094491bebbb083a
      
https://github.com/qemu/qemu/commit/627c2ef7898794a28d706ecdf094491bebbb083a
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr_drc: Fix potential undefined behaviour

The DRC_INDEX_ID_MASK macro does a left shift on ~0, which is a signed
quantity, and therefore undefined behaviour according to the C spec.  In
particular this causes warnings from the clang sanitizer.

This fixes it by calculating the same mask without using ~0 (I think the
new method is a more common idiom for generating masks anyway).  For good
measure I also use 1ULL to force the expression's type to unsigned long
long, which should be good for assigning to anything we're going to want
to.

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


  Commit: aaf87c6616370685a7cff6a21616fc5db7495014
      
https://github.com/qemu/qemu/commit/aaf87c6616370685a7cff6a21616fc5db7495014
  Author: Thomas Huth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  ppc/spapr: Use qemu_log_mask() for hcall_dprintf()

To see the output of the hcall_dprintf statements, you currently have
to enable the DEBUG_SPAPR_HCALLS macro in include/hw/ppc/spapr.h.
This is ugly because a) not every user who wants to debug guest
problems can or wants to recompile QEMU to be able to see such issues,
and b) since this macro is disabled by default, the code in the
hcall_dprintf() brackets tends to bitrot until somebody temporarily
enables that macro again.
Since the hcall_dprintf statements except one indicate guest
problems, let's always use qemu_log_mask(LOG_GUEST_ERROR, ...) for
this macro instead. One spot indicated an unimplemented host feature,
so this is changed into qemu_log_mask(LOG_UNIMP, ...) instead. Now
it's possible to see all those messages by simply adding the CLI
parameter "-d guest_errors,unimp", without the need to re-compile
the binary.

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


  Commit: e6fc9568c865f2f81499475a4e322cd563fdfd90
      
https://github.com/qemu/qemu/commit/e6fc9568c865f2f81499475a4e322cd563fdfd90
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr_rtas: Prevent QEMU crash during hotplug without a prior device_add

If drmgr is used in the guest to hotplug a device before a device_add
has been issued via the QEMU monitor, QEMU segfaults in configure_connector
call. This occurs due to accessing of NULL FDT which otherwise would have
been created and associated with the DRC during device_add command.

Check for NULL FDT and return failure from configure_connector call.
As per PAPR+, an error value of -9003 seems appropriate for this failure.

Signed-off-by: Bharata B Rao <address@hidden>
Cc: Michael Roth <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: a14aa92b20c5482b9b694901304b8100b3c4b5a1
      
https://github.com/qemu/qemu/commit/a14aa92b20c5482b9b694901304b8100b3c4b5a1
  Author: Gavin Shan <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  sPAPR: Introduce rtas_ldq()

This introduces rtas_ldq() to load 64-bits parameter from continuous
two 4-bytes memory chunk of RTAS parameter buffer, to simplify the
code.

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


  Commit: 785652dc4db2023aeda4e381eb08e0beae67b870
      
https://github.com/qemu/qemu/commit/785652dc4db2023aeda4e381eb08e0beae67b870
  Author: Laurent Vivier <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  pseries: define coldplugged devices as "configured"

When a device is hotplugged, attach() sets "configured" to
false, waiting an action from the OS to configure it and then
to call ibm,configure-connector. On ibm,configure-connector,
the hypervisor sets "configured" to true.

In case of coldplugged device, attach() sets "configured" to
false, but firmware and OS never call the ibm,configure-connector
in this case, so it remains set to false.

It could be harmless, but when we unplug a device, hypervisor
waits the device becomes configured because for it, a not configured
device is a device being configured, so it waits the end of configuration
to unplug it... and it never happens, so it is never unplugged.

This patch set by default coldplugged device to "configured=true",
hotplugged device to "configured=false".

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


  Commit: 92d7a30cb3656f577f87b19042d9b66ff3b20e3b
      
https://github.com/qemu/qemu/commit/92d7a30cb3656f577f87b19042d9b66ff3b20e3b
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF

  Log Message:
  -----------
  pseries: Update SLOF firmware image to qemu-slof-20150813

The changes are:
1. GPT support;
2. Much faster VGA support.

The full changelog is:
  > Add missing half word access case to _FASTRMOVE and _FASTMOVE
  > Remove unused RMOVE64 stub
  > fbuffer: Implement RFILL as an accelerated primitive
  > fbuffer: Implement MRMOVE as an accelerated primitive
  > fbuffer: Precalculate line length in bytes
  > terminal: Disable the terminal-write trace by default
  > boot: remove trailing ":" in the bootpath
  > ci: implement boot client interface
  > boot: bootpath should be complete device path
  > fbuffer: Use a smaller cursor
  > fbuffer: Improve invert-region helper
  > usb-hid: Caps is not always shift
  > cas: Increase FDT buffer size to accomodate larger ibm, cas node properties
  > README: Update with patch submittion note
  > disk-label: add support for booting from GPT FAT partition
  > disk-label: introduce helper to check fat filesystem
  > introduce 8-byte LE helpers
  > disk-label: simplify gpt-prep-partition? routine
  > fbuffer: introduce the invert-region-x helper
  > fbuffer: introduce the invert-region helper
  > fbuffer: simplify address computations in fb8-toggle-cursor

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


  Commit: 22419c2a90b859dcab49f9472259ad8a3ce091d6
      
https://github.com/qemu/qemu/commit/22419c2a90b859dcab49f9472259ad8a3ce091d6
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  pseries: Fix incorrect calculation of threads per socket for chip-id

The device tree presented to pseries machine type guests includes an
ibm,chip-id property which gives essentially the socket number of each
vcpu core (individual vcpu threads don't get a node in the device
tree).

To calculate this, it uses a vcpus_per_socket variable computed as
(smp_cpus / #sockets).  This is correct for the usual case where
smp_cpus == smp_threads * smp_cores * #sockets.

However, you can start QEMU with the number of cores and threads
mismatching the total number of vcpus (whether that _should_ be
permitted is a topic for another day).  It's a bit hard to say what
the "real" number of vcpus per socket here is, but for most purposes
(smp_threads * smp_cores) will more meaningfully match how QEMU
behaves with respect to socket boundaries.

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


  Commit: ef9971dd69bdd84b0987b0e1e4f421223b080afd
      
https://github.com/qemu/qemu/commit/ef9971dd69bdd84b0987b0e1e4f421223b080afd
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr: Enable in-kernel H_SET_MODE handling

For setting debug watchpoints, sPAPR guests use H_SET_MODE hypercall.
The existing QEMU H_SET_MODE handler does not support this but
the KVM handler in HV KVM does. However it is not enabled.

This enables the in-kernel H_SET_MODE handler which handles:
- Completed Instruction Address Breakpoint Register
- Watch point 0 registers.

The rest is still handled in QEMU.

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


  Commit: a8ad731a001d41582c9cec4015f73ab3bc11a28d
      
https://github.com/qemu/qemu/commit/a8ad731a001d41582c9cec4015f73ab3bc11a28d
  Author: Michael Roth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci: fix device tree props for MSI/MSI-X

PAPR requires ibm,req#msi and ibm,req#msi-x to be present in the
device node to define the number of msi/msi-x interrupts the device
supports, respectively.

Currently we have ibm,req#msi-x hardcoded to a non-sensical constant
that happens to be 2, and are missing ibm,req#msi entirely. The result
of that is that msi-x capable devices get limited to 2 msi-x
interrupts (which can impact performance), and msi-only devices likely
wouldn't work at all. Additionally, if devices expect a minimum that
exceeds 2, the guest driver may fail to load entirely.

SLOF still owns the generation of these properties at boot-time
(although other device properties have since been offloaded to QEMU),
but for hotplugged devices we rely on the values generated by QEMU
and thus hit the limitations above.

Fix this by generating these properties in QEMU as expected by guests.

In the future it may make sense to modify SLOF to pass through these
values directly as we do with other props since we're duplicating SLOF
code.

Cc: address@hidden
Cc: address@hidden
Cc: David Gibson <address@hidden>
Cc: Nikunj A Dadhania <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 9d1852ce11c888e3ad5096be505d14045d8b49ae
      
https://github.com/qemu/qemu/commit/9d1852ce11c888e3ad5096be505d14045d8b49ae
  Author: Michael Roth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr_drc: don't allow 'empty' DRCs to be unisolated or allocated

Logical resources start with allocation-state:UNUSABLE /
isolation-state:ISOLATED. During hotplug, guests will transition
them to allocation-state:USABLE, and then to
isolation-state:UNISOLATED.

For cases where we cannot transition to allocation-state:USABLE,
in this case due to no device/resource being association with
the logical DRC, we should return an error -3.

For physical DRCs, we default to allocation-state:USABLE and stay
there, so in this case we should report an error -3 when the guest
attempts to make the isolation-state:ISOLATED transition for a DRC
with no device associated.

These are as documented in PAPR 2.7, 13.5.3.4.

We also ensure allocation-state:USABLE when the guest attempts
transition to isolation-state:UNISOLATED to deal with misbehaving
guests attempting to bring online an unallocated logical resource.

This is as documented in PAPR 2.7, 13.7.

Currently we implement no such error logic. Fix this by handling
these error cases as PAPR defines.

Cc: Bharata B Rao <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 4a1c9cf0073e733b421e7b82ad673e7cf6ed8454
      
https://github.com/qemu/qemu/commit/4a1c9cf0073e733b421e7b82ad673e7cf6ed8454
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M default-configs/ppc64-softmmu.mak
    M hw/ppc/spapr.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Initialize hotplug memory address space

Initialize a hotplug memory region under which all the hotplugged
memory is accommodated. Also enable memory hotplug by setting
CONFIG_MEM_HOTPLUG.

Modelled on i386 memory hotplug.

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


  Commit: 0cb688d22b3941af02fee78ba21dc3a39c367e0b
      
https://github.com/qemu/qemu/commit/0cb688d22b3941af02fee78ba21dc3a39c367e0b
  Author: Michael Roth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr_drc: use RTAS return codes for methods called by RTAS

Certain methods in sPAPRDRConnector objects are only ever called by
RTAS and in many cases are responsible for the logic that determines
the RTAS return codes.

Rather than having a level of indirection requiring RTAS code to
re-interpret return values from such methods to determine the
appropriate return code, just pass them through directly.

This requires changing method return types to uint32_t to match the
type of values currently passed to RTAS helpers.

In the case of read accesses like drc->entity_sense() where we weren't
previously reporting any errors, just the read value, we modify the
function to return RTAS return code, and pass the read value back via
reference.

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


  Commit: 94649d423e4647fca3bc3e8b2b363d6d2adee9ce
      
https://github.com/qemu/qemu/commit/94649d423e4647fca3bc3e8b2b363d6d2adee9ce
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Don't use QOM [*] syntax for DR connectors.

The dynamic reconfiguration (hotplug) code for the pseries machine type
uses a "DR connector" QOM object for each resource it will be possible
to hotplug.  Each of these is added to its owner using
    object_property_add_child(owner, "dr-connector[*], ...);

That works ok, mostly, but it means that the property indices are
arbitrary, depending on the order in which the connectors are constructed.
That might line up to something useful, but it doesn't have to.

It will get worse once we add hotplug RAM support.  That will add a DR
connector object for every 256MB of potential memory.  So if maxmem=2T,
for example, there are 8192 objects under the same parent.

The QOM interfaces aren't really designed for this.  In particular
object_property_add() with [*] has O(n^2) time complexity (in the number of
existing children): first it has a linear search through array indices to
find a free slot, each of which is attempted to a recursive call to
object_property_add() with a specific [N].  Those calls are O(n) because
there's a linear search through all properties to check for duplicates.

By using a meaningful index value, which we already know is unique we can
avoid the [*] special behaviour.  That lets us reduce the total time for
creating the DR objects from O(n^3) to O(n^2).

O(n^2) is still kind of crappy, but it's enough to reduce the startup time
of qemu (with in-progress memory hotplug support) with maxmem=2T from ~20
minutes to ~4 seconds.

Signed-off-by: David Gibson <address@hidden>
Cc: Bharata B Rao <address@hidden>
Tested-by: Bharata B Rao <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>


  Commit: 38b02bd846672f33bc2eabcb9847c4b78069e097
      
https://github.com/qemu/qemu/commit/38b02bd846672f33bc2eabcb9847c4b78069e097
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Use QEMU limit for maximum CPUs number

sPAPR uses hard coded limit of maximum 255 supported CPUs which is
exactly the same as QEMU-wide limit which is MAX_CPUMASK_BITS and also
defined as 255.

This makes use of a global CPU number limit for the "pseries" machine.

In order to anticipate future increase of the MAX_CPUMASK_BITS
(or to help debugging large systems), this also bumps the FDT_MAX_SIZE
limit from 256K to 1M assuming that 1 CPU core needs roughly 512 bytes
in the device tree so the new limit can cover up to 2048 CPU cores.

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


  Commit: 224245bf524189789d231f38434c9f8fd57a249c
      
https://github.com/qemu/qemu/commit/224245bf524189789d231f38434c9f8fd57a249c
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr: Add LMB DR connectors

Enable memory hotplug for pseries 2.4 and add LMB DR connectors.
With memory hotplug, enforce RAM size, NUMA node memory size and maxmem
to be a multiple of SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the
granularity in which LMBs are represented and hot-added.

LMB DR connectors will be used by the memory hotplug code.

Signed-off-by: Bharata B Rao <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
         [spapr_drc_reset implementation]
[since this missed the 2.4 cutoff, changing to only enable for 2.5]
Signed-off-by: David Gibson <address@hidden>


  Commit: 03d196b7c57f22f796197f221f9d95336debee9e
      
https://github.com/qemu/qemu/commit/03d196b7c57f22f796197f221f9d95336debee9e
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M docs/specs/ppc-spapr-hotplug.txt
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Support ibm,dynamic-reconfiguration-memory

Parse ibm,architecture.vec table obtained from the guest and enable
memory node configuration via ibm,dynamic-reconfiguration-memory if guest
supports it. This is in preparation to support memory hotplug for
sPAPR guests.

This changes the way memory node configuration is done. Currently all
memory nodes are built upfront. But after this patch, only address@hidden node
for RMA is built upfront. Guest kernel boots with just that and rest of
the memory nodes (via address@hidden or ibm,dynamic-reconfiguration-memory)
are built when guest does ibm,client-architecture-support call.

Note: This patch needs a SLOF enhancement which is already part of
SLOF binary in QEMU.

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


  Commit: ce881f774d69d941eb999c25f0cb1f72cd228795
      
https://github.com/qemu/qemu/commit/ce881f774d69d941eb999c25f0cb1f72cd228795
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Make hash table size a factor of maxram_size

The hash table size is dependent on ram_size, but since with hotplug
the memory can grow till maxram_size. Hence make hash table size dependent
on maxram_size.

This allows to hotplug huge amounts of memory to the guest.

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


  Commit: c20d332a85c95245e3b720bfea1bd02e3a311463
      
https://github.com/qemu/qemu/commit/c20d332a85c95245e3b720bfea1bd02e3a311463
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr: Memory hotplug support

Make use of pc-dimm infrastructure to support memory hotplug
for PowerPC.

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


  Commit: b556854bd8524c26b8be98ab1bfdf0826831e793
      
https://github.com/qemu/qemu/commit/b556854bd8524c26b8be98ab1bfdf0826831e793
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Don't allow memory hotplug to memory less nodes

Currently PowerPC kernel doesn't allow hot-adding memory to memory-less
node, but instead will silently add the memory to the first node that has
some memory. This causes two unexpected behaviours for the user.

- Memory gets hotplugged to a different node than what the user specified.
- Since pc-dimm subsystem in QEMU still thinks that memory belongs to
  memory-less node, a reboot will set things accordingly and the previously
  hotplugged memory now ends in the right node. This appears as if some
  memory moved from one node to another.

So until kernel starts supporting memory hotplug to memory-less
nodes, just prevent such attempts upfront in QEMU.

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


  Commit: 19a35c9e1b964f420ee07141f049e6c96c63b740
      
https://github.com/qemu/qemu/commit/19a35c9e1b964f420ee07141f049e6c96c63b740
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Provide better error message when slots exceed max allowed

Currently when user specifies more slots than allowed max of
SPAPR_MAX_RAM_SLOTS (32), we error out like this:

qemu-system-ppc64: unsupported amount of memory slots: 64

Let the user know about the max allowed slots like this:

qemu-system-ppc64: Specified number of memory slots 64 exceeds max supported 32

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


  Commit: 6663864e950d40c467ae4ab81c4dac64d7a8d9e6
      
https://github.com/qemu/qemu/commit/6663864e950d40c467ae4ab81c4dac64d7a8d9e6
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Populate ibm,associativity-lookup-arrays correctly for non-NUMA

When NUMA isn't configured explicitly, assume node 0 is present for
the purpose of creating ibm,associativity-lookup-arrays property
under ibm,dynamic-reconfiguration-memory DT node. This ensures that
the associativity index property is correctly updated in ibm,dynamic-memory
for the LMB that is hotplugged.

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


  Commit: e8f986fc57a664a74b9f685b466506366a15201b
      
https://github.com/qemu/qemu/commit/e8f986fc57a664a74b9f685b466506366a15201b
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Revert to address@hidden representation for non-hotplugged memory

Don't represent non-hotluggable memory under drconf node. With this
we don't have to create DRC objects for them.

The effect of this patch is that we revert back to address@hidden representation
for all the memory specified with -m option and represent the cold
plugged memory and hot-pluggable memory under
ibm,dynamic-reconfiguration-memory.

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


  Commit: 7a36ae7a9f4f136d40fe1da4aab66b364d4aa56d
      
https://github.com/qemu/qemu/commit/7a36ae7a9f4f136d40fe1da4aab66b364d4aa56d
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

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

  Log Message:
  -----------
  spapr: Support hotplug by specifying DRC count

Support hotplug identifier type RTAS_LOG_V6_HP_ID_DRC_COUNT that allows
hotplugging of DRCs by specifying the DRC count.

While we are here, rename

spapr_hotplug_req_add_event() to spapr_hotplug_req_add_by_index()
spapr_hotplug_req_remove_event() to spapr_hotplug_req_remove_by_index()

so that they match with spapr_hotplug_req_add_by_count().

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


  Commit: 0a4178692c2375a4516da7b71629bd08ee8697ee
      
https://github.com/qemu/qemu/commit/0a4178692c2375a4516da7b71629bd08ee8697ee
  Author: Bharata B Rao <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT type

Till now memory hotplug used RTAS_LOG_V6_HP_ID_DRC_INDEX hotplug type
which meant that we generated one hotplug type of EPOW event for every
256MB (SPAPR_MEMORY_BLOCK_SIZE). This quickly overruns the kernel
rtas log buffer thus resulting in loss of memory hotplug events. Switch
to RTAS_LOG_V6_HP_ID_DRC_COUNT hotplug type for memory so that we
generate only one event per hotplug request.

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


  Commit: 20bb648dca6d7fe8cdd1941194e7851950b25dc5
      
https://github.com/qemu/qemu/commit/20bb648dca6d7fe8cdd1941194e7851950b25dc5
  Author: David Gibson <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Fix default NUMA node allocation for threads

At present, if guest numa nodes are requested, but the cpus in each node
are not specified, spapr just uses the default behaviour or assigning each
vcpu round-robin to nodes.

If smp_threads != 1, that will assign adjacent threads in a core to
different NUMA nodes.  As well as being just weird, that's a configuration
that can't be represented in the device tree we give to the guest, which
means the guest and qemu end up with different ideas of the NUMA topology.

This patch implements mc->cpu_index_to_socket_id in the spapr code to
make sure vcpus get assigned to nodes only at the socket granularity.

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


  Commit: ef001f069e0f175a036929782c5c63053df9569a
      
https://github.com/qemu/qemu/commit/ef001f069e0f175a036929782c5c63053df9569a
  Author: Thomas Huth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  ppc/spapr: Fix buffer overflow in spapr_populate_drconf_memory()

The buffer that is allocated in spapr_populate_drconf_memory()
is used for setting both, the "ibm,dynamic-memory" and the
"ibm,associativity-lookup-arrays" property. However, only the
size of the first one is taken into account when allocating the
memory. So if the length of the second property is larger than
the length of the first one, we run into a buffer overflow here!
Fix it by taking the length of the second property into account,
too.

Fixes: "spapr: Support ibm,dynamic-reconfiguration-memory" patch
Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 4d9392be6c1aada69ce86c0f6584128976985394
      
https://github.com/qemu/qemu/commit/4d9392be6c1aada69ce86c0f6584128976985394
  Author: Thomas Huth <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/Makefile.objs
    M hw/ppc/spapr.c
    A hw/ppc/spapr_rng.c
    M include/hw/ppc/spapr.h
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h

  Log Message:
  -----------
  ppc/spapr: Implement H_RANDOM hypercall in QEMU

The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.

This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:

 qemu-system-ppc64 -device spapr-rng,use-kvm=true

For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:

 qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
             -device spapr-rng,rng=gid0 ...

See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.

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


  Commit: 47445c80fb57035331574ac1ac0bcee67fb84aeb
      
https://github.com/qemu/qemu/commit/47445c80fb57035331574ac1ac0bcee67fb84aeb
  Author: Gavin Shan <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  sPAPR: Revert don't enable EEH on emulated PCI devices

This reverts commit 7cb18007 ("sPAPR: Don't enable EEH on emulated
PCI devices") as rtas_ibm_set_eeh_option() isn't the right place
to check if there has the corresponding PCI device for the input
address, which can be PE address, not PCI device address.

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


  Commit: d76548a98f4e18d3c65a3d921bbb70caf9be6138
      
https://github.com/qemu/qemu/commit/d76548a98f4e18d3c65a3d921bbb70caf9be6138
  Author: Gavin Shan <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M hw/ppc/spapr_pci_vfio.c

  Log Message:
  -----------
  sPAPR: Enable EEH on VFIO PCI device only

This checks if the PCI device retrieved from the PCI device address
is VFIO PCI device when enabling EEH functionality. If it's not
VFIO PCI device, the EEH functonality isn't enabled.

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


  Commit: 684bb5770ec5d72a66620f64fc5d9672bf8d3509
      
https://github.com/qemu/qemu/commit/684bb5770ec5d72a66620f64fc5d9672bf8d3509
  Author: Peter Maydell <address@hidden>
  Date:   2015-09-23 (Wed, 23 Sep 2015)

  Changed paths:
    M default-configs/ppc64-softmmu.mak
    M docs/specs/ppc-spapr-hotplug.txt
    M hw/ppc/Makefile.objs
    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/spapr_pci_vfio.c
    A hw/ppc/spapr_rng.c
    M hw/ppc/spapr_rtas.c
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_drc.h
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF
    M target-ppc/kvm.c
    M target-ppc/kvm_ppc.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/spapr-next-20150923' into 
staging

sPAPR Patch Queue: 2015-09-23

Highlights:
    * pseries-2.5 machine type
    * Memory hotplug for "pseries" guests
    * Fixes to the PAPR Dynamic Reconfiguration hotplug code
    * Several PAPR compliance fixes
    * New SLOF with:
  * GPT support
  * Much faster VGA handling

# gpg: Signature made Wed 23 Sep 2015 02:50:10 BST using DSA key ID FDDA6FC6
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: F730 2185 38B4 D13E FD80  34F2 6882 CAC6 FDDA 6FC6

* remotes/dgibson/tags/spapr-next-20150923: (36 commits)
  sPAPR: Enable EEH on VFIO PCI device only
  sPAPR: Revert don't enable EEH on emulated PCI devices
  ppc/spapr: Implement H_RANDOM hypercall in QEMU
  ppc/spapr: Fix buffer overflow in spapr_populate_drconf_memory()
  spapr: Fix default NUMA node allocation for threads
  spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT type
  spapr: Support hotplug by specifying DRC count
  spapr: Revert to address@hidden representation for non-hotplugged memory
  spapr: Populate ibm,associativity-lookup-arrays correctly for non-NUMA
  spapr: Provide better error message when slots exceed max allowed
  spapr: Don't allow memory hotplug to memory less nodes
  spapr: Memory hotplug support
  spapr: Make hash table size a factor of maxram_size
  spapr: Support ibm,dynamic-reconfiguration-memory
  spapr: Add LMB DR connectors
  spapr: Use QEMU limit for maximum CPUs number
  spapr: Don't use QOM [*] syntax for DR connectors.
  spapr_drc: use RTAS return codes for methods called by RTAS
  spapr: Initialize hotplug memory address space
  spapr_drc: don't allow 'empty' DRCs to be unisolated or allocated
  ...

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


Compare: https://github.com/qemu/qemu/compare/27c7275a5694...684bb5770ec5