riscv: improve boot time isa extensions handling

Alternatives live in a different section, so offsets used by jal instruction will point to wrong locations after the patch got applied.

Similar to arm64, adjust the location to consider that offset.

Co-developed-by Heiko Stuebner <[email protected]>

Signed-off-by Heiko Stuebner <[email protected]>

Signed-off-by Jisheng Zhang <[email protected]>

---
 arch/riscv/include/asm/insn.h   | 27 +++++++++++++++++++++++++++
 arch/riscv/kernel/alternative.c | 27 +++++++++++++++++++++++++++
 2 files changed, 54 insertions(+)

arch/riscv/include/asm/insn.h +27 -0

index 98453535324a..1d2df245d0bd 100644
@@ -291,6 +291,33 @@ static __always_inline bool riscv_insn_is_branch(u32 code)
 	(RVC_X(x_, RVC_B_IMM_7_6_OPOFF, RVC_B_IMM_7_6_MASK) << RVC_B_IMM_7_6_OFF) | \
 	(RVC_IMM_SIGN(x_) << RVC_B_IMM_SIGN_OFF); })
 
+/*
+ * Get the immediate from a J-type instruction.
+ *
+ * @insn: instruction to process
+ * Return: immediate
+ */
+static inline s32 riscv_insn_extract_jtype_imm(u32 insn)
+{
+	return RV_EXTRACT_JTYPE_IMM(insn);
+}
+
+/*
+ * Update a J-type instruction with an immediate value.
+ *
+ * @insn: pointer to the jtype instruction
+ * @imm: the immediate to insert into the instruction
+ */
+static inline void riscv_insn_insert_jtype_imm(u32 *insn, s32 imm)
+{
+	/* drop the old IMMs, all jal IMM bits sit at 31:12 */
+	*insn &= ~GENMASK(31, 12);
+	*insn |= (RV_X(imm, RV_J_IMM_10_1_OFF, RV_J_IMM_10_1_MASK) << RV_J_IMM_10_1_OPOFF) |
+		 (RV_X(imm, RV_J_IMM_11_OFF, RV_J_IMM_11_MASK) << RV_J_IMM_11_OPOFF) |
+		 (RV_X(imm, RV_J_IMM_19_12_OFF, RV_J_IMM_19_12_MASK) << RV_J_IMM_19_12_OPOFF) |
+		 (RV_X(imm, RV_J_IMM_SIGN_OFF, 1) << RV_J_IMM_SIGN_OPOFF);
+}
+
 /*
  * Put together one immediate from a U-type and I-type instruction pair.
  *

arch/riscv/kernel/alternative.c +27 -0

index 6212ea0eed72..3d4f1f32c7f6 100644
@@ -79,6 +79,21 @@ static void riscv_alternative_fix_auipc_jalr(void *ptr, u32 auipc_insn,
 	patch_text_nosync(ptr, call, sizeof(u32) * 2);
 }
 
+static void riscv_alternative_fix_jal(void *ptr, u32 jal_insn, int patch_offset)
+{
+	s32 imm;
+
+	/* get and adjust new target address */
+	imm = riscv_insn_extract_jtype_imm(jal_insn);
+	imm -= patch_offset;
+
+	/* update instruction */
+	riscv_insn_insert_jtype_imm(&jal_insn, imm);
+
+	/* patch the call place again */
+	patch_text_nosync(ptr, &jal_insn, sizeof(u32));
+}
+
 void riscv_alternative_fix_offsets(void *alt_ptr, unsigned int len,
 				      int patch_offset)
 {

@@ -106,6 +121,18 @@ void riscv_alternative_fix_offsets(void *alt_ptr, unsigned int len,
 			riscv_alternative_fix_auipc_jalr(alt_ptr + i * sizeof(u32),
 							 insn, insn2, patch_offset);
 		}
+
+		if (riscv_insn_is_jal(insn)) {
+			s32 imm = riscv_insn_extract_jtype_imm(insn);
+
+			/* Don't modify jumps inside the alternative block */
+			if ((alt_ptr + i * sizeof(u32) + imm) >= alt_ptr &&
+			    (alt_ptr + i * sizeof(u32) + imm) < (alt_ptr + len))
+				continue;
+
+			riscv_alternative_fix_jal(alt_ptr + i * sizeof(u32),
+						  insn, patch_offset);
+		}
 	}
 }
 

Signature · 1 line

2.38.1

Alternatives live in a different section, so offsets used by jal instruction will point to wrong locations after the patch got applied.

Similar to arm64, adjust the location to consider that offset.

Co-developed-by Heiko Stuebner <[email protected]>

Signed-off-by Heiko Stuebner <[email protected]>

Signed-off-by Jisheng Zhang <[email protected]>

Am Mittwoch, 11. Januar 2023, 18:10:15 CET schrieb Jisheng Zhang:

Quoted 8 lines

Alternatives live in a different section, so offsets used by jal instruction will point to wrong locations after the patch got applied.

Similar to arm64, adjust the location to consider that offset.

Co-developed-by Heiko Stuebner <[email protected]>

Signed-off-by Heiko Stuebner <[email protected]>

Signed-off-by Jisheng Zhang <[email protected]>

looks good, thanks for fixing the issues Andrew and Conor pointed out in the variant in my zbb series. I've now switched over to this one.

I guess as you said, we really should separate this out into a single patch [or if Palmer is fine with that, just pick this one patch to apply until the rest is ready]

