Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Radu Rendec <rrendec@redhat.com>
To:     linux-kernel@vger.kernel.org
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Pierre Gondois <Pierre.Gondois@arm.com>,
        Sudeep Holla <sudeep.holla@arm.com>,
        linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/3] arch_topology: Pre-allocate cacheinfo from primary CPU
Date:   Wed, 12 Apr 2023 14:57:56 -0400
Message-Id: <20230412185759.755408-1-rrendec@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
tries to build the cacheinfo from the primary CPU prior to secondary
CPUs boot, if the DT/ACPI description contains cache information.
However, if such information is not present, it still reverts to the old
behavior, which allocates the cacheinfo memory on each secondary CPU. On
RT kernels, this triggers a "BUG: sleeping function called from invalid
context" because the allocation is done before preemption is first
enabled on the secondary CPU.

The solution is to add cache information to DT/ACPI, but at least on
arm64 systems this can be avoided by leveraging automatic detection
(through the CLIDR_EL1 register), which is already implemented but
currently doesn't work on RT kernels for the reason described above.

This patch series attempts to enable automatic detection for RT kernels
when no DT/ACPI cache information is available, by pre-allocating
cacheinfo memory on the primary CPU.

The first patch adds an architecture independent infrastructure that
allows architecture specific code to take an early guess at the number
of cache leaves of the secodary CPUs, while it runs in preemptible
context on the primary CPU. At the same time, it gives architecture
specific code the opportunity to go back later, while it runs on the
secondary CPU, and reallocate the cacheinfo memory if the initial guess
proves to be wrong.

The second patch leverages the infrastructure implemented in the first
patch and enables early cache depth detection for arm64.

The third patch addresses a specific issue on ACPI systems with no PPTT.
This issue came up during review/testing of v3.

The patch series is based on an RFC patch that was posted to the
linux-arm-kernel mailing list and discussed with a smaller audience:
https://lore.kernel.org/all/20230323224242.31142-1-rrendec@redhat.com/

Changes to v3:
* Rebase on top of v6.3-rc6 to avoid a (trivial) merge conflict.
* Add patch #3 (brief description included above).
* Add "Reviewed-by: Pierre Gondois" tag to all patches.
* Rename the new field that is added to struct cpu_cacheinfo from
  early_arch_info to early_ci_levels to better reflect what it does.
* Use local variables in the new detect_cache_level() function. That way
  the code is easier to read and the original level/leaves algorithm is
  unchanged, which also makes the patch clearer.

Changes to v2:
* Address minor coding style issue (unbalanced braces).
* Move cacheinfo reallocation logic from detect_cache_attributes() to a
  new function to improve code readability.
* Minor fix to cacheinfo reallocation logic to avoid a new detection of
  the cache level if/when detect_cache_attributes() is called again.

Radu Rendec (3):
  cacheinfo: Add arch specific early level initializer
  cacheinfo: Add arm64 early level initializer implementation
  cacheinfo: Allow early level detection when DT/ACPI info is
    missing/broken

 arch/arm64/kernel/cacheinfo.c | 25 ++++++++++--
 drivers/base/arch_topology.c  |  4 +-
 drivers/base/cacheinfo.c      | 75 +++++++++++++++++++++++++----------
 include/linux/cacheinfo.h     |  2 +
 4 files changed, 79 insertions(+), 27 deletions(-)

-- 
2.39.2