[Qemu-commits] [qemu/qemu] f350d7: pseries: Update SLOF firmware image

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: f350d78f102faef84910733b6c45e2c72a05d86a
      
https://github.com/qemu/qemu/commit/f350d78f102faef84910733b6c45e2c72a05d86a
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  pseries: Update SLOF firmware image

This adds vTPM support, full-FDT-rebuild-on-CAS fixes and
basic ext4 support.

The full changelog is:

Alexey Kardashevskiy (10):
      disk-label: Prepare for extenting
      disk-label: Support Linux GPT partition type
      ext2: Prepare for extending
      ext2: Rename group-desc-size
      ext2: Read size of group descriptors
      ext2: Read all 64bit of inode number
      ext2/4: Add basic extent tree support
      elf64: Add LE64 ABIv1/2 support for loading images to given address
      fdt: Fix creating new nodes at H_CAS
      version: update to 20200221

Greg Kurz (2):
      fdt: Fix update of "interrupt-controller" node at CAS
      fdt: Delete nodes of devices removed between boot and CAS

Stefan Berger (8):
      slof: Implement SLOF_get_keystroke() and SLOF_reset()
      slof: Make linker script variables accessible
      qemu: Make print_version variable accessible
      tpm: Add TPM CRQ driver implementation
      tpm: Add sha256 implementation
      tcgbios: Add TPM 2.0 support and firmware API
      tcgbios: Implement menu to clear TPM 2 and activate its PCR banks
      tcgbios: Measure the GPT table

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


  Commit: ad334d89a695460ca1387d96bb8ab7aef0909df4
      
https://github.com/qemu/qemu/commit/ad334d89a695460ca1387d96bb8ab7aef0909df4
  Author: Greg Kurz <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr: Handle pending hot plug/unplug requests at CAS

If a hot plug or unplug request is pending at CAS, we currently trigger
a CAS reboot, which severely increases the guest boot time. This is
because SLOF doesn't handle hot plug events and we had no way to fix
the FDT that gets presented to the guest.

We can do better thanks to recent changes in QEMU and SLOF:

- we now return a full FDT to SLOF during CAS

- SLOF was fixed to correctly detect any device that was either added or
  removed since boot time and to update its internal DT accordingly.

The right solution is to process all pending hot plug/unplug requests
during CAS: convert hot plugged devices to cold plugged devices and
remove the hot unplugged ones, which is exactly what spapr_drc_reset()
does. Also clear all hot plug events that are currently queued since
they're no longer relevant.

Note that SLOF cannot currently populate hot plugged PCI bridges or PHBs
at CAS. Until this limitation is lifted, SLOF will reset the machine when
this scenario occurs : this will allow the FDT to be fully processed when
SLOF is started again (ie. the same effect as the CAS reboot that would
occur anyway without this patch).

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


  Commit: 22062e54bb68f5ced71fbdb3f5f2bedb09a8e8c1
      
https://github.com/qemu/qemu/commit/22062e54bb68f5ced71fbdb3f5f2bedb09a8e8c1
  Author: Greg Kurz <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M docs/system/deprecated.rst
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  ppc: Officially deprecate the CPU "compat" property

Server class POWER CPUs have a "compat" property, which was obsoleted
by commit 7843c0d60d and replaced by a "max-cpu-compat" property on the
pseries machine type. A hack was introduced so that passing "compat" to
-cpu would still produce the desired effect, for the sake of backward
compatibility : it strips the "compat" option from the CPU properties
and applies internally it to the pseries machine. The accessors of the
"compat" property were updated to do nothing but warn the user about the
deprecated status when doing something like:

$ qemu-system-ppc64 -global POWER9-family-powerpc64-cpu.compat=power9
qemu-system-ppc64: warning: CPU 'compat' property is deprecated and has no
 effect; use max-cpu-compat machine property instead

This was merged during the QEMU 2.10 timeframe, a few weeks before we
formalized our deprecation process. As a consequence, the "compat"
property fell through the cracks and was never listed in the officialy
deprecated features.

We are now eight QEMU versions later, it is largely time to mention it
in qemu-deprecated.texi. Also, since -global XXX-powerpc64-cpu.compat=
has been emitting warnings since QEMU 2.10 and the usual way of setting
CPU properties is with -cpu, completely remove the "compat" property.
Keep the hack so that -cpu XXX,compat= stays functional some more time,
as required by our deprecation process.

