qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 702829: spapr_pci: Improve error message


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 702829: spapr_pci: Improve error message
Date: Wed, 12 Jun 2019 08:39:58 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 70282930173797afed352b82b4710233948c7495
      
https://github.com/qemu/qemu/commit/70282930173797afed352b82b4710233948c7495
  Author: Greg Kurz <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci: Improve error message

Every PHB must have a unique index. This is checked at realize but when
a duplicate index is detected, an error message mentioning BUIDs is
printed. This doesn't help much, especially since BUID is an internal
concept that is no longer exposed to the user.

Fix the message to mention the index property instead of BUID. As a bonus
print a list of indexes already in use.

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


  Commit: 2a1224359008e23b051b7b45be4789afa0269f8c
      
https://github.com/qemu/qemu/commit/2a1224359008e23b051b7b45be4789afa0269f8c
  Author: Anton Blanchard <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

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

  Log Message:
  -----------
  target/ppc: Fix lxvw4x, lxvh8x and lxvb16x

During the conversion these instructions were incorrectly treated as
stores. We need to use set_cpu_vsr* and not get_cpu_vsr*.

Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() 
helpers for VSR register access")
Signed-off-by: Anton Blanchard <address@hidden>
Reviewed-by: Mark Cave-Ayland <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 4782a8bb81f6d3ac815fb0f603daae4e6030dfa1
      
https://github.com/qemu/qemu/commit/4782a8bb81f6d3ac815fb0f603daae4e6030dfa1
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Clean up device node name generation for PCI devices

spapr_populate_pci_child_dt() adds a 'name' property to the device tree
node for PCI devices.  This is never necessary for a flattened device tree,
it is implicit in the name added when the node is constructed.  In fact
anything we do add to a 'name' property will be overwritten with something
derived from the structural name in the guest firmware (but in fact it is
exactly the same bytes).

So, remove that.  In addition, pci_get_node_name() is very simple, so fold
it into its (also simple) sole caller spapr_create_pci_child_dt().

While we're there rename pci_find_device_name() to the shorter and more
accurate dt_name_from_class().

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: 9d2134d81d40a1b2a4956e173fa228207bfffbbc
      
https://github.com/qemu/qemu/commit/9d2134d81d40a1b2a4956e173fa228207bfffbbc
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Clean up device tree construction for PCI devices

spapr_create_pci_child_dt() is a trivial wrapper around
spapr_populate_pci_child_dt(), but is the latter's only caller.  So fold
them together into spapr_dt_pci_device(), which closer matches our modern
naming convention.

While there, make a number of cleanups to the function itself.  This is
mostly using more temporary locals to avoid awkwardly long lines, and in
some cases avoiding double reads of PCI config space variables.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: 466e88318596a2b9e4df60ad00357f6a4dc648b0
      
https://github.com/qemu/qemu/commit/466e88318596a2b9e4df60ad00357f6a4dc648b0
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

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

  Log Message:
  -----------
  spapr: Clean up dt creation for PCI buses

Device nodes for PCI bridges (both host and P2P) describe both the bridge
device itself and the bus hanging off it, handling of this is a bit of a
mess.

spapr_dt_pci_device() has a few things it only adds for non-bridges, but
always adds #address-cells and #size-cells which should only appear for
bridges.  But the walking down the subordinate PCI bus is done in one of
its callers spapr_populate_pci_devices_dt().  The PHB dt creation in
spapr_populate_pci_dt() open codes some similar logic to the bridge case.

This patch consolidates things in a bunch of ways:
 * Bus specific dt info is now created in spapr_dt_pci_bus() used for both
   P2P bridges and the host bridge.  This includes walking subordinate
   devices
 * spapr_dt_pci_device() now calls spapr_dt_pci_bus() when called on a
   P2P bridge
 * We do detection of bridges with the is_bridge field of the device class,
   rather than checking PCI config space directly, for consistency with
   qemu's core PCI code.
 * Several things are renamed for brevity and clarity

Signed-off-by: David Gibson <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: 9e7d38e8a304c1b5a03334f3f41cbe157da6b2ad
      
https://github.com/qemu/qemu/commit/9e7d38e8a304c1b5a03334f3f41cbe157da6b2ad
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

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

  Log Message:
  -----------
  spapr: Clean up spapr_drc_populate_dt()

This makes some minor cleanups to spapr_drc_populate_dt(), renaming it to
the shorter and more idiomatic spapr_dt_drc() along the way.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: a1ec25b287dd64bdb782061168f8e34552102d48
      
https://github.com/qemu/qemu/commit/a1ec25b287dd64bdb782061168f8e34552102d48
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Clean up DRC index construction

spapr_pci.c currently has several confusingly similarly named functions for
various conversions between representations of DRCs.  Make things clearer
by renaming things in a more consistent XXX_from_YYY() manner and remove
some called-only-once variants in favour of open coding.

While we're at it, move this code together in the file to avoid some extra
forward references, and split out construction and removal of DRCs for the
host bridge into helper functions.

Signed-off-by: David Gibson <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: 05929a6c5dfe1028ef66250b7bbf11939f8e77cd
      