Currently riscv_cpufeature_patch_func() does nothing at the RISCV_ALTERNATIVES_EARLY_BOOT stage. Add a check to detect whether we are in this stage and exit early. This will allow us to use riscv_cpufeature_patch_func() for scanning of all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/kernel/cpufeature.c | 3 +++
 1 file changed, 3 insertions(+)

arch/riscv/kernel/cpufeature.c +3 -0

index 421b3d9578cc..37e8c5e69754 100644
@@ -328,6 +328,9 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
 	struct alt_entry *alt;
 	u32 tmp;
 
+	if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
+		return;
+
 	for (alt = begin; alt < end; alt++) {
 		if (alt->vendor_id != 0)
 			continue;

Signature · 7 lines

2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

We will make use of ISA extension in asm files, so make the multi-letter

RISC-V ISA extension IDs macros rather than enums and move them and those base ISA extension IDs to suitable place.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

---
 arch/riscv/include/asm/hwcap.h | 45 ++++++++++++++++------------------
 1 file changed, 21 insertions(+), 24 deletions(-)

arch/riscv/include/asm/hwcap.h +21 -24

index 86328e3acb02..09a7767723f6 100644
@@ -12,20 +12,6 @@
 #include <linux/bits.h>
 #include <uapi/asm/hwcap.h>
 
-#ifndef __ASSEMBLY__
-#include <linux/jump_label.h>
-/*
- * This yields a mask that user programs can use to figure out what
- * instruction set this cpu supports.
- */
-#define ELF_HWCAP		(elf_hwcap)
-
-enum {
-	CAP_HWCAP = 1,
-};
-
-extern unsigned long elf_hwcap;
-
 #define RISCV_ISA_EXT_a		('a' - 'a')
 #define RISCV_ISA_EXT_c		('c' - 'a')
 #define RISCV_ISA_EXT_d		('d' - 'a')

@@ -46,22 +32,33 @@ extern unsigned long elf_hwcap;
 #define RISCV_ISA_EXT_BASE 26
 
 /*
- * This enum represent the logical ID for each multi-letter RISC-V ISA extension.
+ * These macros represent the logical ID for each multi-letter RISC-V ISA extension.
  * The logical ID should start from RISCV_ISA_EXT_BASE and must not exceed
  * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter
  * extensions while all the multi-letter extensions should define the next
  * available logical extension id.
  */
-enum riscv_isa_ext_id {
-	RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
-	RISCV_ISA_EXT_SVPBMT,
-	RISCV_ISA_EXT_ZICBOM,
-	RISCV_ISA_EXT_ZIHINTPAUSE,
-	RISCV_ISA_EXT_SSTC,
-	RISCV_ISA_EXT_SVINVAL,
-	RISCV_ISA_EXT_ID_MAX
+#define RISCV_ISA_EXT_SSCOFPMF		26
+#define RISCV_ISA_EXT_SVPBMT		27
+#define RISCV_ISA_EXT_ZICBOM		28
+#define RISCV_ISA_EXT_ZIHINTPAUSE	29
+#define RISCV_ISA_EXT_SSTC		30
+#define RISCV_ISA_EXT_SVINVAL		31
+
+#ifndef __ASSEMBLY__
+#include <linux/jump_label.h>
+/*
+ * This yields a mask that user programs can use to figure out what
+ * instruction set this cpu supports.
+ */
+#define ELF_HWCAP		(elf_hwcap)
+
+enum {
+	CAP_HWCAP = 1,
 };
-static_assert(RISCV_ISA_EXT_ID_MAX <= RISCV_ISA_EXT_MAX);
+
+extern unsigned long elf_hwcap;
+
 
 /*
  * This enum represents the logical ID for each RISC-V ISA extension static

Signature · 7 lines

2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Hey Jisheng,

Quoted 4 lines

We will make use of ISA extension in asm files, so make the multi-letter

RISC-V ISA extension IDs macros rather than enums and move them and those base ISA extension IDs to suitable place.

From v2:
Which base ISA extension IDs? Changelog should match the patch contents, and it's a little unclear here since the base ISA extension IDs are visible here but in the context not the diff.

How about something like:
"So that ISA extensions can be used in assembly files, convert the multi-letter RISC-V ISA extension IDs enums to macros. In order to make them visible, move the #ifndef __ASSEMBLY__ guard to a later point in the header"

Pedantry perhaps, but referring to moving the base IDs looks odd, since that is not what git thinks you did - even if that is the copy paste

operation you carried out.

Content itself is

Reviewed-by Conor Dooley <[email protected]>

Thanks,
Conor.

Quoted 84 lines

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

---
 arch/riscv/include/asm/hwcap.h | 45 ++++++++++++++++------------------
 1 file changed, 21 insertions(+), 24 deletions(-)

arch/riscv/include/asm/hwcap.h +21 -24

index 86328e3acb02..09a7767723f6 100644
@@ -12,20 +12,6 @@
 #include <linux/bits.h>
 #include <uapi/asm/hwcap.h>
 
-#ifndef __ASSEMBLY__
-#include <linux/jump_label.h>
-/*
- * This yields a mask that user programs can use to figure out what
- * instruction set this cpu supports.
- */
-#define ELF_HWCAP		(elf_hwcap)
-
-enum {
-	CAP_HWCAP = 1,
-};
-
-extern unsigned long elf_hwcap;
-
 #define RISCV_ISA_EXT_a		('a' - 'a')
 #define RISCV_ISA_EXT_c		('c' - 'a')
 #define RISCV_ISA_EXT_d		('d' - 'a')

@@ -46,22 +32,33 @@ extern unsigned long elf_hwcap;
 #define RISCV_ISA_EXT_BASE 26
 
 /*
- * This enum represent the logical ID for each multi-letter RISC-V ISA extension.
+ * These macros represent the logical ID for each multi-letter RISC-V ISA extension.
  * The logical ID should start from RISCV_ISA_EXT_BASE and must not exceed
  * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter
  * extensions while all the multi-letter extensions should define the next
  * available logical extension id.
  */
-enum riscv_isa_ext_id {
-	RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE,
-	RISCV_ISA_EXT_SVPBMT,
-	RISCV_ISA_EXT_ZICBOM,
-	RISCV_ISA_EXT_ZIHINTPAUSE,
-	RISCV_ISA_EXT_SSTC,
-	RISCV_ISA_EXT_SVINVAL,
-	RISCV_ISA_EXT_ID_MAX
+#define RISCV_ISA_EXT_SSCOFPMF		26
+#define RISCV_ISA_EXT_SVPBMT		27
+#define RISCV_ISA_EXT_ZICBOM		28
+#define RISCV_ISA_EXT_ZIHINTPAUSE	29
+#define RISCV_ISA_EXT_SSTC		30
+#define RISCV_ISA_EXT_SVINVAL		31
+
+#ifndef __ASSEMBLY__
+#include <linux/jump_label.h>
+/*
+ * This yields a mask that user programs can use to figure out what
+ * instruction set this cpu supports.
+ */
+#define ELF_HWCAP		(elf_hwcap)
+
+enum {
+	CAP_HWCAP = 1,
 };
-static_assert(RISCV_ISA_EXT_ID_MAX <= RISCV_ISA_EXT_MAX);
+
+extern unsigned long elf_hwcap;
+
 
 /*
  * This enum represents the logical ID for each RISC-V ISA extension static

Signature · 7 lines

2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Hi Jisheng.

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

In my optimization quest, I found that it's actually pretty neat to convert the errata-id for cpufeatures to a bitfield [1], because then it's possible to just combine extensions into said bitfield [2]:

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

So I really feel this would limit us quite a bit.

Heiko

[0] https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=riscv-hwprobe-v1&id=510c491cb9d87dcbdc91c63558dc704968723240
[1] https://github.com/mmind/linux-riscv/commit/f57a896122ee7e666692079320fc35829434cf96
[2] https://github.com/mmind/linux-riscv/commit/8cef615dab0c00ad68af2651ee5b93d06be17f27#diff-194cb8a86f9fb9b03683295f21c8f46b456a9f94737f01726ddbcbb9e3aace2cR12

Quoted 13 lines · Heiko St?bner

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Quoted 7 lines

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

I agree that this needs to be addressed and Jisheng also raised this yesterday here [*]. It seems we need the concept of cpufeatures, which may be extensions or non-extensions.

[*] https://lore.kernel.org/all/Y77xyNPNqnFQUqAx at xhacker/

Quoted 6 lines

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

Quoted 2 lines

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

One possible approach may be to combine extensions/non-extensions at boot time into pseudo-cpufeatures. Then, alternatives can continue attaching to a single "feature". (I'm not saying that's a better approach than the bitmap, I'm just suggesting it as something else to consider.)

Quoted 5 lines

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

Quoted 34 lines · Andrew Jones

Quoted 13 lines · Heiko St?bner

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Quoted 7 lines

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

I agree that this needs to be addressed and Jisheng also raised this yesterday here [*]. It seems we need the concept of cpufeatures, which may be extensions or non-extensions.

[*] https://lore.kernel.org/all/Y77xyNPNqnFQUqAx at xhacker/

Quoted 6 lines

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

Quoted 14 lines

Quoted 2 lines

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

One possible approach may be to combine extensions/non-extensions at boot time into pseudo-cpufeatures. Then, alternatives can continue attaching to a single "feature". (I'm not saying that's a better approach than the bitmap, I'm just suggesting it as something else to consider.)

Quoted 5 lines

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

Since we're discussing theoretical implementations, and it's a little hard to picture all that they entail in my head, I might be making a fool of myself here with assumptions...

Heiko's suggestion sounded along the lines of: keep probing individual "features" as we are now. Features in this case being the presence of the extension or non-extension capability. And then in the alternative, make all of the decisions about which to apply.

Drew's suggestion would have significantly more defined CPUFEATURE_FOOs, but would offload the decision making about which extensions or non- extension capabilities constitute a feature to regular old cpufeature code. However, the order of precedence would remain in the alt macro, as it does now.

I think I am just a wee bit biased, but adding the complexity somewhere other than alternative macros seems a wise choice, especially as we are likely to find that complexity increases over time?

The other thing that came to mind, and maybe this is just looking for holes where they don't exist (or are not worth addressing), is that order of precedence.
I can imagine that, in some cases, the order of precedence is not a constant per psuedo-cpufeature, but determined by implementation of the capabilities that comprise it?

If my assumption/understanding holds, moving decision making out of the alternative seems like it would better provision for scenarios like that? I dunno, maybe that is whatever the corollary of "premature optimisation" is for this discussion.

That's my unsolicited ? 0.02, hopefully I wasn't off-base with the assumptions I made.

Heiko, I figure you've got some sort of WIP stuff for this anyway since you're interested in the fast unaligned? How close are you to posting any of that?

While I think of it, w.r.t. extension versus (pseudo)cpufeature etc naming, it may make sense to call the functions that this series adds in patch 6 has_cpufeature_{un,}likely(), no matter what decision gets made here?
IMO using cpufeature seems to make more sense for a general use API that may be used later on for the likes of unaligned access, even if initially it is not used for anything other than extensions.

Quoted 69 lines · Conor Dooley

Quoted 34 lines · Andrew Jones

Quoted 13 lines · Heiko St?bner

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Quoted 7 lines

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

I agree that this needs to be addressed and Jisheng also raised this yesterday here [*]. It seems we need the concept of cpufeatures, which may be extensions or non-extensions.

[*] https://lore.kernel.org/all/Y77xyNPNqnFQUqAx at xhacker/

Quoted 6 lines

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

Quoted 14 lines

Quoted 2 lines

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

One possible approach may be to combine extensions/non-extensions at boot time into pseudo-cpufeatures. Then, alternatives can continue attaching to a single "feature". (I'm not saying that's a better approach than the bitmap, I'm just suggesting it as something else to consider.)

Quoted 5 lines

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

Since we're discussing theoretical implementations, and it's a little hard to picture all that they entail in my head, I might be making a fool of myself here with assumptions...

Heiko's suggestion sounded along the lines of: keep probing individual "features" as we are now. Features in this case being the presence of the extension or non-extension capability. And then in the alternative, make all of the decisions about which to apply.

Drew's suggestion would have significantly more defined CPUFEATURE_FOOs, but would offload the decision making about which extensions or non- extension capabilities constitute a feature to regular old cpufeature code. However, the order of precedence would remain in the alt macro, as it does now.

I think I am just a wee bit biased, but adding the complexity somewhere other than alternative macros seems a wise choice, especially as we are likely to find that complexity increases over time?

Quoted 6 lines

The other thing that came to mind, and maybe this is just looking for holes where they don't exist (or are not worth addressing), is that order of precedence.
I can imagine that, in some cases, the order of precedence is not a constant per psuedo-cpufeature, but determined by implementation of the capabilities that comprise it?

Having spent longer than I maybe should've looking at your patches Heiko, given it's a Saturday evening, the precedence stuff is still sticking out to me..

For Zbb & fast unaligned, the order may be non-controversial, but in the general case I don't see how it can be true that the order of precedence for variants is a constant.

Creating pseudo cpufeatures as Drew suggested does seem like a way to extract complexity from the alternatives themselves (which I think is a good thing) but at the expense of eating up cpu_req_feature bits... By itself, it doesn't help with precedence, but it may better allow us to deal with some of the precedence in cpufeature.c, since the alternative would operate based on the pseudo cpufeature rather than on the individual capabilities that the pseudo cpufeature depends on.

I tried to come up with a suggestion for what to do about precedence, but everything I thought up felt a bit horrific tbh.
The thing that fits the current model best is just allowing cpu vendors to add, yet more, "errata" that pick the variant that works best for their implementation... Although I'd be worried about ballooning some of these ALT_FOO macros out to a massive degree with that sort of approach.

Quoted 7 lines

If my assumption/understanding holds, moving decision making out of the alternative seems like it would better provision for scenarios like that? I dunno, maybe that is whatever the corollary of "premature optimisation" is for this discussion.

That's my unsolicited ? 0.02, hopefully I wasn't off-base with the assumptions I made.

The order in which an alternative is added to the macro does matter, right? At least, that's how I thought it worked and hope I've not had an incorrect interpretation there all along... I wasn't until I started reading your patch and couldn't understand why you had a construct that looked like

if (zbb && !fast_unaligned)
...
else if (zbb && fast_unaligned)
...

rather than just inverting the order and dropping the !fast_unaligned that I realised I might have a gap in my understanding after all..

Quoted 11 lines

Heiko, I figure you've got some sort of WIP stuff for this anyway since you're interested in the fast unaligned? How close are you to posting any of that?

While I think of it, w.r.t. extension versus (pseudo)cpufeature etc naming, it may make sense to call the functions that this series adds in patch 6 has_cpufeature_{un,}likely(), no matter what decision gets made here?
IMO using cpufeature seems to make more sense for a general use API that may be used later on for the likes of unaligned access, even if initially it is not used for anything other than extensions.

Hey!

I guess here is the right place to follow up on all of this stuff...

Quoted 114 lines · Conor Dooley

Quoted 69 lines · Conor Dooley

Quoted 34 lines · Andrew Jones

Quoted 13 lines · Heiko St?bner

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Quoted 7 lines

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

I agree that this needs to be addressed and Jisheng also raised this yesterday here [*]. It seems we need the concept of cpufeatures, which may be extensions or non-extensions.

[*] https://lore.kernel.org/all/Y77xyNPNqnFQUqAx at xhacker/

Quoted 6 lines

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

Quoted 14 lines

Quoted 2 lines

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

One possible approach may be to combine extensions/non-extensions at boot time into pseudo-cpufeatures. Then, alternatives can continue attaching to a single "feature". (I'm not saying that's a better approach than the bitmap, I'm just suggesting it as something else to consider.)

Quoted 5 lines

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

Since we're discussing theoretical implementations, and it's a little hard to picture all that they entail in my head, I might be making a fool of myself here with assumptions...

Heiko's suggestion sounded along the lines of: keep probing individual "features" as we are now. Features in this case being the presence of the extension or non-extension capability. And then in the alternative, make all of the decisions about which to apply.

Drew's suggestion would have significantly more defined CPUFEATURE_FOOs, but would offload the decision making about which extensions or non- extension capabilities constitute a feature to regular old cpufeature code. However, the order of precedence would remain in the alt macro, as it does now.

I think I am just a wee bit biased, but adding the complexity somewhere other than alternative macros seems a wise choice, especially as we are likely to find that complexity increases over time?

Quoted 6 lines

The other thing that came to mind, and maybe this is just looking for holes where they don't exist (or are not worth addressing), is that order of precedence.
I can imagine that, in some cases, the order of precedence is not a constant per psuedo-cpufeature, but determined by implementation of the capabilities that comprise it?

Having spent longer than I maybe should've looking at your patches Heiko, given it's a Saturday evening, the precedence stuff is still sticking out to me..

For Zbb & fast unaligned, the order may be non-controversial, but in the general case I don't see how it can be true that the order of precedence for variants is a constant.

Creating pseudo cpufeatures as Drew suggested does seem like a way to extract complexity from the alternatives themselves (which I think is a good thing) but at the expense of eating up cpu_req_feature bits... By itself, it doesn't help with precedence, but it may better allow us to deal with some of the precedence in cpufeature.c, since the alternative would operate based on the pseudo cpufeature rather than on the individual capabilities that the pseudo cpufeature depends on.

I tried to come up with a suggestion for what to do about precedence, but everything I thought up felt a bit horrific tbh.
The thing that fits the current model best is just allowing cpu vendors to add, yet more, "errata" that pick the variant that works best for their implementation... Although I'd be worried about ballooning some of these ALT_FOO macros out to a massive degree with that sort of approach.

Quoted 7 lines

If my assumption/understanding holds, moving decision making out of the alternative seems like it would better provision for scenarios like that? I dunno, maybe that is whatever the corollary of "premature optimisation" is for this discussion.

That's my unsolicited ? 0.02, hopefully I wasn't off-base with the assumptions I made.

The order in which an alternative is added to the macro does matter, right? At least, that's how I thought it worked and hope I've not had an incorrect interpretation there all along... I wasn't until I started reading your patch and couldn't understand why you had a construct that looked like

Quoted 19 lines

if (zbb && !fast_unaligned)
...
else if (zbb && fast_unaligned)
...

rather than just inverting the order and dropping the !fast_unaligned that I realised I might have a gap in my understanding after all..

Quoted 11 lines

Heiko, I figure you've got some sort of WIP stuff for this anyway since you're interested in the fast unaligned? How close are you to posting any of that?

While I think of it, w.r.t. extension versus (pseudo)cpufeature etc naming, it may make sense to call the functions that this series adds in patch 6 has_cpufeature_{un,}likely(), no matter what decision gets made here?
IMO using cpufeature seems to make more sense for a general use API that may be used later on for the likes of unaligned access, even if initially it is not used for anything other than extensions.

Today at [1] we talked a bit about the various bits going on here. I'll attempt to summarise what I remember, but I meant to do this several hours ago and am likely to make a hames of it.

For Zbb/unaligned stuff, the sentiment was along the lines of there needing to be a performance benefit to justify the inclusion. Some of us have HW that is (allegedly) capable of Zbb, and, if that's the case, will give it a go.
I think it was similar for unaligned, since there is nothing yet that supports this behaviour, we should wait until a benefit is demonstrable.

On the subject of grouping extension/non-extension capabilities into a single cpufeature, Palmer mentioned that GCC does something similar, for the likes of the Ventana vendor extensions, that are unlikely to be present in isolation.
Those are (or were?) probed as a group of extensions rather than individually.
I think it was said it'd make sense for us to unify extensions that will only ever appear together single psuedo cpufeature too.

For the bitfield approach versus creating pseudo cpufeatures discussion & how to deal with that in alternatives etc, I'm a bit less sure what the outcome was.
IIRC, nothing concrete was said about either approach, but maybe it was implied that we should do as GCC does, only grouping things that won't ever been seen apart.
Figuring that out seems to have been punted down the road, as the inclusion of our only current example of this (Zbb + unaligned) is dependant on hardware showing up that actually benefits from it.

The plan then seemed to be press ahead with this series & test the benefits of the Zbb str* functions in Zbb capable hardware before making a decision there.

Hopefully I wasn't too far off with that summary...

Thanks,
Conor.

1 - https://lore.kernel.org/linux-riscv/mhng-775d4068-6c1e-48a4-a1dc-b4a76ff26bb3 at palmer-ri-x1c9a/

Quoted 5 lines · Conor Dooley

Hey!

I guess here is the right place to follow up on all of this stuff...

On Sat, Jan 14, 2023 at 08:32:37PM +0000, Conor Dooley wrote:

Quoted 7 lines

Today at [1] we talked a bit about the various bits going on here. I'll attempt to summarise what I remember, but I meant to do this several hours ago and am likely to make a hames of it.

For Zbb/unaligned stuff, the sentiment was along the lines of there needing to be a performance benefit to justify the inclusion. Some of us have HW that is (allegedly) capable of Zbb, and, if that's the

Quoted 8 lines

case, will give it a go.
I think it was similar for unaligned, since there is nothing yet that supports this behaviour, we should wait until a benefit is demonstrable.

On the subject of grouping extension/non-extension capabilities into a single cpufeature, Palmer mentioned that GCC does something similar, for the likes of the Ventana vendor extensions, that are unlikely to be present in isolation.

Quoted 15 lines

Those are (or were?) probed as a group of extensions rather than individually.
I think it was said it'd make sense for us to unify extensions that will only ever appear together single psuedo cpufeature too.

For the bitfield approach versus creating pseudo cpufeatures discussion & how to deal with that in alternatives etc, I'm a bit less sure what the outcome was.
IIRC, nothing concrete was said about either approach, but maybe it was implied that we should do as GCC does, only grouping things that won't ever been seen apart.
Figuring that out seems to have been punted down the road, as the inclusion of our only current example of this (Zbb + unaligned) is dependant on hardware showing up that actually benefits from it.

Quoted 5 lines

The plan then seemed to be press ahead with this series & test the benefits of the Zbb str* functions in Zbb capable hardware before making a decision there.

Hopefully I wasn't too far off with that summary...

This matches my recollection. Thanks for the summary, Conor.

Quoted 15 lines · Heiko St?bner

Hi Jisheng.

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

Quoted 7 lines

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

I agree that this needs to be addressed and Jisheng also raised this yesterday here [*]. It seems we need the concept of cpufeatures, which may be extensions or non-extensions.

[*] https://lore.kernel.org/all/Y77xyNPNqnFQUqAx at xhacker/

Quoted 7 lines

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

Quoted 2 lines

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

One possible approach may be to combine extensions/non-extensions at boot time into pseudo-cpufeatures. Then, alternatives can continue attaching to a single "feature". (I'm not saying that's a better approach than the bitmap, I'm just suggesting it as something else to consider.)

Thanks,
drew

Quoted 23 lines

In my optimization quest, I found that it's actually pretty neat to convert the errata-id for cpufeatures to a bitfield [1], because then it's possible to just combine extensions into said bitfield [2]:

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

So I really feel this would limit us quite a bit.

Heiko

[0] https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=riscv-hwprobe-v1&id=510c491cb9d87dcbdc91c63558dc704968723240
[1] https://github.com/mmind/linux-riscv/commit/f57a896122ee7e666692079320fc35829434cf96
[2] https://github.com/mmind/linux-riscv/commit/8cef615dab0c00ad68af2651ee5b93d06be17f27#diff-194cb8a86f9fb9b03683295f21c8f46b456a9f94737f01726ddbcbb9e3aace2cR12

Hi Jisheng.

Am Mittwoch, 11. Januar 2023, 18:10:19 CET schrieb Jisheng Zhang:

Quoted 11 lines

riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/errata_list.h |  9 ++--
 arch/riscv/kernel/cpufeature.c       | 63 ++++------------------------
 2 files changed, 11 insertions(+), 61 deletions(-)

hmmm ... I do see a somewhat big caveat for this. and would like to take back my Reviewed-by for now

With this change we would limit the patchable cpufeatures to actual riscv extensions. But cpufeatures can also be soft features like how performant the core handles unaligned accesses.

See Palmer's series [0].

Also this essentially codifies that each ALTERNATIVE can only ever be attached to exactly one extension.

But contrary to vendor-errata, it is very likely that we will need combinations of different extensions for some alternatives in the future.

In my optimization quest, I found that it's actually pretty neat to convert the errata-id for cpufeatures to a bitfield [1], because then it's possible to just combine extensions into said bitfield [2]:

ALTERNATIVE_2("nop",
"j strcmp_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB, "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

[the additional field there models a "not" component]

So I really feel this would limit us quite a bit.

Heiko

[0] https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=riscv-hwprobe-v1&id=510c491cb9d87dcbdc91c63558dc704968723240
[1] https://github.com/mmind/linux-riscv/commit/f57a896122ee7e666692079320fc35829434cf96
[2] https://github.com/mmind/linux-riscv/commit/8cef615dab0c00ad68af2651ee5b93d06be17f27#diff-194cb8a86f9fb9b03683295f21c8f46b456a9f94737f01726ddbcbb9e3aace2cR12

Switch has_fpu() from statich branch to the new helper

riscv_has_extension_likely().

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

---
 arch/riscv/include/asm/switch_to.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/riscv/include/asm/switch_to.h +2 -1

index 11463489fec6..60f8ca01d36e 100644
@@ -59,7 +59,8 @@ static inline void __switch_to_aux(struct task_struct *prev,
 
 static __always_inline bool has_fpu(void)
 {
-	return static_branch_likely(&riscv_isa_ext_keys[RISCV_ISA_EXT_KEY_FPU]);
+	return riscv_has_extension_likely(RISCV_ISA_EXT_f) ||
+		riscv_has_extension_likely(RISCV_ISA_EXT_d);
 }
 #else
 static __always_inline bool has_fpu(void) { return false; }

Signature · 7 lines

2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Instead of using absolute addresses for both the old instrucions and the alternative instructions, use offsets relative to the alt_entry values. So this not only cuts the size of the alternative entry, but also meets the prerequisite for patching alternatives in the vDSO, since absolute alternative entries are subject to dynamic relocation, which is incompatible with the vDSO building.

Signed-off-by Jisheng Zhang <[email protected]>

---
 arch/riscv/errata/sifive/errata.c           |  4 +++-
 arch/riscv/errata/thead/errata.c            | 11 ++++++++---
 arch/riscv/include/asm/alternative-macros.h | 20 ++++++++++----------
 arch/riscv/include/asm/alternative.h        | 12 ++++++------
 arch/riscv/kernel/cpufeature.c              |  8 +++++---
 5 files changed, 32 insertions(+), 23 deletions(-)

arch/riscv/errata/sifive/errata.c +0 -0

index 1031038423e7..0e537cdfd324 100644

arch/riscv/errata/sifive/errata.c +1 -0

+					  alt->alt_len);
 			cpu_apply_errata |= tmp;
 		}
 	}

arch/riscv/errata/thead/errata.c +8 -3

index fac5742d1c1e..d56d76a529b5 100644
@@ -87,6 +87,7 @@ void __init_or_module thead_errata_patch_func(struct alt_entry *begin, struct al
 	struct alt_entry *alt;
 	u32 cpu_req_errata = thead_errata_probe(stage, archid, impid);
 	u32 tmp;
+	void *oldptr, *altptr;
 
 	for (alt = begin; alt < end; alt++) {
 		if (alt->vendor_id != THEAD_VENDOR_ID)

@@ -96,12 +97,16 @@ void __init_or_module thead_errata_patch_func(struct alt_entry *begin, struct al
 
 		tmp = (1U << alt->errata_id);
 		if (cpu_req_errata & tmp) {
+			oldptr = (void *)&alt->old_offset + alt->old_offset;
+			altptr = (void *)&alt->alt_offset + alt->alt_offset;
+
 			/* On vm-alternatives, the mmu isn't running yet */
 			if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
-				memcpy((void *)__pa_symbol(alt->old_ptr),
-				       (void *)__pa_symbol(alt->alt_ptr), alt->alt_len);
+				memcpy((void *)__pa_symbol(oldptr),
+				       (void *)__pa_symbol(altptr),
+				       alt->alt_len);
 			else
-				patch_text_nosync(alt->old_ptr, alt->alt_ptr, alt->alt_len);
+				patch_text_nosync(oldptr, altptr, alt->alt_len);
 		}
 	}
 

arch/riscv/include/asm/alternative-macros.h +0 -0

index 7226e2462584..3c3ca65e521b 100644
@@ -7,11 +7,11 @@
 #ifdef __ASSEMBLY__
 
 .macro ALT_ENTRY oldptr newptr vendor_id errata_id new_len

arch/riscv/include/asm/alternative-macros.h +5 -5

 .endm
 
 .macro ALT_NEW_CONTENT vendor_id, errata_id, enable = 1, new_c : vararg

@@ -59,11 +59,11 @@
 #include <linux/stringify.h>
 
 #define ALT_ENTRY(oldptr, newptr, vendor_id, errata_id, newlen)		\
-	RISCV_PTR " " oldptr "\n"					\
-	RISCV_PTR " " newptr "\n"					\
-	REG_ASM " " vendor_id "\n"					\
-	REG_ASM " " newlen "\n"						\
-	".word " errata_id "\n"
+	".long	((" oldptr ") - .) \n"					\
+	".long	((" newptr ") - .) \n"					\
+	".short	" vendor_id "\n"					\
+	".short	" newlen "\n"						\
+	".long	" errata_id "\n"
 
 #define ALT_NEW_CONTENT(vendor_id, errata_id, enable, new_c)		\
 	".if " __stringify(enable) " == 1\n"				\

arch/riscv/include/asm/alternative.h +0 -0

index 1bd4027d34ca..b6050a235f50 100644

arch/riscv/include/asm/alternative.h +5 -0

+	s32 alt_offset;		/* offset relative to replacement instruction or data */
+	u16 vendor_id;		/* cpu vendor id */
+	u16 alt_len;		/* The replacement size */
+	u32 errata_id;		/* The errata id */
+};
 
 struct errata_checkfunc_id {
 	unsigned long vendor_id;

arch/riscv/kernel/cpufeature.c +5 -3

index 6db8b31d9149..c394cde2560b 100644
@@ -280,6 +280,7 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
 						  unsigned int stage)
 {
 	struct alt_entry *alt;
+	void *oldptr, *altptr;
 
 	if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
 		return;

@@ -293,12 +294,13 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
 			continue;
 		}
 