The now empty powerpc_servercpu_properties[] list which was introduced
for "compat" and never had any other use is removed on the way. We can
re-add it in the future if the need for a server class POWER CPU specific
property arises again.

Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
[dwg: Convert from .texi to .rst to match upstream change]
Signed-off-by: David Gibson <address@hidden>


  Commit: af7084e72b66e4c3008f7a70d5f2a06e11af7fbe
      
https://github.com/qemu/qemu/commit/af7084e72b66e4c3008f7a70d5f2a06e11af7fbe
  Author: Shivaprasad G Bhat <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr_nvdimm.c

  Log Message:
  -----------
  spapr: Fix Coverity warning while validating nvdimm options

Fixes Coverity issue,
      CID 1419883:  Error handling issues  (CHECKED_RETURN)
           Calling "qemu_uuid_parse" without checking return value

nvdimm_set_uuid() already verifies if the user provided uuid is valid or
not. So, need to check for the validity during pre-plug validation again.

As this a false positive in this case, assert if not valid to be safe.
Also, error_abort if QOM accessor encounters error while fetching the uuid
property.

Reported-by: Coverity (CID 1419883)
Signed-off-by: Shivaprasad G Bhat <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: f42274cff373e9bd1c2dc5873ba9f6d0a6384dc3
      
https://github.com/qemu/qemu/commit/f42274cff373e9bd1c2dc5873ba9f6d0a6384dc3
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/pnv_lpc.c

  Log Message:
  -----------
  hw/ppc/pnv: Fix typo in comment

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 23513f818f2112cceadfc1cf4007a4f068ecd84b
      
https://github.com/qemu/qemu/commit/23513f818f2112cceadfc1cf4007a4f068ecd84b
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  ppc: Remove stub support for 32-bit hypervisor mode

a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not
fundamentally available only for PowerPC 64" and added a 32-bit version
of the MSR[HV] bit.

But nothing was ever really done with that; there is no meaningful support
for 32-bit hypervisor mode 13 years later.  Let's stop pretending and just
remove the stubs.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Fabiano Rosas <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 19acd4b610a2f6a8db2840faecaab813089a33b2
      
https://github.com/qemu/qemu/commit/19acd4b610a2f6a8db2840faecaab813089a33b2
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M target/ppc/mmu-hash64.c
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  ppc: Remove stub of PPC970 HID4 implementation

The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability.
However, it can be (and often was) strapped into "Apple mode", where the
hypervisor capabilities were disabled (essentially putting it always in
hypervisor mode).

That's actually the only mode of the 970 we support in qemu, and we're
unlikely to change that any time soon.  However, we do have a partial
implementation of the 970's HID4 register which affects things only
relevant for hypervisor mode.

That stub is also really ugly, since it attempts to duplicate the effects
of HID4 by re-encoding it into the LPCR register used in newer CPUs, but
in a really confusing way.

Just get rid of it.

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


  Commit: 682c1dfb86acb19f542d06375b97c604ee000730
      
https://github.com/qemu/qemu/commit/682c1dfb86acb19f542d06375b97c604ee000730
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Correct handling of real mode accesses with vhyp on hash MMU

On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu.  Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.

In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view.  So accesses in
guest real mode don't require translation.  If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.

Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero.  This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU.  It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.

Clean this up by explicitly handling the vhyp case.  While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.

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


  Commit: 1b99e029c5e7bc99d45a9a9b74f2d4d4a3d5befb
      
https://github.com/qemu/qemu/commit/1b99e029c5e7bc99d45a9a9b74f2d4d4a3d5befb
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Introduce ppc_hash64_use_vrma() helper

When running guests under a hypervisor, the hypervisor obviously needs to
be protected from guest accesses even if those are in what the guest
considers real mode (translation off).  The POWER hardware provides two
ways of doing that: The old way has guest real mode accesses simply offset
and bounds checked into host addresses.  It works, but requires that a
significant chunk of the guest's memory - the RMA - be physically
contiguous in the host, which is pretty inconvenient.  The new way, known
as VRMA, has guest real mode accesses translated in roughly the normal way
but with some special parameters.

In POWER7 and POWER8 the LPCR[VPM0] bit selected between the two modes, but
in POWER9 only VRMA mode is supported and LPCR[VPM0] no longer exists.  We
handle that difference in behaviour in ppc_hash64_set_isi().. but not in
other places that we blindly check LPCR[VPM0].

Correct those instances with a new helper to tell if we should be in VRMA
mode.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Reviewed-by: Fabiano Rosas <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: e8b1144e73544ea6e42f8948d61f6c23312a78c5
      
