On Wed, Mar 31, 2021 at 04:45:06PM +0200, Cédric Le Goater wrote: > The 'chip_id' field of the XIVE CPU structure is used to choose a > target for a source located on the same chip when possible. The XIVE > driver queries the chip id value from the "ibm,chip-id" DT property > but this property is not available on all platforms. It was first > introduced on the PowerNV platform and later, under QEMU for pseries. > However, the property does not exist under PowerVM since it is not > specified in PAPR. > > cpu_to_node() is a better alternative. On the PowerNV platform, the > node id is computed from the "ibm,associativity" property of the CPU. > Its value is built in the OPAL firmware from the physical chip id and > is equivalent to "ibm,chip-id".
Hrm... I mean, for powernv this is certainly correct, but seems to be
relying on pretty specific specifics of the OPAL / chip behaviour,
namely that the NUMA id == chip ID.
> On pSeries, the hcall
> H_HOME_NODE_ASSOCIATIVITY returns the node id.
AFAICT, the chip_id field is never actually used in the PAPR version
of XIVE. The only access to the field outside native.c is in
xive_pick_irq_target(), and it only looks at chip_id if src_chip is
valid. But src_chip is initialized to XIVE_INVALID_CHIP_ID in papr.c
So it would make more sense to me to also initialize chip_id to
XIVE_INVALID_CHIP_ID for PAPR to make it clearer that it's not
relevant.
> Also to be noted that under QEMU/KVM "ibm,chip-id" is badly calculated
> with unusual SMT configuration. This leads to a bogus chip id value
> being returned by of_get_ibm_chip_id().
I *still* don't clearly understand what you think is bogus about the
chip id value that qemu generates. It's clearly not a problem for
XIVE, since PAPR XIVE never uses it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
