All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, will@kernel.org, maz@kernel.org,
	mark.rutland@arm.com, dave.martin@arm.com,
	ard.biesheuvel@linaro.org, christoffer.dall@arm.com,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH v2 1/7] arm64: Introduce system_capabilities_finalized() marker
Date: Fri, 10 Jan 2020 14:50:19 +0000	[thread overview]
Message-ID: <20200110145019.GD8786@arrakis.emea.arm.com> (raw)
In-Reply-To: <20191217183402.2259904-2-suzuki.poulose@arm.com>

On Tue, Dec 17, 2019 at 06:33:56PM +0000, Suzuki K Poulose wrote:
> We finalize the system wide capabilities after the SMP CPUs
> are booted by the kernel. This is used as a marker for deciding
> various checks in the kernel. e.g, sanity check the hotplugged
> CPUs for missing mandatory features.
> 
> However there is no explicit helper available for this in the
> kernel. There is sys_caps_initialised, which is not exposed.
> The other closest one we have is the jump_label arm64_const_caps_ready
> which denotes that the capabilities are set and the capability checks
> could use the individual jump_labels for fast path. This is
> performed before setting the ELF Hwcaps, which must be checked
> against the new CPUs. We also perform some of the other initialization
> e.g, SVE setup, which is important for the use of FP/SIMD
> where SVE is supported. Normally userspace doesn't get to run
> before we finish this. However the in-kernel users may
> potentially start using the neon mode. So, we need to
> reject uses of neon mode before we are set. Instead of defining
> a new marker for the completion of SVE setup, we could simply
> reuse the arm64_const_caps_ready and enable it once we have
> finished all the setup. Also we could expose this to the
> various users as "system_capabilities_finalized()" to make
> it more meaningful than "const_caps_ready".
> 
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: mark.rutland@arm.com, ard.biesheuvel@linaro.org, maz@kernel.org,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, christoffer.dall@arm.com,
	will@kernel.org, dave.martin@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/7] arm64: Introduce system_capabilities_finalized() marker
Date: Fri, 10 Jan 2020 14:50:19 +0000	[thread overview]
Message-ID: <20200110145019.GD8786@arrakis.emea.arm.com> (raw)
In-Reply-To: <20191217183402.2259904-2-suzuki.poulose@arm.com>

On Tue, Dec 17, 2019 at 06:33:56PM +0000, Suzuki K Poulose wrote:
> We finalize the system wide capabilities after the SMP CPUs
> are booted by the kernel. This is used as a marker for deciding
> various checks in the kernel. e.g, sanity check the hotplugged
> CPUs for missing mandatory features.
> 
> However there is no explicit helper available for this in the
> kernel. There is sys_caps_initialised, which is not exposed.
> The other closest one we have is the jump_label arm64_const_caps_ready
> which denotes that the capabilities are set and the capability checks
> could use the individual jump_labels for fast path. This is
> performed before setting the ELF Hwcaps, which must be checked
> against the new CPUs. We also perform some of the other initialization
> e.g, SVE setup, which is important for the use of FP/SIMD
> where SVE is supported. Normally userspace doesn't get to run
> before we finish this. However the in-kernel users may
> potentially start using the neon mode. So, we need to
> reject uses of neon mode before we are set. Instead of defining
> a new marker for the completion of SVE setup, we could simply
> reuse the arm64_const_caps_ready and enable it once we have
> finished all the setup. Also we could expose this to the
> various users as "system_capabilities_finalized()" to make
> it more meaningful than "const_caps_ready".
> 
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-10 14:50 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 18:33 [PATCH v2 0/7] arm64: Fix support for no FP/SIMD Suzuki K Poulose
2019-12-17 18:33 ` Suzuki K Poulose
2019-12-17 18:33 ` [PATCH v2 1/7] arm64: Introduce system_capabilities_finalized() marker Suzuki K Poulose
2019-12-17 18:33   ` Suzuki K Poulose
2020-01-10 14:50   ` Catalin Marinas [this message]
2020-01-10 14:50     ` Catalin Marinas
2019-12-17 18:33 ` [PATCH v2 2/7] arm64: fpsimd: Make sure SVE setup is complete before SIMD is used Suzuki K Poulose
2019-12-17 18:33   ` Suzuki K Poulose
2020-01-10 11:51   ` Catalin Marinas
2020-01-10 11:51     ` Catalin Marinas
2020-01-10 18:41     ` Suzuki Kuruppassery Poulose
2020-01-10 18:41       ` Suzuki Kuruppassery Poulose
2019-12-17 18:33 ` [PATCH v2 3/7] arm64: cpufeature: Fix the type of no FP/SIMD capability Suzuki K Poulose
2019-12-17 18:33   ` Suzuki K Poulose
2020-01-10 14:50   ` Catalin Marinas
2020-01-10 14:50     ` Catalin Marinas
2019-12-17 18:33 ` [PATCH v2 4/7] arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly Suzuki K Poulose
2019-12-17 18:33   ` Suzuki K Poulose
2020-01-10 14:51   ` Catalin Marinas
2020-01-10 14:51     ` Catalin Marinas
2019-12-17 18:34 ` [PATCH v2 5/7] arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations Suzuki K Poulose
2019-12-17 18:34   ` Suzuki K Poulose
2020-01-10 15:12   ` Catalin Marinas
2020-01-10 15:12     ` Catalin Marinas
2020-01-10 18:42     ` Suzuki Kuruppassery Poulose
2020-01-10 18:42       ` Suzuki Kuruppassery Poulose
2019-12-17 18:34 ` [PATCH v2 6/7] arm64: signal: nofpsimd: Handle fp/simd context for signal frames Suzuki K Poulose
2019-12-17 18:34   ` Suzuki K Poulose
2020-01-10 12:34   ` Catalin Marinas
2020-01-10 12:34     ` Catalin Marinas
2019-12-17 18:34 ` [PATCH v2 7/7] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly Suzuki K Poulose
2019-12-17 18:34   ` Suzuki K Poulose
2019-12-17 19:05   ` Marc Zyngier
2019-12-17 19:05     ` Marc Zyngier
2019-12-18 11:42     ` Suzuki Kuruppassery Poulose
2019-12-18 11:42       ` Suzuki Kuruppassery Poulose
2019-12-18 11:56       ` Marc Zyngier
2019-12-18 11:56         ` Marc Zyngier
2019-12-18 12:00         ` Suzuki Kuruppassery Poulose
2019-12-18 12:00           ` Suzuki Kuruppassery Poulose
2020-01-10 15:21           ` Marc Zyngier
2020-01-10 15:21             ` Marc Zyngier
2020-01-13 10:28             ` Suzuki Kuruppassery Poulose
2020-01-13 10:28               ` Suzuki Kuruppassery Poulose
2020-01-10 14:49   ` Catalin Marinas
2020-01-10 14:49     ` Catalin Marinas
2020-03-27 13:04 [PATCH v2 1/7] arm64: Introduce system_capabilities_finalized() marker Billie Teall

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=20200110145019.GD8786@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=christoffer.dall@arm.com \
    --cc=dave.martin@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.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.