https://github.com/qemu/qemu/commit/e8b1144e73544ea6e42f8948d61f6c23312a78c5
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr_cpu_core.c
    M target/ppc/mmu-hash64.c

  Log Message:
  -----------
  spapr, ppc: Remove VPM0/RMLS hacks for POWER9

For the "pseries" machine, we use "virtual hypervisor" mode where we
only model the CPU in non-hypervisor privileged mode.  This means that
we need guest physical addresses within the modelled cpu to be treated
as absolute physical addresses.

We used to do that by clearing LPCR[VPM0] and setting LPCR[RMLS] to a high
limit so that the old offset based translation for guest mode applied,
which does what we need.  However, POWER9 has removed support for that
translation mode, which meant we had some ugly hacks to keep it working.

We now explicitly handle this sort of translation for virtual hypervisor
mode, so the hacks aren't necessary.  We don't need to set VPM0 and RMLS
from the machine type code - they're now ignored in vhyp mode.  On the cpu
side we don't need to allow LPCR[RMLS] to be set on POWER9 in vhyp mode -
that was only there to allow the hack on the machine side.

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


  Commit: 5167100975e7888de397456adc1678f65a3dbd59
      
https://github.com/qemu/qemu/commit/5167100975e7888de397456adc1678f65a3dbd59
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  target/ppc: Remove RMOR register from POWER9 & POWER10

Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus
from POWER7 onwards.  However the translation mode which the RMOR controls
is no longer supported in POWER9, and so the register has been removed from
the architecture.

Remove it from our model on POWER9 and POWER10.

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


  Commit: e232eccc754b7c61110a21fb029f2946cc968799
      
https://github.com/qemu/qemu/commit/e232eccc754b7c61110a21fb029f2946cc968799
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M target/ppc/cpu-qom.h
    M target/ppc/mmu-hash64.c
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  target/ppc: Use class fields to simplify LPCR masking

When we store the Logical Partitioning Control Register (LPCR) we have a
big switch statement to work out which are valid bits for the cpu model
we're emulating.

As well as being ugly, this isn't really conceptually correct, since it is
based on the mmu_model variable, whereas the LPCR isn't (only) about the
MMU, so mmu_model is basically just acting as a proxy for the cpu model.

Handle this in a simpler way, by adding a suitable lpcr_mask to the QOM
class.

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


  Commit: a864a6b382d52579210b86cde50bc949d48a3155
      
https://github.com/qemu/qemu/commit/a864a6b382d52579210b86cde50bc949d48a3155
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Streamline calculation of RMA limit from LPCR[RMLS]

Currently we use a big switch statement in ppc_hash64_update_rmls() to work
out what the right RMA limit is based on the LPCR[RMLS] field.  There's no
formula for this - it's just an arbitrary mapping defined by the existing
CPU implementations - but we can make it a bit more readable by using a
lookup table rather than a switch.  In addition we can use the MiB/GiB
symbols to make it a bit clearer.

While there we add a bit of clarity and rationale to the comment about
what happens if the LPCR[RMLS] doesn't contain a valid value.

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


  Commit: d37b40daf647aaf2f5e4c4dfcd62c9412ff05009
      
https://github.com/qemu/qemu/commit/d37b40daf647aaf2f5e4c4dfcd62c9412ff05009
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Correct RMLS table

The table of RMA limits based on the LPCR[RMLS] field is slightly wrong.
We're missing the RMLS == 0 => 256 GiB RMA option, which is available on
POWER8, so add that.

The comment that goes with the table is much more wrong.  We *don't* filter
invalid RMLS values when writing the LPCR, and there's not really a
sensible way to do so.  Furthermore, while in theory the set of RMLS values
is implementation dependent, it seems in practice the same set has been
available since around POWER4+ up until POWER8, the last model which
supports RMLS at all.  So, correct that as well.

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


  Commit: 3a56a55ccb2e31e3a52d74db2ddd8ea603ea667b
      
https://github.com/qemu/qemu/commit/3a56a55ccb2e31e3a52d74db2ddd8ea603ea667b
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Only calculate RMLS derived RMA limit on demand

When the LPCR is written, we update the env->rmls field with the RMA limit
it implies.  Simplify things by just calculating the value directly from
the LPCR value when we need it.

It's possible this is a little slower, but it's unlikely to be significant,
since this is only for real mode accesses in a translation configuration
that's not used very often, and the whole thing is behind the qemu TLB
anyway.  Therefore, keeping the number of state variables down and not
having to worry about making sure it's always in sync seems the better
option.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 4c24a87f662a46264dd73f6dd05a4a0c30b2038b
      
https://github.com/qemu/qemu/commit/4c24a87f662a46264dd73f6dd05a4a0c30b2038b
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: Don't store VRMA SLBE persistently

