From: "Cédric Le Goater" <clg@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v3 1/9] powerpc/xive: Use cpu_to_node() instead of "ibm,chip-id" property
Date: Thu, 1 Apr 2021 11:10:46 +0200 [thread overview]
Message-ID: <b9937a0d-659e-e56e-3d32-efce602a34e3@kaod.org> (raw)
In-Reply-To: <YGU0u4v2GVWBCrWw@yekko.fritz.box>
On 4/1/21 4:49 AM, David Gibson wrote:
> 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.
Yes. It seems so.
>> 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.
Yes.
> But src_chip is initialized to XIVE_INVALID_CHIP_ID in papr.c
Yes. The H_INT hcalls do no return any information on the source
location.
> 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.
yes. That would clarify that chip_id is only relevant on PowerVM/KVM.
We can drop this patch, it's not a requirement for patches 2-9, simply
a cleanup. I will move the chip_id assignment to a platform handler
in a other patch.
>> 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.
I am getting confused by socket/node/chip concepts under PPC.
However, when looking at PHB and MSI, there is definitely a "node"
concept being used in the core IRQ layer for allocation and affinity.
We will need to clarify that when we introduce MSI domains.
Thanks,
C.
next prev parent reply other threads:[~2021-04-01 9:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 14:45 [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 1/9] powerpc/xive: Use cpu_to_node() instead of "ibm, chip-id" property Cédric Le Goater
2021-04-01 2:49 ` [PATCH v3 1/9] powerpc/xive: Use cpu_to_node() instead of "ibm,chip-id" property David Gibson
2021-04-01 9:10 ` Cédric Le Goater [this message]
2021-03-31 14:45 ` [PATCH v3 2/9] powerpc/xive: Introduce an IPI interrupt domain Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 3/9] powerpc/xive: Remove useless check on XIVE_IPI_HW_IRQ Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 4/9] powerpc/xive: Simplify xive_core_debug_show() Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 5/9] powerpc/xive: Drop check on irq_data in xive_core_debug_show() Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 6/9] powerpc/xive: Simplify the dump of XIVE interrupts under xmon Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 7/9] powerpc/xive: Fix xmon command "dxi" Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 8/9] powerpc/xive: Map one IPI interrupt per node Cédric Le Goater
2021-04-01 12:50 ` Nicholas Piggin
2021-04-02 11:31 ` Cédric Le Goater
2021-04-02 12:19 ` Cédric Le Goater
2021-03-31 14:45 ` [PATCH v3 9/9] powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler Cédric Le Goater
2021-04-01 8:04 ` [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node Greg Kurz
2021-04-01 9:18 ` Cédric Le Goater
2021-04-01 12:45 ` Greg Kurz
2021-04-01 17:14 ` Cédric Le Goater
2021-04-01 8:42 ` Cédric Le Goater
2021-04-19 3:59 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9937a0d-659e-e56e-3d32-efce602a34e3@kaod.org \
--to=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.