+		oldptr = (void *)&alt->old_offset + alt->old_offset;
+		altptr = (void *)&alt->alt_offset + alt->alt_offset;
 		if (!__riscv_isa_extension_available(NULL, alt->errata_id))
 			continue;
 
-		patch_text_nosync(alt->old_ptr, alt->alt_ptr, alt->alt_len);
-		riscv_alternative_fix_offsets(alt->old_ptr, alt->alt_len,
-					      alt->old_ptr - alt->alt_ptr);
+		patch_text_nosync(oldptr, altptr, alt->alt_len);
+		riscv_alternative_fix_offsets(oldptr, alt->alt_len, oldptr - altptr);
 	}
 }
 #endif

Signature · 1 line

2.38.1

Instead of using absolute addresses for both the old instrucions and the alternative instructions, use offsets relative to the alt_entry values. So this not only cuts the size of the alternative entry, but also meets the prerequisite for patching alternatives in the vDSO, since absolute alternative entries are subject to dynamic relocation, which is incompatible with the vDSO building.

Signed-off-by Jisheng Zhang <[email protected]>

---
 arch/riscv/errata/sifive/errata.c           |  4 +++-
 arch/riscv/errata/thead/errata.c            | 11 ++++++++---
 arch/riscv/include/asm/alternative-macros.h | 20 ++++++++++----------
 arch/riscv/include/asm/alternative.h        | 12 ++++++------
 arch/riscv/kernel/cpufeature.c              |  8 +++++---
 5 files changed, 32 insertions(+), 23 deletions(-)

