qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 58c46e: pseries: do not allow memory-less/cpu


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 58c46e: pseries: do not allow memory-less/cpu-less NUMA node
Date: Mon, 07 Oct 2019 07:40:22 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 58c46efa451caa3935224223f950216872e2eee3
      
https://github.com/qemu/qemu/commit/58c46efa451caa3935224223f950216872e2eee3
  Author: Laurent Vivier <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  pseries: do not allow memory-less/cpu-less NUMA node

When we hotplug a CPU on memory-less/cpu-less node, the linux kernel
crashes.

This happens because linux kernel needs to know the NUMA topology at
start to be able to initialize the distance lookup table.

On pseries, the topology is provided by the firmware via the existing
CPUs and memory information. Thus a node without memory and CPU cannot be
discovered by the kernel.

To avoid the kernel crash, do not allow to start pseries with empty
nodes.

Signed-off-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
[dwg: Rework to cope with movement of numa state from globals to MachineState]
Signed-off-by: David Gibson <address@hidden>


  Commit: f42b6f535c290046d10aebf1796fb46957dfa8e6
      
https://github.com/qemu/qemu/commit/f42b6f535c290046d10aebf1796fb46957dfa8e6
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/pnv_bmc.c

  Log Message:
  -----------
  ppc/pnv: fix "bmc" node name in DT

Fixes the dtc output :

ERROR (node_name_chars): //bmc: Bad character '/' in node name
Warning (avoid_unnecessary_addr_size): /bmc: unnecessary 
#address-cells/#size-cells without "ranges" or child "reg" property

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


  Commit: 226c9d15df0a9c9e94fc30c373cdefbc4156d8dd
      
https://github.com/qemu/qemu/commit/226c9d15df0a9c9e94fc30c373cdefbc4156d8dd
  Author: Greg Kurz <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_tpm_proxy.c

  Log Message:
  -----------
  spapr-tpm-proxy: Drop misleading check

Coverity is reporting in CID 1405304 that tpm_execute() may pass a NULL
tpm_proxy->host_path pointer to open(). This is based on the fact that
h_tpm_comm() does a NULL check on tpm_proxy->host_path and then passes
tpm_proxy to tpm_execute().

The check in h_tpm_comm() is abusive actually since a spapr-proxy-tpm
requires a non NULL host_path property, as checked during realize.

Fixes: 0fb6bd073230
Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael Roth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 59b7c1c283508ad5aa1c4064b17f8d368664029c
      
https://github.com/qemu/qemu/commit/59b7c1c283508ad5aa1c4064b17f8d368664029c
  Author: Balamuruhan S <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/pnv.c

  Log Message:
  -----------
  hw/ppc/pnv: fix checkpatch.pl coding style warnings

There were few trailing comments after `/*` instead in
new line and line more than 80 character, these fixes are
trivial and doesn't change any logic in code.

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


  Commit: f041d6af55708a75851bfc4ef1373a565703f976
      
https://github.com/qemu/qemu/commit/f041d6af55708a75851bfc4ef1373a565703f976
  Author: Greg Kurz <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Report kvm_irqchip_in_kernel() in 'info pic'

Unless the machine was started with kernel-irqchip=on, we cannot easily
tell if we're actually using an in-kernel or an emulated irqchip. This
information is important enough that it is worth printing it in 'info
pic'.

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


  Commit: 7454558c69b4fa4a9bb26d601b26330319b85f89
      
https://github.com/qemu/qemu/commit/7454558c69b4fa4a9bb26d601b26330319b85f89
  Author: Balamuruhan S <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/pnv_xscom.c
    M include/hw/ppc/pnv.h

  Log Message:
  -----------
  hw/ppc/pnv_xscom: retrieve homer/occ base address from PBA BARs

During PowerNV boot skiboot populates the device tree by
retrieving base address of homer/occ common area from
PBA BARs and prd ipoll mask by accessing xscom read/write
accesses.

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


  Commit: f3db82660d22def1ffaa122f3952b560ac386147
      
https://github.com/qemu/qemu/commit/f3db82660d22def1ffaa122f3952b560ac386147
  Author: Balamuruhan S <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/pnv.c
    M hw/ppc/pnv_occ.c
    M include/hw/ppc/pnv_occ.h

  Log Message:
  -----------
  hw/ppc/pnv_occ: add sram device model for occ common area

emulate occ common area region with occ sram device model which
occ and skiboot uses it to communicate regarding sensors, slw
and HWMON in PowerNV emulated host.

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


  Commit: 3887d241238c7b5960c7f153d2025891c5f5fc66
      
https://github.com/qemu/qemu/commit/3887d241238c7b5960c7f153d2025891c5f5fc66
  Author: Balamuruhan S <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/Makefile.objs
    M hw/ppc/pnv.c
    A hw/ppc/pnv_homer.c
    M include/hw/ppc/pnv.h
    A include/hw/ppc/pnv_homer.h

  Log Message:
  -----------
  hw/ppc/pnv_homer: add PowerNV homer device model