Currently, we construct the SLBE used for VRMA translations when the LPCR
is written (which controls some bits in the SLBE), then use it later for
translations.

This is a bit complex and confusing - simplify it by simply constructing
the SLBE directly from the LPCR when we need it.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 9943266ec36fec54367085758cd3ee821696a791
      
https://github.com/qemu/qemu/commit/9943266ec36fec54367085758cd3ee821696a791
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Don't use weird units for MIN_RMA_SLOF

MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware
requires.  It lets us give a meaningful error if the RMA ends up too small,
rather than just letting SLOF crash.

It's currently stored as a number of megabytes, which is strange for global
constants.  Move that megabyte scaling into the definition of the constant
like most other things use.

Change from M to MiB in the associated message while we're at it.

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


  Commit: 6a84737c80b3febb093e066d451a44e61b54159a
      
https://github.com/qemu/qemu/commit/6a84737c80b3febb093e066d451a44e61b54159a
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr,ppc: Simplify signature of kvmppc_rma_size()

This function calculates the maximum size of the RMA as implied by the
host's page size of structure of the VRMA (there are a number of other
constraints on the RMA size which will supersede this one in many
circumstances).

The current interface takes the current RMA size estimate, and clamps it
to the VRMA derived size.  The only current caller passes in an arguably
wrong value (it will match the current RMA estimate in some but not all
cases).

We want to fix that, but for now just keep concerns separated by having the
KVM helper function just return the VRMA derived limit, and let the caller
combine it with other constraints.  We call the new function
kvmppc_vrma_limit() to more clearly indicate its limited responsibility.

The helper should only ever be called in the KVM enabled case, so replace
its !CONFIG_KVM stub with an assert() rather than a dummy value.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Cedric Le Goater <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 8897ea5a9fc0aafa5ed7eee1e0c49893b91a2d87
      
https://github.com/qemu/qemu/commit/8897ea5a9fc0aafa5ed7eee1e0c49893b91a2d87
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr: Don't attempt to clamp RMA to VRMA constraint

The Real Mode Area (RMA) is the part of memory which a guest can access
when in real (MMU off) mode.  Of course, for a guest under KVM, the MMU
isn't really turned off, it's just in a special translation mode - Virtual
Real Mode Area (VRMA) - which looks like real mode in guest mode.

The mechanics of how this works when using the hash MMU (HPT) put a
constraint on the size of the RMA, which depends on the size of the
HPT.  So, the latter part of spapr_setup_hpt_and_vrma() clamps the RMA
we advertise to the guest based on this VRMA limit.

There are several things wrong with this:
 1) spapr_setup_hpt_and_vrma() doesn't actually clamp, it takes the minimum
    of Node 0 memory size and the VRMA limit.  That will *often* work the
    same as clamping, but there can be other constraints on RMA size which
    supersede Node 0 memory size.  We have real bugs caused by this
    (currently worked around in the guest kernel)
 2) Some callers of spapr_setup_hpt_and_vrma() are in a situation where
    we're past the point that we can actually advertise an RMA limit to the
    guest
 3) But most fundamentally, the VRMA limit depends on host configuration
    (page size) which shouldn't be visible to the guest, but this partially
    exposes it.  This can cause problems with migration in certain edge
    cases, although we will mostly get away with it.

In practice, this clamping is almost never applied anyway.  With 64kiB
pages and the normal rules for sizing of the HPT, the theoretical VRMA
limit will be 4x(guest memory size) and so never hit.  It will hit with
4kiB pages, where it will be (guest memory size)/4.  However all mainstream
distro kernels for POWER have used a 64kiB page size for at least 10 years.

So, simply replace this logic with a check that the RMA we've calculated
based only on guest visible configuration will fit within the host implied
VRMA limit.  This can break if running HPT guests on a host kernel with
4kiB page size.  As noted that's very rare.  There also exist several
possible workarounds:
  * Change the host kernel to use 64kiB pages
  * Use radix MMU (RPT) guests instead of HPT
  * Use 64kiB hugepages on the host to back guest memory
  * Increase the guest memory size so that the RMA hits one of the fixed
    limits before the RMA limit.  This is relatively easy on POWER8 which
    has a 16GiB limit, harder on POWER9 which has a 1TiB limit.
  * Use a guest NUMA configuration which artificially constrains the RMA
    within the VRMA limit (the RMA must always fit within Node 0).