https://github.com/qemu/qemu/commit/05929a6c5dfe1028ef66250b7bbf11939f8e77cd
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Don't use bus number for building DRC ids

DRC ids are more or less arbitrary, as long as they're consistent.  For
PCI, we notionally build them from the phb's index along with PCI bus
number, slot and function number.

Using bus number is broken, however, because it can change if the guest
re-enumerates the PCI topology for whatever reason (e.g. due to hotplug
of a bridge, which we don't support yet but want to).

Fortunately, there's an alternative.  Bridges are required to have a unique
non-zero "chassis number" that we can use instead.  Adjust the code to
use that instead.

This looks like it would introduce a guest visible breaking change, but
in fact it does not because we don't yet ever use non-zero bus numbers.
Both chassis and bus number are always 0 for the root bus, so there's no
change for the existing cases.

Signed-off-by: David Gibson <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: cb600087060897ca73d231f3edbe7f70ae3ce67f
      
https://github.com/qemu/qemu/commit/cb600087060897ca73d231f3edbe7f70ae3ce67f
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Direct all PCI hotplug to host bridge, rather than P2P bridge

A P2P bridge will attempt to handle the hotplug with SHPC, which doesn't
work in the PAPR environment.  Instead we want to direct all PCI hotplug
actions to the PAPR specific host bridge which will use the PAPR hotplug
mechanism.

Signed-off-by: David Gibson <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: 14e714900f6b90b35ae2b040d300f95581a416f4
      
https://github.com/qemu/qemu/commit/14e714900f6b90b35ae2b040d300f95581a416f4
  Author: David Gibson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges

The pseries machine type already allows PCI hotplug and unplug via the
PAPR mechanism, but only on the root bus of each PHB.  This patch extends
this to allow PCI to PCI bridges to be hotplugged, and devices to be
hotplugged or unplugged under P2P bridges.

For now we disallow hot unplugging P2P bridges.  I tried doing that, but
haven't managed to get it working, I think due to some guest side problems
that need further investigation.

To do this we dynamically construct DRCs when bridges are hot (or cold)
added, which can in turn be used to hotplug devices under the bridge.

Signed-off-by: David Gibson <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>


  Commit: fe2d1696147b905c7bb67283588040576369ded4
      
https://github.com/qemu/qemu/commit/fe2d1696147b905c7bb67283588040576369ded4
  Author: Richard Henderson <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

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

  Log Message:
  -----------
  target/ppc: Use tcg_gen_gvec_bitsel

Replace the target-specific implementation of XXSEL.

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


  Commit: 8d409261416171efcaf3f741f677566308c16290
      
https://github.com/qemu/qemu/commit/8d409261416171efcaf3f741f677566308c16290
  Author: Cédric Le Goater <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/ppc/pnv.c

  Log Message:
  -----------
  ppc/pnv: activate the "dumpdtb" option on the powernv machine

This is a good way to debug the DT creation for current PowerNV
machines and new ones to come.

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: 4aca9786542e427d4337503566efdf09f2cb87cd
      
https://github.com/qemu/qemu/commit/4aca9786542e427d4337503566efdf09f2cb87cd
  Author: Benjamin Herrenschmidt <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

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

  Log Message:
  -----------
  ppc/xive: Make XIVE generate the proper interrupt types

It should be generic Hypervisor Virtualization interrupts for HV
directed rings and traditional External Interrupts for the OS directed
ring.

Don't generate anything for the user ring as it isn't actually
supported.

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


  Commit: a050901d4b40092dc356b59912c6df39e389c7b9
      
https://github.com/qemu/qemu/commit/a050901d4b40092dc356b59912c6df39e389c7b9
  Author: Peter Maydell <address@hidden>
  Date:   2019-06-12 (Wed, 12 Jun 2019)

  Changed paths:
    M hw/intc/xive.c
    M hw/ppc/pnv.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_pci.c
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/spapr_drc.h
    M include/hw/ppc/xive.h
    M target/ppc/translate/vsx-impl.inc.c

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

ppc patch queue 2019-06-12

Next pull request against qemu-4.1.  The big thing here is adding
support for hot plug of P2P bridges, and PCI devices under P2P bridges
on the "pseries" machine (which doesn't use SHPC).  Other than that
there's just a handful of fixes and small enhancements.

# gpg: Signature made Wed 12 Jun 2019 06:47:56 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.1-20190612:
  ppc/xive: Make XIVE generate the proper interrupt types
  ppc/pnv: activate the "dumpdtb" option on the powernv machine
  target/ppc: Use tcg_gen_gvec_bitsel
  spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges
  spapr: Direct all PCI hotplug to host bridge, rather than P2P bridge
  spapr: Don't use bus number for building DRC ids
  spapr: Clean up DRC index construction
  spapr: Clean up spapr_drc_populate_dt()
  spapr: Clean up dt creation for PCI buses
  spapr: Clean up device tree construction for PCI devices
  spapr: Clean up device node name generation for PCI devices
  target/ppc: Fix lxvw4x, lxvh8x and lxvb16x
  spapr_pci: Improve error message

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


Compare: https://github.com/qemu/qemu/compare/59c58f96b270...a050901d4b40



reply via email to

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