add PnvHomer device model to emulate homer memory access
for pstate table, occ-sensors, slw, occ static and dynamic
values for Power8 and Power9 chips.

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


  Commit: 4a99d40551d265e56584bfa6657d9a549e729127
      
https://github.com/qemu/qemu/commit/4a99d40551d265e56584bfa6657d9a549e729127
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  spapr/irq: Introduce an ics_irq_free() helper

It will help us to discard interrupt numbers which have not been
claimed in the next patch.

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: 4c3539d491026a0cc68e3b886f16cb7f57efd46b
      
https://github.com/qemu/qemu/commit/4c3539d491026a0cc68e3b886f16cb7f57efd46b
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/spapr_xive_kvm.c
    M hw/intc/xics_kvm.c

  Log Message:
  -----------
  spapr/irq: Only claim VALID interrupts at the KVM level

A typical pseries VM with 16 vCPUs, one disk, one network adapater
uses less than 100 interrupts but the whole IRQ number space of the
QEMU machine is allocated at reset time and it is 8K wide. This is
wasting a considerable amount of interrupt numbers in the global IRQ
space which has 1M interrupts per socket on a POWER9.

To optimise the HW resources, only request at the KVM level interrupts
which have been claimed by the guest. This will help to increase the
maximum number of VMs per system and also help supporting nested guests
using the XIVE interrupt mode.

Signed-off-by: Cédric Le Goater <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
[dwg: Folded in fix up from Greg Kurz]
Signed-off-by: David Gibson <address@hidden>


  Commit: a2735cf483814b1c0e5773eee4a52f8e32d438cf
      
https://github.com/qemu/qemu/commit/a2735cf483814b1c0e5773eee4a52f8e32d438cf
  Author: Paul A. Clarke <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/cpu.h
    M target/ppc/dfp_helper.c
    M target/ppc/internal.h
    M target/ppc/translate/fp-impl.inc.c
    M target/ppc/translate/fp-ops.inc.c

  Log Message:
  -----------
  ppc: Add support for 'mffscrn','mffscrni' instructions

ISA 3.0B added a set of Floating-Point Status and Control Register (FPSCR)
instructions: mffsce, mffscdrn, mffscdrni, mffscrn, mffscrni, mffsl.
This patch adds support for 'mffscrn' and 'mffscrni' instructions.

'mffscrn' and 'mffscrni' are similar to 'mffsl', except they do not return
the status bits (FI, FR, FPRF) and they also set the rounding mode in the
FPSCR.

On CPUs without support for 'mffscrn'/'mffscrni' (below ISA 3.0), the
instructions will execute identically to 'mffs'.

Signed-off-by: Paul A. Clarke <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: bc7a45ab88281bbced8ebe9fb87d518102b22519
      
https://github.com/qemu/qemu/commit/bc7a45ab88281bbced8ebe9fb87d518102b22519
  Author: Paul A. Clarke <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/translate/fp-impl.inc.c
    M target/ppc/translate/fp-ops.inc.c

  Log Message:
  -----------
  ppc: Add support for 'mffsce' instruction

ISA 3.0B added a set of Floating-Point Status and Control Register (FPSCR)
instructions: mffsce, mffscdrn, mffscdrni, mffscrn, mffscrni, mffsl.
This patch adds support for 'mffsce' instruction.

'mffsce' is identical to 'mffs', except that it also clears the exception
enable bits in the FPSCR.

On CPUs without support for 'mffsce' (below ISA 3.0), the
instruction will execute identically to 'mffs'.

Signed-off-by: Paul A. Clarke <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 5c94dd3806b6cd4a9540a818ee87c335804bdc38
      
https://github.com/qemu/qemu/commit/5c94dd3806b6cd4a9540a818ee87c335804bdc38
  Author: Paul A. Clarke <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c
    M target/ppc/fpu_helper.c

  Log Message:
  -----------
  ppc: Use FPSCR defines instead of constants

There are FPSCR-related defines in target/ppc/cpu.h which can be used in
place of constants and explicit shifts which arguably improve the code a
bit in places.

Signed-off-by: Paul A. Clarke <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 972bd57689f1e11311d86b290134ea2ed9c7c11e
      
https://github.com/qemu/qemu/commit/972bd57689f1e11311d86b290134ea2ed9c7c11e
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  ppc/kvm: Skip writing DPDES back when in run time state

On POWER8 systems the Directed Privileged Door-bell Exception State
register (DPDES) stores doorbell pending status, one bit per a thread
of a core, set by "msgsndp" instruction. The register is shared among
threads of the same core and KVM on POWER9 emulates it in a similar way
(POWER9 does not have DPDES).

DPDES is shared but QEMU assumes all SPRs are per thread so the only safe
way to write DPDES back to VCPU before running a guest is doing so
while all threads are pulled out of the guest so DPDES cannot change.
There is only one situation when this condition is met: incoming migration
when all threads are stopped. Otherwise any QEMU HMP/QMP command causing
kvm_arch_put_registers() (for example printing registers or dumping memory)
can clobber DPDES in a race with other vcpu threads.

This changes DPDES handling so it is not written to KVM at runtime.

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


  Commit: daa36379ce1a0a683562d40ca20f9b722ef595e1
      