Previously, on KVM, we also temporarily reduced the rma_size to 256M so
that the we'd load the kernel and initrd safely, regardless of the VRMA
limit.  This was a) confusing, b) could significantly limit the size of
images we could load and c) introduced a behavioural difference between
KVM and TCG.  So we remove that as well.

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


  Commit: 1052ab67f4c10ea8961bf1a523b764b19bff1997
      
https://github.com/qemu/qemu/commit/1052ab67f4c10ea8961bf1a523b764b19bff1997
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr: Don't clamp RMA to 16GiB on new machine types

In spapr_machine_init() we clamp the size of the RMA to 16GiB and the
comment saying why doesn't make a whole lot of sense.  In fact, this was
done because the real mode handling code elsewhere limited the RMA in TCG
mode to the maximum value configurable in LPCR[RMLS], 16GiB.

But,
 * Actually LPCR[RMLS] has been able to encode a 256GiB size for a very
   long time, we just didn't implement it properly in the softmmu
 * LPCR[RMLS] shouldn't really be relevant anyway, it only was because we
   used to abuse the RMOR based translation mode in order to handle the
   fact that we're not modelling the hypervisor parts of the cpu

We've now removed those limitations in the modelling so the 16GiB clamp no
longer serves a function.  However, we can't just remove the limit
universally: that would break migration to earlier qemu versions, where
the 16GiB RMLS limit still applies, no matter how bad the reasons for it
are.

So, we replace the 16GiB clamp, with a clamp to a limit defined in the
machine type class.  We set it to 16 GiB for machine types 4.2 and earlier,
but set it to 0 meaning unlimited for the new 5.0 machine type.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 425f0b7adb8773d6989abcf3cb19bf0bcab9e07e
      
https://github.com/qemu/qemu/commit/425f0b7adb8773d6989abcf3cb19bf0bcab9e07e
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Clean up RMA size calculation

Move the calculation of the Real Mode Area (RMA) size into a helper
function.  While we're there clean it up and correct it in a few ways:
  * Add comments making it clearer where the various constraints come from
  * Remove a pointless check that the RMA fits within Node 0 (we've just
    clamped it so that it does)

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 560f421ae9ed0d7f5acf29b1f06bed8adb3a5b51
      
https://github.com/qemu/qemu/commit/560f421ae9ed0d7f5acf29b1f06bed8adb3a5b51
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/viosrp.h

  Log Message:
  -----------
  hw/scsi/viosrp: Add missing 'hw/scsi/srp.h' include

This header use the srp_* structures declared in "hw/scsi/srp.h".

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0dc556987dc01e06b6ff543a6752dbdc4c88f2fb
      
https://github.com/qemu/qemu/commit/0dc556987dc01e06b6ff543a6752dbdc4c88f2fb
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Use SRP_MAX_IU_LEN instead of sizeof flexible array

Replace sizeof() flexible arrays union srp_iu/viosrp_iu by the
SRP_MAX_IU_LEN definition, which is what this code actually meant
to use.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 06109ab34edd59a853efede87d0296aa0c9b1105
      
https://github.com/qemu/qemu/commit/06109ab34edd59a853efede87d0296aa0c9b1105
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Simplify a bit

We already have a 'iu' pointer, use it
(this simplifies the next commit).

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 81e705494f2915b7b6174bc5695d19ee4a083a85
      
https://github.com/qemu/qemu/commit/81e705494f2915b7b6174bc5695d19ee4a083a85
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Introduce req_iu() helper

Introduce the req_iu() helper which returns a pointer to
the viosrp_iu union held in the vscsi_req structure.
This simplifies the next patch.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: ff78b728f6c9d2c274dab20114bfe052322365a1
      
https://github.com/qemu/qemu/commit/ff78b728f6c9d2c274dab20114bfe052322365a1
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c
    M hw/scsi/viosrp.h

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Do not mix SRP IU size with DMA buffer size

The 'union srp_iu' is meant as a pointer to any SRP Information
Unit type, it is not related to the size of a VIO DMA buffer.

Use a plain buffer for the VIO DMA read/write calls.
We can remove the reserved buffer from the 'union srp_iu'.

This issue was noticed when replacing the zero-length arrays
from hw/scsi/srp.h with flexible array member,
'clang -fsanitize=undefined' reported:

  hw/scsi/spapr_vscsi.c:69:29: error: field 'iu' with variable sized type 
'union viosrp_iu' not at the end of a struct or class is a GNU extension 
[-Werror,-Wgnu-variable-sized-type-not-at-end]
       union viosrp_iu         iu;
                               ^

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 13a5490536c5c260ad158d5b9672daebcd1d85d5
      