arch/riscv/errata/sifive/errata.c +0 -0

index 1031038423e7..0e537cdfd324 100644

arch/riscv/include/asm/alternative.h +0 -0

index 1bd4027d34ca..b6050a235f50 100644
@@ -31,12 +31,12 @@ void riscv_alternative_fix_offsets(void *alt_ptr, unsigned int len,
 				   int patch_offset);

Make it possible to use alternatives in the vDSO, so that better implementations can be used if possible.

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Guo Ren <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

---
 arch/riscv/include/asm/vdso.h     |  4 ++++
 arch/riscv/kernel/alternative.c   | 25 +++++++++++++++++++++++++
 arch/riscv/kernel/vdso.c          |  5 -----
 arch/riscv/kernel/vdso/vdso.lds.S |  7 +++++++
 4 files changed, 36 insertions(+), 5 deletions(-)

arch/riscv/include/asm/vdso.h +4 -0

index a7644f46d0e5..f891478829a5 100644
@@ -28,8 +28,12 @@
 #define COMPAT_VDSO_SYMBOL(base, name)						\
 	(void __user *)((unsigned long)(base) + compat__vdso_##name##_offset)
 
+extern char compat_vdso_start[], compat_vdso_end[];
+
 #endif /* CONFIG_COMPAT */
 
+extern char vdso_start[], vdso_end[];
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* CONFIG_MMU */

arch/riscv/kernel/alternative.c +25 -0

index 3d4f1f32c7f6..a883a309139f 100644
@@ -11,7 +11,9 @@
 #include <linux/cpu.h>
 #include <linux/uaccess.h>
 #include <asm/alternative.h>
+#include <asm/module.h>
 #include <asm/sections.h>
+#include <asm/vdso.h>
 #include <asm/vendorid_list.h>
 #include <asm/sbi.h>
 #include <asm/csr.h>

@@ -160,6 +162,27 @@ static void __init_or_module _apply_alternatives(struct alt_entry *begin,
 				stage);
 }
 