https://github.com/qemu/qemu/commit/daa36379ce1a0a683562d40ca20f9b722ef595e1
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Simplify handling of pre ISA 3.0 guest workaround handling

Certain old guest versions don't understand the radix MMU introduced with
POWER ISA 3.0, but incorrectly select it if presented with the option at
CAS time.  We workaround this in qemu by explicitly excluding the radix
(and other ISA 3.0 linked) options if the guest doesn't explicitly note
support for ISA 3.0.

This is handled by the 'cas_legacy_guest_workaround' flag, which is pretty
vague.  Rename it to 'cas_pre_isa3_guest' to be clearer about what it's for.

In addition, we unnecessarily call spapr_populate_pa_features() with
different options when initially constructing the device tree and when
adjusting it at CAS time.  At the initial construct time cas_pre_isa3_guest
is already false, so we can still use the flag, rather than explicitly
overriding it to be false at the callsite.

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


  Commit: db5127b28ae1113bbc10f843d1cd219dc90a52d1
      
https://github.com/qemu/qemu/commit/db5127b28ae1113bbc10f843d1cd219dc90a52d1
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Move handling of special NVLink numa node from reset to init

The number of NUMA nodes in the system is fixed from the command line.
Therefore, there's no need to recalculate it at reset time, and we can
determine the special gpu_numa_id value used for NVLink2 devices at init
time.

This simplifies the reset path a bit which will make further improvements
easier.

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


  Commit: f767b1ac5766fcc48cc3939eeb7db7b95b98408b
      
https://github.com/qemu/qemu/commit/f767b1ac5766fcc48cc3939eeb7db7b95b98408b
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Fixes a leak in CAS

Add a missing g_free(fdt) if the resulting tree is bigger
than the space allocated by SLOF.

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


  Commit: 3a17e38f6eac0028f2e4ca052455b38a4048c85d
      
https://github.com/qemu/qemu/commit/3a17e38f6eac0028f2e4ca052455b38a4048c85d
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Skip leading zeroes from memory@ DT node names

The device tree build by QEMU at the machine reset time is used by SLOF
to build its internal device tree but the node names are not preserved
exactly so when QEMU provides a device tree update in response to H_CAS,
it might become tricky to match a node from the update blob to
the actual node in SLOF.

This removed leading zeroes from "memory@" nodes and makes
the DTC checker happy.

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


  Commit: 5ced78955fe3f74002ad27676cf7c65cc89d6660
      
https://github.com/qemu/qemu/commit/5ced78955fe3f74002ad27676cf7c65cc89d6660
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Do not put empty properties for -kernel/-initrd/-append

We are going to use spapr_build_fdt() for the boot time FDT and as an
update for SLOF during handling of H_CAS. SLOF will apply all properties
from the QEMU's FDT which is usually ok unless there are properties
changed by grub or guest kernel. The properties are:
bootargs, linux,initrd-start, linux,initrd-end, linux,stdout-path,
linux,rtas-base, linux,rtas-entry. Resetting those during CAS will most
likely cause grub failure.

Don't create such properties if we're booting without "-kernel" and
"-initrd" so they won't get included into the DT update blob and
therefore the guest is more likely to boot successfully.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
[dwg: Tweaked commit message based on Greg Kurz's input]
Signed-off-by: David Gibson <address@hidden>


  Commit: 744a928ccee92482385f58e835108aa6ebd54ecb
      
https://github.com/qemu/qemu/commit/744a928ccee92482385f58e835108aa6ebd54ecb
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M MAINTAINERS
    M Makefile
    M configure
    M hw/ppc/spapr.c
    M hw/ppc/spapr_rtas.c
    M include/hw/ppc/spapr.h
    R pc-bios/spapr-rtas.bin
    R pc-bios/spapr-rtas/Makefile
    R pc-bios/spapr-rtas/spapr-rtas.S

  Log Message:
  -----------
  spapr: Stop providing RTAS blob

SLOF implements one itself so let's remove it from QEMU. It is one less
image and simpler setup as the RTAS blob never stays in its initial place
anyway as the guest OS always decides where to put it.

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


  Commit: 85164ad4ed9960cac842fa4cc067c6b6699b0994
      
https://github.com/qemu/qemu/commit/85164ad4ed9960cac842fa4cc067c6b6699b0994
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

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

This fixes USB host bus adapter name in the device tree to match QEMU's
one.

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


  Commit: 6a8fbb9bdb7c06b2a73085fd846e22cd3b65242d
      
https://github.com/qemu/qemu/commit/6a8fbb9bdb7c06b2a73085fd846e22cd3b65242d
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: introduce get_dfp{64,128}() helper functions

The existing functions (now incorrectly) assume that the MSB and LSB of DFP
numbers are stored as consecutive 64-bit words in memory. Instead of accessing
the DFP numbers directly, introduce get_dfp{64,128}() helper functions to ease
the switch to the correct representation.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 33432d7737b53c92791f90ece5dbe3b7bb1c79f5
      
https://github.com/qemu/qemu/commit/33432d7737b53c92791f90ece5dbe3b7bb1c79f5
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: introduce set_dfp{64,128}() helper functions

The existing functions (now incorrectly) assume that the MSB and LSB of DFP
numbers are stored as consecutive 64-bit words in memory. Instead of accessing
the DFP numbers directly, introduce set_dfp{64,128}() helper functions to ease
the switch to the correct representation.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d9acba3130314e2e4239d39a99eeca147c255584
      
https://github.com/qemu/qemu/commit/d9acba3130314e2e4239d39a99eeca147c255584
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/cpu.h
    M target/ppc/dfp_helper.c
    M target/ppc/helper.h

  Log Message:
  -----------
  target/ppc: update {get,set}_dfp{64,128}() helper functions to read/write DFP 
numbers correctly

Since commit ef96e3ae96 "target/ppc: move FP and VMX registers into aligned vsr
register array" FP registers are no longer stored consecutively in memory and so
the current method of combining FP register pairs into DFP numbers is incorrect.

Firstly update the definition of the dh_*_fprp defines in helper.h to reflect
that FP registers are now stored as part of an array of ppc_vsr_t elements
rather than plain uint64_t elements, and then introduce a new ppc_fprp_t type
which conceptually represents a DFP even-odd register pair to be consumed by the
DFP helper functions.

Finally update the new DFP {get,set}_dfp{64,128}() helper functions to convert
between DFP numbers and DFP even-odd register pairs correctly, making use of the
existing VsrD() macro to access the correct elements regardless of host endian.

Fixes: ef96e3ae96 "target/ppc: move FP and VMX registers into aligned vsr 
register array"
Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 474c2e931d51bad00c20c65d6fe478a9391e5e2a
      
https://github.com/qemu/qemu/commit/474c2e931d51bad00c20c65d6fe478a9391e5e2a
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: introduce dfp_finalize_decimal{64,128}() helper functions

Most of the DFP helper functions call decimal{64,128}FromNumber() just before
returning in order to convert the decNumber stored in dfp.t64 back to a
Decimal{64,128} to write back to the FP registers.

Introduce new dfp_finalize_decimal{64,128}() helper functions which both enable
the parameter list to be reduced considerably, and also help minimise the
changes required in the next patch.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 64b8574e143f2287009ad77a12b87e64516a0711
      
https://github.com/qemu/qemu/commit/64b8574e143f2287009ad77a12b87e64516a0711
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: change struct PPC_DFP decimal storage from uint64[2] to ppc_vsr_t

There are several places in dfp_helper.c that access the decimal number
representations in struct PPC_DFP via HI_IDX and LO_IDX defines which are set
at the top of dfp_helper.c according to the host endian.

However we can instead switch to using ppc_vsr_t for decimal numbers and then
make subsequent use of the existing VsrD() macros to access the correct
element regardless of host endian. Note that 64-bit decimals are stored in the
LSB of ppc_vsr_t (equivalent to VsrD(1)).

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 1ea80bf7f4398099b6818f574cda8b4089c62340
      
https://github.com/qemu/qemu/commit/1ea80bf7f4398099b6818f574cda8b4089c62340
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: use existing VsrD() macro to eliminate HI_IDX and LO_IDX from 
dfp_helper.c

Switch over all accesses to the decimal numbers held in struct PPC_DFP from
using HI_IDX and LO_IDX to using the VsrD() macro instead. Not only does this
allow the compiler to ensure that the various dfp_* functions are being passed
a ppc_vsr_t rather than an arbitrary uint64_t pointer, but also allows the
host endian-specific HI_IDX and LO_IDX to be completely removed from
dfp_helper.c.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: f6d4c423a222f02bfa84a49c3d306d7341ec9bab
      
https://github.com/qemu/qemu/commit/f6d4c423a222f02bfa84a49c3d306d7341ec9bab
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/dfp_helper.c

  Log Message:
  -----------
  target/ppc: remove unnecessary if() around calls to set_dfp{64,128}() in DFP 
macros

Now that the parameters to both set_dfp64() and set_dfp128() are exactly the
same, there is no need for an explicit if() statement to determine which
function should be called based upon size. Instead we can simply use the
preprocessor to generate the call to set_dfp##size() directly.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: c4ec08ab70bab90685d1443d6da47293e3aa312a
      
https://github.com/qemu/qemu/commit/c4ec08ab70bab90685d1443d6da47293e3aa312a
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr-pci: Stop providing assigned-addresses

QEMU does not allocate PCI resources (BARs) in any case - coldplug devices
are configured by the firmware and hotplug devices rely on the guest
system to do the assignment via the PCI rescan mechanism. Also in order
to create non empty "assigned-addresses", the device has to be enabled
(i.e. PCI_COMMAND needs the MMIO bit set) first as otherwise
io_regions[i].addr are -1, and devices are not enabled at this point.

This removes "assigned-addresses" and leaves it to those who actually
do resource allocation.

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


  Commit: e68cd0cb5cf49d334abe17231a1d2c28b846afa2
      
https://github.com/qemu/qemu/commit/e68cd0cb5cf49d334abe17231a1d2c28b846afa2
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Render full FDT on ibm,client-architecture-support

The ibm,client-architecture-support call is a way for the guest to
negotiate capabilities with a hypervisor. It is implemented as:
- the guest calls SLOF via client interface;
- SLOF calls QEMU (H_CAS hypercall) with an options vector from the guest;
- QEMU returns a device tree diff (which uses FDT format with
an additional header before it);
- SLOF walks through the partial diff tree and updates its internal tree
with the values from the diff.

This changes QEMU to simply re-render the entire tree and send it as
an update. SLOF can handle this already mostly, [1] is needed before this
can be applied. This stores the resulting tree in the spapr machine to have
the latest valid FDT copy possible (this should not matter much as
H_UPDATE_DT happens right after that but nevertheless).

The benefit is reduced code size as there is no need for another set of
DT rendering helpers such as spapr_fixup_cpu_dt().

The downside is that the updates are bigger now (as they include all
nodes and properties) but the difference on a '-smp 256,threads=1' system
before/after is 2.35s vs. 2.5s.

[1] https://patchwork.ozlabs.org/patch/1152915/

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


  Commit: 428115c3a9d0f64e1b9189986dbba4be0548c4a5
      
https://github.com/qemu/qemu/commit/428115c3a9d0f64e1b9189986dbba4be0548c4a5
  Author: Mark Cave-Ayland <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M target/ppc/int_helper.c

  Log Message:
  -----------
  target/ppc: use Vsr macros in BCD helpers

This allows us to remove more endian-specific defines from int_helper.c.

Signed-off-by: Mark Cave-Ayland <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>


  Commit: 627fa61746f70f7c799f08e9048bb6a482402138
      
https://github.com/qemu/qemu/commit/627fa61746f70f7c799f08e9048bb6a482402138
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/xive.c

  Log Message:
  -----------
  spapr/xive: skip partially initialized vCPUs in presenter

When vCPUs are hotplugged, they are added to the QEMU CPU list before
being fully realized. This can crash the XIVE presenter because the
'tctx' pointer is not necessarily initialized when looking for a
matching target.

These vCPUs are not valid targets for the presenter. Skip them.

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


  Commit: 00ed3da9b5c2e66e796a172df3e19545462b9c90
      
https://github.com/qemu/qemu/commit/00ed3da9b5c2e66e796a172df3e19545462b9c90
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  xics: Minor fixes for XICSFabric interface

Interface instances should never be directly dereferenced.  So, the common
practice is to make them incomplete types to make sure no-one does that.
XICSFrabric, however, had a dummy type which is less safe.

We were also using OBJECT_CHECK() where we should have been using
INTERFACE_CHECK().

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


  Commit: d5803c7319f5cc79afda066e2c8b9c61436b43df
      
https://github.com/qemu/qemu/commit/d5803c7319f5cc79afda066e2c8b9c61436b43df
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  xics: Eliminate 'reject', 'resend' and 'eoi' class hooks

Currently ics_reject(), ics_resend() and ics_eoi() indirect through
class methods.  But there's only one implementation of each method,
the one in TYPE_ICS_SIMPLE.  TYPE_ICS_BASE has no implementation, but
it's never instantiated, and has no other subtypes.

So clean up by eliminating the method and just having ics_reject(),
ics_resend() and ics_eoi() contain the logic directly.

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


  Commit: 28976c99cfa59e1880a86a59af20099eba62f5e7
      
https://github.com/qemu/qemu/commit/28976c99cfa59e1880a86a59af20099eba62f5e7
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/trace-events
    M hw/intc/xics.c
    M hw/intc/xics_spapr.c
    M hw/ppc/pnv_psi.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  xics: Rename misleading ics_simple_*() functions

There are a number of ics_simple_*() functions that aren't actually
specific to TYPE_XICS_SIMPLE at all, and are equally valid on
TYPE_XICS_BASE.  Rename them to ics_*() accordingly.

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


  Commit: da2ef5b2f24be70d4fa0b05fd6799031cd3a456e
      
https://github.com/qemu/qemu/commit/da2ef5b2f24be70d4fa0b05fd6799031cd3a456e
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/xics.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  xics: Eliminate reset hook

Currently TYPE_XICS_BASE and TYPE_XICS_SIMPLE have their own reset methods,
using the standard technique for having the subtype call the supertype's
methods before doing its own thing.

But TYPE_XICS_SIMPLE is the only subtype of TYPE_XICS_BASE ever
instantiated, so there's no point having the split here.  Merge them
together into just an ics_reset() function.

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


  Commit: 642e92719e2790dfa0e12be1cfd822a0ff2322aa
      
https://github.com/qemu/qemu/commit/642e92719e2790dfa0e12be1cfd822a0ff2322aa
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/xics.c
    M hw/ppc/pnv_psi.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  xics: Merge TYPE_ICS_BASE and TYPE_ICS_SIMPLE classes

TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
instantiated.  The existence of different classes is mostly a hang
over from when we (misguidedly) had separate subtypes for the KVM and
non-KVM version of the device.

There could be some call for an abstract base type for ICS variants
that use a different representation of their state (PowerNV PHB3 might
want this).  The current split isn't really in the right place for
that though.  If we need this in future, we can re-implement it more
in line with what we actually need.

So, collapse the two classes together into just TYPE_ICS.

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


  Commit: 9db8c551c98c285bad2ed19ce28a721d33c20d2f
      
https://github.com/qemu/qemu/commit/9db8c551c98c285bad2ed19ce28a721d33c20d2f
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/xics_spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/xics_spapr.h

  Log Message:
  -----------
  xics: Create sPAPR specific ICS subtype

We create a subtype of TYPE_ICS specifically for sPAPR.  For now all this
does is move the setup of the PAPR specific hcalls and RTAS calls to
the realize() function for this, rather than requiring the PAPR code to
explicitly call xics_spapr_init().  In future it will have some more
function.

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


  Commit: 258aa5ce1c62bf9cf28dc344f52e13ea3a0a38cd
      
https://github.com/qemu/qemu/commit/258aa5ce1c62bf9cf28dc344f52e13ea3a0a38cd
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Fold spapr_phb_lsi_qirq() into its single caller

No point having a two-line helper that's used exactly once, and not likely
to be used anywhere else in future.

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: 7678b74a94a70186da3b3971d7ae92ca1a81c969
      
https://github.com/qemu/qemu/commit/7678b74a94a70186da3b3971d7ae92ca1a81c969
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/char/spapr_vty.c
    M hw/net/spapr_llan.c
    M hw/ppc/spapr_vio.c
    M include/hw/ppc/spapr_vio.h

  Log Message:
  -----------
  spapr: Replace spapr_vio_qirq() helper with spapr_vio_irq_pulse() helper

Every caller of spapr_vio_qirq() immediately calls qemu_irq_pulse() with
the result, so we might as well just fold that into the helper.

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: ad8de98636e7cadeb1be4efa997cfe2a60bd5c30
      
https://github.com/qemu/qemu/commit/ad8de98636e7cadeb1be4efa997cfe2a60bd5c30
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Clarify and fix handling of nr_irqs

Both the XICS and XIVE interrupt backends have a "nr-irqs" property, but
it means slightly different things.  For XICS (or, strictly, the ICS) it
indicates the number of "real" external IRQs.  Those start at XICS_IRQ_BASE
(0x1000) and don't include the special IPI vector.  For XIVE, however, it
includes the whole IRQ space, including XIVE's many IPI vectors.

The spapr code currently doesn't handle this sensibly, with the
nr_irqs value in SpaprIrq having different meanings depending on the
backend.  We fix this by renaming nr_irqs to nr_xirqs and making it
always indicate just the number of external irqs, adjusting the value
we pass to XIVE accordingly.  We also move to using common constants
in most of the irq configurations, to make it clearer that the IRQ
space looks the same to the guest (and emulated devices), even if the
backend is different.

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


  Commit: fe9b61b2468a6de170ae0e9afe92fa1daa7ab48b
      
https://github.com/qemu/qemu/commit/fe9b61b2468a6de170ae0e9afe92fa1daa7ab48b
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Eliminate nr_irqs parameter to SpaprIrq::init

The only reason this parameter was needed was to work around the
inconsistent meaning of nr_irqs between xics and xive.  Now that we've
fixed that, we can consistently use the number directly in the SpaprIrq
configuration.

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


  Commit: 9f53c0db19605f76324fb09af23d30e181a06211
      
https://github.com/qemu/qemu/commit/9f53c0db19605f76324fb09af23d30e181a06211
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr: Fix indexing of XICS irqs

spapr global irq numbers are different from the source numbers on the ICS
when using XICS - they're offset by XICS_IRQ_BASE (0x1000).  But
spapr_irq_set_irq_xics() was passing through the global irq number to
the ICS code unmodified.

We only got away with this because of a counteracting bug - we were
incorrectly adjusting the qemu_irq we returned for a requested global irq
number.

That approach mostly worked but is very confusing, incorrectly relies on
the way the qemu_irq array is allocated, and undermines the intention of
having the global array of qemu_irqs for spapr have a consistent meaning
regardless of irq backend.

So, fix both set_irq and qemu_irq indexing.  We rename some parameters at
the same time to make it clear that they are referring to spapr global
irq numbers.

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


  Commit: af1861511d3853664e5362ea3d2eb14b1f8d05b4
      
https://github.com/qemu/qemu/commit/af1861511d3853664e5362ea3d2eb14b1f8d05b4
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Simplify spapr_qirq() handling

Currently spapr_qirq(), whic is used to find the qemu_irq for an spapr
global irq number, redirects through the SpaprIrq::qirq method.  But
the array of qemu_irqs is allocated in the PAPR layer, not the
backends, and so the method implementations all return the same thing,
just differing in the preliminary checks they make.

So, we can remove the method, and just implement spapr_qirq() directly,
including all the relevant checks in one place.  We change all those
checks into assert()s as well, since a failure here indicates an error in
the calling code.

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: 14789694cd1ba57b1d548451b8b7630e888d679f
      
https://github.com/qemu/qemu/commit/14789694cd1ba57b1d548451b8b7630e888d679f
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/xics_spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h
    M include/hw/ppc/xics_spapr.h

  Log Message:
  -----------
  spapr: Eliminate SpaprIrq:get_nodename method

This method is used to determine the name of the irq backend's node in the
device tree, so that we can find its phandle (after SLOF may have modified
it from the phandle we initially gave it).

But, in the two cases the only difference between the node name is the
presence of a unit address.  Searching for a node name without considering
unit address is standard practice for the device tree, and
fdt_subnode_offset() will do exactly that, making this method unecessary.

While we're there, remove the XICS_NODENAME define.  The name
"interrupt-controller" is required by PAPR (and IEEE1275), and a bunch of
places assume it already.

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


  Commit: 85d0425652a5117164d716a284df5aa22ddf44fe
      
https://github.com/qemu/qemu/commit/85d0425652a5117164d716a284df5aa22ddf44fe
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c
    M hw/ppc/trace-events

  Log Message:
  -----------
  spapr: Remove unhelpful tracepoints from spapr_irq_free_xics()

These traces contain some useless information (the always-0 source#) and
have no equivalents for XIVE mode.  For now just remove them, and we can
put back something more sensible if and when we need 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: f233cee97bfbab24517171ef5a56d8a54d8a96ef
      
https://github.com/qemu/qemu/commit/f233cee97bfbab24517171ef5a56d8a54d8a96ef
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Handle freeing of multiple irqs in frontend only

spapr_irq_free() can be used to free multiple irqs at once. That's useful
for its callers, but there's no need to make the individual backend hooks
handle this.  We can loop across the irqs in spapr_irq_free() itself and
have the hooks just do one at time.

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


  Commit: 580dde5e4a4597be26cb948a711727c2a406f158
      
https://github.com/qemu/qemu/commit/580dde5e4a4597be26cb948a711727c2a406f158
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/spapr_xive.c
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr, xics, xive: Better use of assert()s on irq claim/free paths

The irq claim and free paths for both XICS and XIVE check for some
validity conditions.  Some of these represent genuine runtime failures,
however others - particularly checking that the basic irq number is in a
sane range - could only fail in the case of bugs in the callin code.
Therefore use assert()s instead of runtime failures for those.

In addition the non backend-specific part of the claim/free paths should
only be used for PAPR external irqs, that is in the range SPAPR_XIRQ_BASE
to the maximum irq number.  Put assert()s for that into the top level
dispatchers as well.

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


  Commit: e594c2ad1c3207ff308449203fd5abc002ac89c9
      
https://github.com/qemu/qemu/commit/e594c2ad1c3207ff308449203fd5abc002ac89c9
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/intc/spapr_xive.c
    M hw/intc/spapr_xive_kvm.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_xive.h
    M include/hw/ppc/xive.h

  Log Message:
  -----------
  xive: Improve irq claim/free path

spapr_xive_irq_claim() returns a bool to indicate if it succeeded.
But most of the callers and one callee use int return values and/or an
Error * with more information instead.  In any case, ints are a more
common idiom for success/failure states than bools (one never knows
what sense they'll be in).

So instead change to an int return value to indicate presence of error
+ an Error * to describe the details through that call chain.

It also didn't actually check if the irq was already claimed, which is
one of the primary purposes of the claim path, so do that.

spapr_xive_irq_free() also returned a bool... which no callers checked
and was always true, so just drop it.

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


  Commit: ca62823b79443e3f498c6e6b9fea5f8bbe61033e
      
https://github.com/qemu/qemu/commit/ca62823b79443e3f498c6e6b9fea5f8bbe61033e
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Use less cryptic representation of which irq backends are supported

SpaprIrq::ov5 stores the value for a particular byte in PAPR option vector
5 which indicates whether XICS, XIVE or both interrupt controllers are
available.  As usual for PAPR, the encoding is kind of overly complicated
and confusing (though to be fair there are some backwards compat things it
has to handle).

But to make our internal code clearer, have SpaprIrq encode more directly
which backends are available as two booleans, and derive the OV5 value from
that at the point we need it.

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


  Commit: 0a3fd3df6f6a9b318909ab8400172d2d5a42abf9
      
https://github.com/qemu/qemu/commit/0a3fd3df6f6a9b318909ab8400172d2d5a42abf9
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr: Add return value to spapr_irq_check()

Explicitly return success or failure, rather than just relying on the
Error ** parameter.  This makes handling it less verbose in the caller.

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


  Commit: f478d9af213f169449f7aaba7257aba1a4032e1e
      
https://github.com/qemu/qemu/commit/f478d9af213f169449f7aaba7257aba1a4032e1e
  Author: David Gibson <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

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

  Log Message:
  -----------
  spapr: Eliminate SpaprIrq::init hook

This method is used to set up the interrupt backends for the current
configuration.  However, this means some confusing redirection between
the "dual" mode init and the init hooks for xics only and xive only modes.

Since we now have simple flags indicating whether XICS and/or XIVE are
supported, it's easier to just open code each initialization directly in
spapr_irq_init().  This will also make some future cleanups simpler.

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


  Commit: 1aba8716c8335e88b8c358002a6e1ac89f7dd258
      
https://github.com/qemu/qemu/commit/1aba8716c8335e88b8c358002a6e1ac89f7dd258
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M hw/ppc/pnv.c

  Log Message:
  -----------
  ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine

The POWER8 PowerNV machine needs to implement a XICSFabric interface
as this is the POWER8 interrupt controller model. But the POWER9
machine uselessly inherits of XICSFabric from the common PowerNV
machine definition.

Open code machine definitions to have a better control on the
different interfaces each machine should define.

Fixes: f30c843ced50 ("ppc/pnv: Introduce PowerNV machines with fixed CPU 
models")
Signed-off-by: Cédric Le Goater <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0f0b43868a566068fc137632fd51bd3cbb23f350
      
https://github.com/qemu/qemu/commit/0f0b43868a566068fc137632fd51bd3cbb23f350
  Author: Peter Maydell <address@hidden>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M MAINTAINERS
    M Makefile
    M configure
    M hw/char/spapr_vty.c
    M hw/intc/spapr_xive.c
    M hw/intc/spapr_xive_kvm.c
    M hw/intc/trace-events
    M hw/intc/xics.c
    M hw/intc/xics_kvm.c
    M hw/intc/xics_spapr.c
    M hw/intc/xive.c
    M hw/net/spapr_llan.c
    M hw/ppc/Makefile.objs
    M hw/ppc/pnv.c
    M hw/ppc/pnv_bmc.c
    A hw/ppc/pnv_homer.c
    M hw/ppc/pnv_occ.c
    M hw/ppc/pnv_psi.c
    M hw/ppc/pnv_xscom.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_hcall.c
    M hw/ppc/spapr_irq.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_rtas.c
    M hw/ppc/spapr_tpm_proxy.c
    M hw/ppc/spapr_vio.c
    M hw/ppc/trace-events
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/pnv.h
    A include/hw/ppc/pnv_homer.h
    M include/hw/ppc/pnv_occ.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_irq.h
    M include/hw/ppc/spapr_vio.h
    M include/hw/ppc/spapr_xive.h
    M include/hw/ppc/xics.h
    M include/hw/ppc/xics_spapr.h
    M include/hw/ppc/xive.h
    M pc-bios/README
    M pc-bios/slof.bin
    R pc-bios/spapr-rtas.bin
    R pc-bios/spapr-rtas/Makefile
    R pc-bios/spapr-rtas/spapr-rtas.S
    M roms/SLOF
    M target/ppc/cpu.h
    M target/ppc/dfp_helper.c
    M target/ppc/fpu_helper.c
    M target/ppc/helper.h
    M target/ppc/int_helper.c
    M target/ppc/internal.h
    M target/ppc/kvm.c
    M target/ppc/translate/fp-impl.inc.c
    M target/ppc/translate/fp-ops.inc.c
    M target/ppc/translate_init.inc.c

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

ppc patch queue 2019-10-04

Here's the next batch of ppc and spapr patches.  Includes:
  * Fist part of a large cleanup to irq infrastructure
  * Recreate the full FDT at CAS time, instead of making a difficult
    to follow set of updates.  This will help us move towards
    eliminating CAS reboots altogether
  * No longer provide RTAS blob to SLOF - SLOF can include it just as
    well itself, since guests will generally need to relocate it with
    a call to instantiate-rtas
  * A number of DFP fixes and cleanups from Mark Cave-Ayland
  * Assorted bugfixes
  * Several new small devices for powernv

# gpg: Signature made Fri 04 Oct 2019 10:35:57 BST
# 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-4.2-20191004: (53 commits)
  ppc/pnv: Remove the XICSFabric Interface from the POWER9 machine
  spapr: Eliminate SpaprIrq::init hook
  spapr: Add return value to spapr_irq_check()
  spapr: Use less cryptic representation of which irq backends are supported
  xive: Improve irq claim/free path
  spapr, xics, xive: Better use of assert()s on irq claim/free paths
  spapr: Handle freeing of multiple irqs in frontend only
  spapr: Remove unhelpful tracepoints from spapr_irq_free_xics()
  spapr: Eliminate SpaprIrq:get_nodename method
  spapr: Simplify spapr_qirq() handling
  spapr: Fix indexing of XICS irqs
  spapr: Eliminate nr_irqs parameter to SpaprIrq::init
  spapr: Clarify and fix handling of nr_irqs
  spapr: Replace spapr_vio_qirq() helper with spapr_vio_irq_pulse() helper
  spapr: Fold spapr_phb_lsi_qirq() into its single caller
  xics: Create sPAPR specific ICS subtype
  xics: Merge TYPE_ICS_BASE and TYPE_ICS_SIMPLE classes
  xics: Eliminate reset hook
  xics: Rename misleading ics_simple_*() functions
  xics: Eliminate 'reject', 'resend' and 'eoi' class hooks
  ...

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


Compare: https://github.com/qemu/qemu/compare/9e5319ca52a5...0f0b43868a56



reply via email to

[Prev in Thread] Current Thread [Next in Thread]