https://github.com/qemu/qemu/commit/13a5490536c5c260ad158d5b9672daebcd1d85d5
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Prevent buffer overflow

Depending on the length of sense data, vscsi_send_rsp() can
overrun the buffer size.
Do not copy more than SRP_MAX_IU_DATA_LEN bytes, and assert
that vscsi_send_iu() is always called with a size in range.

Reported-by: Paolo Bonzini <address@hidden>
Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: a7017b203770fdc87e05a7f1b977ac30ce6adea6
      
https://github.com/qemu/qemu/commit/a7017b203770fdc87e05a7f1b977ac30ce6adea6
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/scsi/spapr_vscsi.c
    M hw/scsi/trace-events

  Log Message:
  -----------
  hw/scsi/spapr_vscsi: Convert debug fprintf() to trace event

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 52d3403d1e4dab51706f0ede70f88edae2b2ec04
      
https://github.com/qemu/qemu/commit/52d3403d1e4dab51706f0ede70f88edae2b2ec04
  Author: Cédric Le Goater <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/intc/spapr_xive.c

  Log Message:
  -----------
  spapr/xive: use SPAPR_IRQ_IPI to define IPI ranges exposed to the guest

The "ibm,xive-lisn-ranges" defines ranges of interrupt numbers that
the guest can use to configure IPIs. It starts at 0 today but it could
change to some other offset. Make clear which IRQ range we are
exposing by using SPAPR_IRQ_IPI in the property definition.

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


  Commit: 94f040aaecf4e41cc68991b80204b1b6886bbdd0
      
https://github.com/qemu/qemu/commit/94f040aaecf4e41cc68991b80204b1b6886bbdd0
  Author: Vitaly Chikunov <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Fix rlwinm on ppc64

rlwinm cannot just AND with Mask if shift value is zero on ppc64 when
Mask Begin is greater than Mask End and high bits are set to 1.