+static void __init apply_vdso_alternatives(void)
+{
+	const struct elf64_hdr *hdr;
+	const struct elf64_shdr *shdr;
+	const struct elf64_shdr *alt;
+	struct alt_entry *begin, *end;
+
+	hdr = (struct elf64_hdr *)vdso_start;
+	shdr = (void *)hdr + hdr->e_shoff;
+	alt = find_section(hdr, shdr, ".alternative");
+	if (!alt)
+		return;
+
+	begin = (void *)hdr + alt->sh_offset,
+	end = (void *)hdr + alt->sh_offset + alt->sh_size,
+
+	_apply_alternatives((struct alt_entry *)begin,
+			    (struct alt_entry *)end,
+			    RISCV_ALTERNATIVES_BOOT);
+}
+
 void __init apply_boot_alternatives(void)
 {
 	/* If called on non-boot cpu things could go wrong */

@@ -168,6 +191,8 @@ void __init apply_boot_alternatives(void)
 	_apply_alternatives((struct alt_entry *)__alt_start,
 			    (struct alt_entry *)__alt_end,
 			    RISCV_ALTERNATIVES_BOOT);
+
+	apply_vdso_alternatives();
 }
 
 /*

arch/riscv/kernel/vdso.c +0 -5

index e410275918ac..4e631c098f4d 100644
@@ -22,11 +22,6 @@ struct vdso_data {
 };
 #endif
 
-extern char vdso_start[], vdso_end[];
-#ifdef CONFIG_COMPAT
-extern char compat_vdso_start[], compat_vdso_end[];
-#endif
-
 enum vvar_pages {
 	VVAR_DATA_PAGE_OFFSET,
 	VVAR_TIMENS_PAGE_OFFSET,

arch/riscv/kernel/vdso/vdso.lds.S +7 -0

index 150b1a572e61..4a0606633290 100644
@@ -40,6 +40,13 @@ SECTIONS
 	. = 0x800;
 	.text		: { *(.text .text.*) }		:text
 
+	. = ALIGN(4);
+	.alternative : {
+		__alt_start = .;
+		*(.alternative)
+		__alt_end = .;
+	}
+
 	.data		: {
 		*(.got.plt) *(.got)
 		*(.data .data.* .gnu.linkonce.d.*)

Signature · 1 line

2.38.1

Hey Jisheng,

Quoted 3 lines · Jisheng Zhang

Make it possible to use alternatives in the vDSO, so that better implementations can be used if possible.

Quoted 3 lines

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Guo Ren <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

FYI, from this patch onwards the rv32 build is broken. Should be reproduceable with the in-tree rv32_defconfig.

Unfortunately no logs for you, I've got a CI bug to fix!

Switch cpu_relax() from static branch to the new helper riscv_has_extension_likely()

Signed-off-by Jisheng Zhang <[email protected]>

Reviewed-by Andrew Jones <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

Reviewed-by Guo Ren <[email protected]>

---
 arch/riscv/include/asm/vdso/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/riscv/include/asm/vdso/processor.h +1 -1

index fa70cfe507aa..edf0e25e43d1 100644
@@ -10,7 +10,7 @@
 
 static inline void cpu_relax(void)
 {
-	if (!static_branch_likely(&riscv_isa_ext_keys[RISCV_ISA_EXT_KEY_ZIHINTPAUSE])) {
+	if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZIHINTPAUSE)) {
 #ifdef __riscv_muldiv
 		int dummy;
 		/* In lieu of a halt instruction, induce a long-latency stall. */

Signature · 7 lines

2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv