linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ruifeng Zhang <ruifeng.zhang0110@gmail.com>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux@armlinux.org.uk, sudeep.holla@arm.com,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	a.p.zijlstra@chello.nl, dietmar.eggemann@arm.com,
	mingo@kernel.org, ruifeng.zhang1@unisoc.com,
	nianfu.bai@unisoc.com, linux-arm-kernel@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] arm: topology: parse the topology from the dt
Date: Tue, 13 Apr 2021 14:13:28 +0800	[thread overview]
Message-ID: <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com> (raw)
In-Reply-To: <87tuobmsba.mognet@arm.com>

Valentin Schneider <valentin.schneider@arm.com> 于2021年4月12日周一 下午11:33写道:
>
> On 12/04/21 20:20, Ruifeng Zhang wrote:
> > There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> > The MPIDR has been written to the chip register in armv8.3 format.
> > For example,
> > core0: 0000000080000000
> > core1: 0000000080000100
> > core2: 0000000080000200
> > ...
> >
> > Its cpu topology can be parsed normally on aarch64 mode (both
> > userspace and kernel work on arm64).
> >
> > The problem is when it working on aarch32 mode (both userspace and
> > kernel work on arm 32-bit),
>
> I didn't know using aarch32 elsewhere than EL0 was something actually being
> used. Do you deploy this somewhere, or do you use it for testing purposes?

In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
version, one
of them is the kernel running on EL1 using aarch32.
                          user(EL0)            kernel(EL1)
sc9863a_go      aarch32               aarch32
sc9863a            aarch64               aarch64
>
> > the cpu topology
> > will parse error because of the format is different between armv7 and armv8.3.
> > The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> > and store to the topology with armv7,
> > and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
> >
>
> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
> I couldn't find anything about MPIDR format differences:
>
>   DDI 0487G.a G8.2.113
>   """
>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
>   AArch64 System register MPIDR_EL1[31:0].
>   """
>
> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
> just the same, i.e. for both of them, with your example of:

The cortex-a7 spec DDI0464F 4.3.5
https://developer.arm.com/documentation/ddi0464/f/?lang=en

The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
the parse code is:
void store_cpu_topology(unsigned int cpuid)
{
    ...
    cpuid_topo->thread_id = -1;
    cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
    cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
    ...
}
>
>   core0: 0000000080000000
>   core1: 0000000080000100
>   core2: 0000000080000200
>   ...
>
> we'll get:
>
>   |       | aff2 | aff1 | aff0 |
>   |-------+------+------+------|
>   | Core0 |    0 |    0 |    0 |
>   | Core1 |    0 |    1 |    0 |
>   | Core2 |    0 |    2 |    0 |
>       ...
>
> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
>
>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>
> so without DT we would get:
>   |       | package_id | core_id |
>   |-------+------------+---------|
>   | Core0 |          0 |       0 |
>   | Core1 |          0 |       1 |
>   | Core2 |          0 |       2 |
>
> Whereas with an arm kernel we'll end up parsing MPIDR as:
>   |       | package_id | core_id |
>   |-------+------------+---------|
>   | Core0 |          0 |       0 |
>   | Core1 |          1 |       0 |
>   | Core2 |          2 |       0 |
>
> Did I get this right? Is this what you're observing?

Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
kernel on EL1.
>
> > In addition, I think arm should also allow customers to configure cpu
> > topologies via DT.

  reply	other threads:[~2021-04-13  6:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  7:08 [PATCH 1/1] arm: topology: parse the topology from the dt Ruifeng Zhang
2021-04-12 11:31 ` Valentin Schneider
2021-04-12 12:20   ` Ruifeng Zhang
2021-04-12 12:40     ` Dietmar Eggemann
2021-04-13  6:18       ` Ruifeng Zhang
2021-04-12 15:32     ` Valentin Schneider
2021-04-13  6:13       ` Ruifeng Zhang [this message]
2021-04-13 11:40         ` Valentin Schneider
2021-04-13 13:26           ` Ruifeng Zhang
2021-04-14  9:42             ` Dietmar Eggemann
2021-04-14 11:26               ` Ruifeng Zhang
2021-04-14 13:53                 ` Dietmar Eggemann

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=CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com \
    --to=ruifeng.zhang0110@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mingo@kernel.org \
    --cc=nianfu.bai@unisoc.com \
    --cc=rafael@kernel.org \
    --cc=ruifeng.zhang1@unisoc.com \
    --cc=sudeep.holla@arm.com \
    --cc=valentin.schneider@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).