[Qemu-commits] [qemu/qemu] 14de3d: ppc/pnv: Make PSI device types not user creatable

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 14de3d4ac58c0f63e9f5560c7e01e62e39467edd
      
https://github.com/qemu/qemu/commit/14de3d4ac58c0f63e9f5560c7e01e62e39467edd
  Author: Greg Kurz <groug@kaod.org>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

  Changed paths:
    M hw/ppc/pnv_psi.c

  Log Message:
  -----------
  ppc/pnv: Make PSI device types not user creatable

QEMU aborts with -device pnv-psi-POWER8:

$ qemu-system-ppc64 -device pnv-psi-POWER8
qemu-system-ppc64: hw/intc/xics.c:605: ics_realize: Assertion
`ics->xics' failed.
Aborted (core dumped)

The Processor Service Interface Controller is an internal device.
It should only be instantiated by the chip, which takes care of
configuring the link required by the ICS object in the case of
POWER8. It doesn't make sense for a user to specify it on the
command line.

Note that the PSI model for POWER8 was added 3 yrs ago but the
devices weren't available on the command line because of a bug
that was fixed by recent commit 2f35254aa0 ("pnv/psi: Correct
the pnv-psi* devices not to be sysbus devices").

Fixes: 54f59d786c ("ppc/pnv: Add cut down PSI bridge model and hookup external 
interrupt")
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <159413975752.169116.5808968580649255382.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: a4beb5f5d4672400a76cc0551c4f0878e42d921c
      
https://github.com/qemu/qemu/commit/a4beb5f5d4672400a76cc0551c4f0878e42d921c
  Author: Greg Kurz <groug@kaod.org>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci: Robustify support of PCI bridges

Some recent error handling cleanups unveiled issues with our support of
PCI bridges:

1) QEMU aborts when using non-standard PCI bridge types,
   unveiled by commit 7ef1553dac "spapr_pci: Drop some dead error handling"

$ qemu-system-ppc64 -M pseries -device pcie-pci-bridge
Unexpected error in object_property_find() at qom/object.c:1240:
qemu-system-ppc64: -device pcie-pci-bridge: Property '.chassis_nr' not found
Aborted (core dumped)

This happens because we assume all PCI bridge types to have a "chassis_nr"
property. This property only exists with the standard PCI bridge type
"pci-bridge" actually. We could possibly revert 7ef1553dac but it seems
much simpler to check the presence of "chassis_nr" earlier.

2) QEMU abort if same "chassis_nr" value is used several times,
   unveiled by commit d2623129a7de "qom: Drop parameter @errp of
   object_property_add() & friends"

$ qemu-system-ppc64 -M pseries -device pci-bridge,chassis_nr=1 \
                        -device pci-bridge,chassis_nr=1
Unexpected error in object_property_try_add() at qom/object.c:1167:
qemu-system-ppc64: -device pci-bridge,chassis_nr=1: attempt to add duplicate 
property '40000100' to object (type 'container')
Aborted (core dumped)

This happens because we assume that "chassis_nr" values are unique, but
nobody enforces that and we end up generating duplicate DRC ids. The PCI
code doesn't really care for duplicate "chassis_nr" properties since it
is only used to initialize the "Chassis Number Register" of the bridge,
with no functional impact on QEMU. So, even if passing the same value
several times might look weird, it never broke anything before, so
I guess we don't necessarily want to enforce strict checking in the PCI
code now.

Workaround both issues in the PAPR code: check that the bridge has a
unique and non null "chassis_nr" when plugging it into its parent bus.

Fixes: 05929a6c5dfe ("spapr: Don't use bus number for building DRC ids")
Fixes: 7ef1553dac ("spapr_pci: Drop some dead error handling")
Fixes: d2623129a7de ("qom: Drop parameter @errp of object_property_add() & 
friends")
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <159431476748.407044.16711294833569014964.stgit@bahia.lan>
[dwg: Move check slightly to a better place]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: a6030d7e0b35a23c82e4a765b53dc3847bcdb4d1
      
https://github.com/qemu/qemu/commit/a6030d7e0b35a23c82e4a765b53dc3847bcdb4d1
  Author: Reza Arbab <arbab@linux.ibm.com>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

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

  Log Message:
  -----------
  spapr: Add a new level of NUMA for GPUs

NUMA nodes corresponding to GPU memory currently have the same
affinity/distance as normal memory nodes. Add a third NUMA associativity
reference point enabling us to give GPU nodes more distance.

This is guest visible information, which shouldn't change under a
running guest across migration between different qemu versions, so make
the change effective only in new (pseries > 5.0) machine types.

Before, `numactl -H` output in a guest with 4 GPUs (nodes 2-5):

node distances:
node   0   1   2   3   4   5
  0:  10  40  40  40  40  40
  1:  40  10  40  40  40  40
  2:  40  40  10  40  40  40
  3:  40  40  40  10  40  40
  4:  40  40  40  40  10  40
  5:  40  40  40  40  40  10

After:

node distances:
node   0   1   2   3   4   5
  0:  10  40  80  80  80  80
  1:  40  10  80  80  80  80
  2:  80  80  10  80  80  80
  3:  80  80  80  10  80  80
  4:  80  80  80  80  10  80
  5:  80  80  80  80  80  10

These are the same distances as on the host, mirroring the change made
to host firmware in skiboot commit f845a648b8cb ("numa/associativity:
Add a new level of NUMA for GPU's").

Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Message-Id: <20200716225655.24289-1-arbab@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: b25fbd6a1302c0eac5b326be3e1f828e905c0c9a
      
https://github.com/qemu/qemu/commit/b25fbd6a1302c0eac5b326be3e1f828e905c0c9a
  Author: Alexey Kardashevskiy <aik@ozlabs.ru>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

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

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

This adds tcgbios (this was posted earlier [1] but got lost)
and fixes FDT update at ibm,client-architecture-support
for huge guests.

The full list of changes:

Alexey Kardashevskiy (4):
      make: Define default rule for .c when V=1 or V=2
      version: update to 20200513
      fdt: Avoid recursion when traversing tree
      version: update to 20200717

Gustavo Romero (1):
      board-qemu: Fix comment about SLOF start address

Stefan Berger (6):
      tcgbios: Only write logs for PCRs that are allocated
      tcgbios: Fix the vendorInfoSize to be of type uint8_t
      tcgbios: Add support for SHA3 type of algorithms
      elf: Implement elf_get_file_size to determine size of an ELF image
      tcgbios: Implement tpm_hash_log_extend_event_buffer
      tcgbios: Measure the bootloader file read from disk

[1] 
https://patchwork.ozlabs.org/project/qemu-devel/patch/20200513024355.121476-1-aik@ozlabs.ru/

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 1e6c50ad8559c18b21041ef69d8fff781a8db0bb
      
https://github.com/qemu/qemu/commit/1e6c50ad8559c18b21041ef69d8fff781a8db0bb
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

  Changed paths:
    M hw/ppc/pnv_psi.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_pci_nvlink2.c
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/spapr.h
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF

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

ppc patch queue 20200720

Here are some assorted fixes for qemu-5.1:
 * SLOF update with improved TPM handling, and fix for possible stack
   overflows on many-vcpu machines
 * Fix for NUMA distances on NVLink2 attached GPU memory nodes
 * Fixes to fail more gracefully on attempting to plug unsupported PCI bridge 
types
 * Don't allow pnv-psi device to be user created

# gpg: Signature made Mon 20 Jul 2020 06:29:21 BST
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" 
[full]
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>" 
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-5.1-20200720:
  pseries: Update SLOF firmware image
  spapr: Add a new level of NUMA for GPUs
  spapr_pci: Robustify support of PCI bridges
  ppc/pnv: Make PSI device types not user creatable

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/873ec69aeb12...1e6c50ad8559