All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	will.deacon@arm.com, mark.rutland@arm.com, dave.martin@arm.com,
	aph@redhat.com, ryan.arnold@linaro.org,
	adhemerval.zanella@linaro.org, sid@reserved-bit.com,
	Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: [PATCH v4 1/9] arm64: cpufeature: treat unknown fields as RES0
Date: Mon,  9 Jan 2017 17:28:24 +0000	[thread overview]
Message-ID: <1483982912-27215-2-git-send-email-suzuki.poulose@arm.com> (raw)
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>

From: Mark Rutland <mark.rutland@arm.com>

Any fields not defined in an arm64_ftr_bits entry are propagated to the
system-wide register value in init_cpu_ftr_reg(), and while we require
that these strictly match for the sanity checks, we don't update them in
update_cpu_ftr_reg().

Generally, the lack of an arm64_ftr_bits entry indicates that the bits
are currently RES0 (as is the case for the upper 32 bits of all
supposedly 32-bit registers).

A better default would be to use zero for the system-wide value of
unallocated bits, making all register checking consistent, and allowing
for subsequent simplifications to the arm64_ftr_bits arrays.

This patch updates init_cpu_ftr_reg() to treat unallocated bits as RES0
for the purpose of the system-wide safe value. These bits will still be
sanity checked with strict match requirements, as is currently the case.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/kernel/cpufeature.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fdf8f04..ea02201 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -410,23 +410,33 @@ static void __init sort_ftr_regs(void)
 /*
  * Initialise the CPU feature register from Boot CPU values.
  * Also initiliases the strict_mask for the register.
+ * Any bits that are not covered by an arm64_ftr_bits entry are considered
+ * RES0 for the system-wide value, and must strictly match.
  */
 static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
 {
 	u64 val = 0;
 	u64 strict_mask = ~0x0ULL;
+	u64 valid_mask = 0;
+
 	const struct arm64_ftr_bits *ftrp;
 	struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
 
 	BUG_ON(!reg);
 
 	for (ftrp  = reg->ftr_bits; ftrp->width; ftrp++) {
+		u64 ftr_mask = arm64_ftr_mask(ftrp);
 		s64 ftr_new = arm64_ftr_value(ftrp, new);
 
 		val = arm64_ftr_set_value(ftrp, val, ftr_new);
+
+		valid_mask |= ftr_mask;
 		if (!ftrp->strict)
-			strict_mask &= ~arm64_ftr_mask(ftrp);
+			strict_mask &= ~ftr_mask;
 	}
+
+	val &= valid_mask;
+
 	reg->sys_val = val;
 	reg->strict_mask = strict_mask;
 }
-- 
2.7.4

WARNING: multiple messages have this Message-ID (diff)
From: suzuki.poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/9] arm64: cpufeature: treat unknown fields as RES0
Date: Mon,  9 Jan 2017 17:28:24 +0000	[thread overview]
Message-ID: <1483982912-27215-2-git-send-email-suzuki.poulose@arm.com> (raw)
In-Reply-To: <1483982912-27215-1-git-send-email-suzuki.poulose@arm.com>

From: Mark Rutland <mark.rutland@arm.com>

Any fields not defined in an arm64_ftr_bits entry are propagated to the
system-wide register value in init_cpu_ftr_reg(), and while we require
that these strictly match for the sanity checks, we don't update them in
update_cpu_ftr_reg().

Generally, the lack of an arm64_ftr_bits entry indicates that the bits
are currently RES0 (as is the case for the upper 32 bits of all
supposedly 32-bit registers).

A better default would be to use zero for the system-wide value of
unallocated bits, making all register checking consistent, and allowing
for subsequent simplifications to the arm64_ftr_bits arrays.

This patch updates init_cpu_ftr_reg() to treat unallocated bits as RES0
for the purpose of the system-wide safe value. These bits will still be
sanity checked with strict match requirements, as is currently the case.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/kernel/cpufeature.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fdf8f04..ea02201 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -410,23 +410,33 @@ static void __init sort_ftr_regs(void)
 /*
  * Initialise the CPU feature register from Boot CPU values.
  * Also initiliases the strict_mask for the register.
+ * Any bits that are not covered by an arm64_ftr_bits entry are considered
+ * RES0 for the system-wide value, and must strictly match.
  */
 static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
 {
 	u64 val = 0;
 	u64 strict_mask = ~0x0ULL;
+	u64 valid_mask = 0;
+
 	const struct arm64_ftr_bits *ftrp;
 	struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
 
 	BUG_ON(!reg);
 
 	for (ftrp  = reg->ftr_bits; ftrp->width; ftrp++) {
+		u64 ftr_mask = arm64_ftr_mask(ftrp);
 		s64 ftr_new = arm64_ftr_value(ftrp, new);
 
 		val = arm64_ftr_set_value(ftrp, val, ftr_new);
+
+		valid_mask |= ftr_mask;
 		if (!ftrp->strict)
-			strict_mask &= ~arm64_ftr_mask(ftrp);
+			strict_mask &= ~ftr_mask;
 	}
+
+	val &= valid_mask;
+
 	reg->sys_val = val;
 	reg->strict_mask = strict_mask;
 }
-- 
2.7.4

  reply	other threads:[~2017-01-09 17:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 17:28 [PATCH v4 0/9] arm64: Expose CPUID registers via emulation Suzuki K Poulose
2017-01-09 17:28 ` Suzuki K Poulose
2017-01-09 17:28 ` Suzuki K Poulose [this message]
2017-01-09 17:28   ` [PATCH v4 1/9] arm64: cpufeature: treat unknown fields as RES0 Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 2/9] arm64: cpufeature: remove explicit RAZ fields Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 3/9] arm64: cpufeature: Cleanup feature bit tables Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 4/9] arm64: cpufeature: Document the rules of safe value for features Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 5/9] arm64: cpufeature: Define helpers for sys_reg id Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 6/9] arm64: Add helper to decode register from instruction Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 7/9] arm64: cpufeature: Track user visible fields Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-10 14:24   ` Catalin Marinas
2017-01-10 14:24     ` Catalin Marinas
2017-01-10 14:25     ` Suzuki K Poulose
2017-01-10 14:25       ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 8/9] arm64: cpufeature: Expose CPUID registers by emulation Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-09 17:28 ` [PATCH v4 9/9] arm64: Documentation - Expose CPU feature registers Suzuki K Poulose
2017-01-09 17:28   ` Suzuki K Poulose
2017-01-10 17:15 ` [PATCH v4 0/9] arm64: Expose CPUID registers via emulation Will Deacon
2017-01-10 17:15   ` Will Deacon

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=1483982912-27215-2-git-send-email-suzuki.poulose@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=aph@redhat.com \
    --cc=catalin.marinas@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=ryan.arnold@linaro.org \
    --cc=sid@reserved-bit.com \
    --cc=will.deacon@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 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.