Note that PowerISA 3.0B says that for `rlwinm' ROTL32 is used, and
ROTL32 is defined (in 3.3.14) so that rotated value should have two
copies of lower word of the source value.

This seems to be another incarnation of the fix from 820724d170
("target-ppc: Fix rlwimi, rlwinm, rlwnm again"), except I leave
optimization when Mask value is less than 32 bits.

Fixes: 7b4d326f47 ("target-ppc: Use the new deposit and extract ops")
Cc: address@hidden
Signed-off-by: Vitaly Chikunov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 395a20d3cc61fa99cf4ad58921050f8a44b369f9
      
https://github.com/qemu/qemu/commit/395a20d3cc61fa99cf4ad58921050f8a44b369f9
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  ppc/spapr: Move GPRs setup to one place

At the moment "pseries" starts in SLOF which only expects the FDT blob
pointer in r3. As we are going to introduce a OpenFirmware support in
QEMU, we will be booting OF clients directly and these expect a stack
pointer in r1, Linux looks at r3/r4 for the initramdisk location
(although vmlinux can find this from the device tree but zImage from
distro kernels cannot).

This extends spapr_cpu_set_entry_state() to take more registers. This
should cause no behavioral change.

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


  Commit: eeea9f9d13102c643319e51498c904010dee231d
      
https://github.com/qemu/qemu/commit/eeea9f9d13102c643319e51498c904010dee231d
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  pseries: Update SLOF firmware image

This mainly fixes virtio-serial with and without
enabled iommu-platform.

The full list of changes is:

Alexey Kardashevskiy (3):
      llfw: Fix debug printf warnings
      virtio-serial: Close device completely
      version: update to 20200312

Cédric Le Goater (1):
      virtio: Fix typo in virtio_serial_init()

Greg Kurz (2):
      virtio-serial: Don't override some words
      virtio-serial: Rework shutdown sequence

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


  Commit: 4dba87221936e18111959344b05ec3384e50fed0
      
https://github.com/qemu/qemu/commit/4dba87221936e18111959344b05ec3384e50fed0
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr/rtas: Reserve space for RTAS blob and log

At the moment SLOF reserves space for RTAS and instantiates the RTAS blob
which is 20 bytes binary blob calling an hypercall. The rest of the RTAS
area is a log which SLOF has no idea about but QEMU does.

This moves RTAS sizing to QEMU and this overrides the size from SLOF.
The only remaining problem is that SLOF copies the number of bytes it
reserved (2KB for now) so QEMU needs to reserve at least this much;
SLOF will be fixed separately to check that rtas-size from QEMU is
enough for those 20 bytes for the H_RTAS hcall.

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


  Commit: fa523f0dd3c5abae3f57cc4d174e2a2c61204518
      
https://github.com/qemu/qemu/commit/fa523f0dd3c5abae3f57cc4d174e2a2c61204518
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Move creation of ibm,dynamic-reconfiguration-memory dt node

Currently this node with information about hotpluggable memory is created
from spapr_dt_cas_updates().  But that's just a hangover from when we
created it only as a diff to the device tree at CAS time.  Now that we
fully rebuild the DT as CAS time, it makes more sense to create this along
with the rest of the memory information in the device tree.

So, move it to spapr_populate_memory().  The patch is huge, but it's nearly
all just code motion.

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


  Commit: 1e0e11085a0d3e47cbbad8944f70b371d22b987d
      
https://github.com/qemu/qemu/commit/1e0e11085a0d3e47cbbad8944f70b371d22b987d
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Move creation of ibm,architecture-vec-5 property

This is currently called from spapr_dt_cas_updates() which is a hang
over from when we created this only as a diff to the DT at CAS time.
Now that we fully rebuild the DT at CAS time, just create it along
with the rest of the properties in /chosen.

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


  Commit: 91335a5e1585afea9cf84ac955a59edbcd9700ab
      
https://github.com/qemu/qemu/commit/91335a5e1585afea9cf84ac955a59edbcd9700ab
  Author: David Gibson <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  spapr: Rename DT functions to newer naming convention

In the spapr code we've been gradually moving towards a convention that
functions which create pieces of the device tree are called spapr_dt_*().
This patch speeds that along by renaming most of the things that don't yet
match that so that they do.

For now we leave the *_dt_populate() functions which are actual methods
used in the DRCClass::dt_populate method.

While we're there we remove a few comments that don't really say anything
useful.

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


  Commit: bae9dc4f28016e1721058dd71392433baf7d36a9
      
https://github.com/qemu/qemu/commit/bae9dc4f28016e1721058dd71392433baf7d36a9
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr_events.c

  Log Message:
  -----------
  ppc/spapr: Fix FWNMI machine check failure handling

ppc_cpu_do_system_reset delivers a system rreset interrupt to the guest,
which is certainly not what is intended here. Panic the guest like other
failure cases here do.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 8af7e1fe6fa4bdd3c4561c13a4bd4ee525e6f02f
      
https://github.com/qemu/qemu/commit/8af7e1fe6fa4bdd3c4561c13a4bd4ee525e6f02f
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_rtas.c
    M include/hw/ppc/spapr.h
    M tests/qtest/libqos/libqos-spapr.h

  Log Message:
  -----------
  ppc/spapr: Change FWNMI names

The option is called "FWNMI", and it involves more than just machine
checks, also machine checks can be delivered without the FWNMI option,
so re-name various things to reflect that.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: edfdbf9c6baf6f8dc17842bd300cd2dd78d5f0d4
      
https://github.com/qemu/qemu/commit/edfdbf9c6baf6f8dc17842bd300cd2dd78d5f0d4
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  ppc/spapr: Add FWNMI System Reset state

The FWNMI option must deliver system reset interrupts to their
registered address, and there are a few constraints on the handler
addresses specified in PAPR. Add the system reset address state and
checks.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviwed-by: Mahesh Salgaonkar <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: ad77c6ca0c63e39eb6ded9c1a761eaa16b21b7f9
      
https://github.com/qemu/qemu/commit/ad77c6ca0c63e39eb6ded9c1a761eaa16b21b7f9
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  ppc/spapr: Fix FWNMI machine check interrupt delivery

FWNMI machine check delivery misses a few things that will make it fail
with TCG at least (which we would like to allow in future to improve
testing).

It's not nice to scatter interrupt delivery logic around the tree, so
move it to excp_helper.c and share code where possible.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 89ba45652b0ce41e96ebf7108cfca0906201a967
      
https://github.com/qemu/qemu/commit/89ba45652b0ce41e96ebf7108cfca0906201a967
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr_caps.c
    M tests/qtest/libqos/libqos-spapr.h

  Log Message:
  -----------
  ppc/spapr: Allow FWNMI on TCG

There should no longer be a reason to prevent TCG providing FWNMI.
System Reset interrupts are generated to the guest with nmi monitor
command and H_SIGNAL_SYS_RESET. Machine Checks can not be injected
currently, but this could be implemented with the mce monitor cmd
similarly to i386.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
[dwg: Re-enable FWNMI in qtests, since that now works]
Signed-off-by: David Gibson <address@hidden>


  Commit: 9aa25280708a066e4920e8348091318f542fd19d
      
https://github.com/qemu/qemu/commit/9aa25280708a066e4920e8348091318f542fd19d
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  target/ppc: allow ppc_cpu_do_system_reset to take an alternate vector

Provide for an alternate delivery location, -1 defaults to the
architected address.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0e236d347790b1d938909207d5db101ab705fdd4
      
https://github.com/qemu/qemu/commit/0e236d347790b1d938909207d5db101ab705fdd4
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  ppc/spapr: Implement FWNMI System Reset delivery

PAPR requires that if "ibm,nmi-register" succeeds, then the hypervisor
delivers all system reset and machine check exceptions to the registered
addresses.

System Resets are delivered with registers set to the architected state,
and with no interlock.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 75aa803835a5e868292a476fd9b5099ffb619619
      
https://github.com/qemu/qemu/commit/75aa803835a5e868292a476fd9b5099ffb619619
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

  Changed paths:
    M hw/ppc/spapr_rtas.c

  Log Message:
  -----------
  ppc/spapr: Ignore common "ibm,nmi-interlock" Linux bug

Linux kernels call "ibm,nmi-interlock" in their system reset handlers
contrary to PAPR. Returning an error because the CPU does not hold the
interlock here causes Linux to print warning messages. PowerVM returns
success in this case, so do the same for now.

Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 6961eae79f58385482775dc0a6c3d553f633662d
      
https://github.com/qemu/qemu/commit/6961eae79f58385482775dc0a6c3d553f633662d
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2020-03-17 (Tue, 17 Mar 2020)

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

  Log Message:
  -----------
  pseries: Update SLOF firmware image

The only change here is moving the decision about rtas-size
to QEMU.

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


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

  Changed paths:
    M docs/system/deprecated.rst
    M hw/intc/spapr_xive.c
    M hw/ppc/pnv_lpc.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_hcall.c
    M hw/ppc/spapr_nvdimm.c
    M hw/ppc/spapr_ovec.c
    M hw/ppc/spapr_rtas.c
    M hw/scsi/spapr_vscsi.c
    M hw/scsi/trace-events
    M hw/scsi/viosrp.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_cpu_core.h
    M include/hw/ppc/spapr_ovec.h
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF
    M target/ppc/cpu-qom.h
    M target/ppc/cpu.h
    M target/ppc/excp_helper.c
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/mmu-hash64.c
    M target/ppc/translate.c
    M target/ppc/translate_init.inc.c
    M tests/qtest/libqos/libqos-spapr.h

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

ppc patch queue 2020-03-17

Here's my final pull request for the qemu-5.0 soft freeze.  Sorry this
is just under the wire - I hit some last minute problems that took a
while to fix up and retest.

Highlights are:
 * Numerous fixes for the FWNMI feature
 * A handful of cleanups to the device tree construction code
 * Numerous fixes for the spapr-vscsi device
 * A number of fixes and cleanups for real mode (MMU off) softmmu
   handling
 * Fixes for handling of the PAPR RMA
 * Better handling of hotplug/unplug events during boot
 * Assorted other fixes

# gpg: Signature made Tue 17 Mar 2020 09:55:07 GMT
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>" [full]
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>" [full]
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>" 
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-5.0-20200317: (45 commits)
  pseries: Update SLOF firmware image
  ppc/spapr: Ignore common "ibm,nmi-interlock" Linux bug
  ppc/spapr: Implement FWNMI System Reset delivery
  target/ppc: allow ppc_cpu_do_system_reset to take an alternate vector
  ppc/spapr: Allow FWNMI on TCG
  ppc/spapr: Fix FWNMI machine check interrupt delivery
  ppc/spapr: Add FWNMI System Reset state
  ppc/spapr: Change FWNMI names
  ppc/spapr: Fix FWNMI machine check failure handling
  spapr: Rename DT functions to newer naming convention
  spapr: Move creation of ibm,architecture-vec-5 property
  spapr: Move creation of ibm,dynamic-reconfiguration-memory dt node
  spapr/rtas: Reserve space for RTAS blob and log
  pseries: Update SLOF firmware image
  ppc/spapr: Move GPRs setup to one place
  target/ppc: Fix rlwinm on ppc64
  spapr/xive: use SPAPR_IRQ_IPI to define IPI ranges exposed to the guest
  hw/scsi/spapr_vscsi: Convert debug fprintf() to trace event
  hw/scsi/spapr_vscsi: Prevent buffer overflow
  hw/scsi/spapr_vscsi: Do not mix SRP IU size with DMA buffer size
  ...

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


Compare: https://github.com/qemu/qemu/compare/d649689a8ecb...b319df553707