Legacy instruction emulation for arm64

According to the ARM ARMv7, explicit barriers are necessary when using synchronisation primitives such as SWP{B}. The use of these instructions does not automatically imply a barrier and any ordering requirements by the software must be explicitly expressed with the use of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Cc Russell King <[email protected]>

Signed-off-by Punit Agrawal <[email protected]>

---
 arch/arm/kernel/swp_emulate.c |   15 ---------------
 1 file changed, 15 deletions(-)

According to the ARM ARMv7, explicit barriers are necessary when using synchronisation primitives such as SWP{B}. The use of these instructions does not automatically imply a barrier and any ordering requirements by the software must be explicitly expressed with the use of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Cc Russell King <[email protected]>

Signed-off-by Punit Agrawal <[email protected]>

Quoted 8 lines · Punit Agrawal

According to the ARM ARMv7, explicit barriers are necessary when using synchronisation primitives such as SWP{B}. The use of these instructions does not automatically imply a barrier and any ordering requirements by the software must be explicitly expressed with the use of suitable barriers.

Based on this, remove the barriers from SWP{B} emulation.

Quoted 2 lines

Cc Russell King <[email protected]>

Signed-off-by Punit Agrawal <[email protected]>

This patch is independent to the SWP emulation for arm64 series. Unless Russell has any objections, you should send it to his patch system (git send-email to patches at arm.linux.org.uk with "KernelVersion: v3..." after the commit log; I hope Russell drops the KernelVersion requirement some day ;)).

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

arch/arm64/kernel/traps.c +6 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+	struct undef_hook *hook;
+	unsigned long flags;
+	u32 instr;
+	int (*fn)(struct pt_regs *regs, u32 instr) = NULL;

arch/arm64/kernel/traps.c +14 -0

+	get_user(instr, (u32 __user *)pc);
+	instr = le32_to_cpu(instr);
+
+	raw_spin_lock_irqsave(&undef_lock, flags);
+	list_for_each_entry(hook, &undef_hook, node)
+		if ((instr & hook->instr_mask) == hook->instr_val &&
+			(regs->pstate & hook->pstate_mask) == hook->pstate_val)
+			fn = hook->fn;
+
+	raw_spin_unlock_irqrestore(&undef_lock, flags);
+
+	return fn ? fn(regs, instr) : 1;
+}
+
 asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 {
 	siginfo_t info;

Hi Punit,

Quoted 6 lines · Punit Agrawal

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

[...]

Quoted 13 lines

(quoted diff) +13 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+     struct undef_hook *hook;
+     unsigned long flags;
+     u32 instr;
+     int (*fn)(struct pt_regs *regs, u32 instr) = NULL;
+     void __user *pc = (void __user *)instruction_pointer(regs);
+
+     /*
+      * Currently, undefined instruction patching is only supported
+      * for user mode. Also, as we're not emulating any thumb
+      * instructions lets not add thumb instruction decoding until
+      * it is needed.

Review

Quoted 3 lines

(quoted diff) +3 -0

+      */
+     if (!compat_user_mode(regs) || compat_thumb_mode(regs))
+             return 1;

What do you mean by `undefined instruction patching'? I don't see anything in the mechanism that means this can't be reused for kernel code, then we just register the SWP emulation hook for userspace only using the mode (like we do for kgdb).

Quoted 18 lines

(quoted diff) +14 -0

+     get_user(instr, (u32 __user *)pc);
+     instr = le32_to_cpu(instr);
+
+     raw_spin_lock_irqsave(&undef_lock, flags);
+     list_for_each_entry(hook, &undef_hook, node)
+             if ((instr & hook->instr_mask) == hook->instr_val &&
+                     (regs->pstate & hook->pstate_mask) == hook->pstate_val)
+                     fn = hook->fn;
+
+     raw_spin_unlock_irqrestore(&undef_lock, flags);
+
+     return fn ? fn(regs, instr) : 1;
+}
+
 asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 {
      siginfo_t info;

Review asmlinkage void __exception do_undefinstr(struct pt_regs *regs) · line 333

Quoted 5 lines

(quoted diff) +2 -0

@@ -266,6 +329,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
      if (!aarch32_break_handler(regs))
              return;
 
+     if (call_undef_hook(regs) == 0)
+             return;

I'd like to reuse this hook for the aarch32 break hooks (you can see the direct call in the context above). That means adding support for thumb after all. Is there a reason you've been avoiding that?

Will

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

Quoted 23 lines · Will Deacon

Quoted 6 lines · Punit Agrawal

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

[...]

Quoted 13 lines

(quoted diff) +13 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+     struct undef_hook *hook;
+     unsigned long flags;
+     u32 instr;
+     int (*fn)(struct pt_regs *regs, u32 instr) = NULL;
+     void __user *pc = (void __user *)instruction_pointer(regs);
+
+     /*
+      * Currently, undefined instruction patching is only supported
+      * for user mode. Also, as we're not emulating any thumb
+      * instructions lets not add thumb instruction decoding until
+      * it is needed.

Quoted 9 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+      */
+     if (!compat_user_mode(regs) || compat_thumb_mode(regs))
+             return 1;

What do you mean by `undefined instruction patching'? I don't see anything in the mechanism that means this can't be reused for kernel code, then we just register the SWP emulation hook for userspace only using the mode (like we do for kgdb).

You need this patch in order to be able to return from an undef exception taken in EL1:

Quoted 36 lines · Ard Biesheuvel

Quoted 23 lines · Will Deacon

Quoted 6 lines · Punit Agrawal

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

[...]

Quoted 13 lines

(quoted diff) +13 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+     struct undef_hook *hook;
+     unsigned long flags;
+     u32 instr;
+     int (*fn)(struct pt_regs *regs, u32 instr) = NULL;
+     void __user *pc = (void __user *)instruction_pointer(regs);
+
+     /*
+      * Currently, undefined instruction patching is only supported
+      * for user mode. Also, as we're not emulating any thumb
+      * instructions lets not add thumb instruction decoding until
+      * it is needed.

Quoted 8 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+      */
+     if (!compat_user_mode(regs) || compat_thumb_mode(regs))
+             return 1;

What do you mean by `undefined instruction patching'? I don't see anything in the mechanism that means this can't be reused for kernel code, then we just register the SWP emulation hook for userspace only using the mode (like we do for kgdb).

You need this patch in order to be able to return from an undef exception taken in EL1:

arch/arm64/kernel/entry.S el1_undef: · line 295

Quoted 13 lines

arch/arm64/kernel/entry.S +3 -1

@@ -287,7 +287,9 @@ el1_undef:
         */
        enable_dbg
        mov     x0, sp
-       b       do_undefinstr
+       bl      do_undefinstr
+
+       kernel_exit 1
 el1_dbg:
        /*
         * Debug exception handling

Hmm, I'm surprised we don't already need something like this for KGDB...

Quoted 4 lines · Will Deacon

Quoted 3 lines · Ard Biesheuvel

You need this patch in order to be able to return from an undef exception taken in EL1:

Quoted 15 lines

arch/arm64/kernel/entry.S el1_undef: · line 295

Quoted 13 lines

arch/arm64/kernel/entry.S +3 -1

@@ -287,7 +287,9 @@ el1_undef:
         */
        enable_dbg
        mov     x0, sp
-       b       do_undefinstr
+       bl      do_undefinstr
+
+       kernel_exit 1
 el1_dbg:
        /*
         * Debug exception handling

Hmm, I'm surprised we don't already need something like this for KGDB...

We don't expect undef exceptions at EL1, so far they are fatal as we don't have any hooks for them. Doesn't KGDB use dedicated breakpoint instructions?

Hi Punit,

Quoted 6 lines · Punit Agrawal

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

[...]

Quoted 10 lines

arch/arm64/kernel/traps.c +10 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+	struct undef_hook *hook;
+	unsigned long flags;
+	u32 instr;
+	int (*fn)(struct pt_regs *regs, u32 instr) = NULL;
+	void __user *pc = (void __user *)instruction_pointer(regs);
+
+	/*
+	 * Currently, undefined instruction patching is only supported

arch/arm64/kernel/traps.c void arm64_notify_die(const char *str, struct pt_regs *regs, · line 307

Quoted 6 lines

arch/arm64/kernel/traps.c +6 -0

+	 * for user mode. Also, as we're not emulating any thumb
+	 * instructions lets not add thumb instruction decoding until
+	 * it is needed.
+	 */
+	if (!compat_user_mode(regs) || compat_thumb_mode(regs))
+		return 1;

What do you mean by `undefined instruction patching'?

I don't see anything
in the mechanism that means this can't be reused for kernel code, then we just register the SWP emulation hook for userspace only using the mode (like we do for kgdb).

Quoted 22 lines

arch/arm64/kernel/traps.c +14 -0

+	get_user(instr, (u32 __user *)pc);
+	instr = le32_to_cpu(instr);
+
+	raw_spin_lock_irqsave(&undef_lock, flags);
+	list_for_each_entry(hook, &undef_hook, node)
+		if ((instr & hook->instr_mask) == hook->instr_val &&
+			(regs->pstate & hook->pstate_mask) == hook->pstate_val)
+			fn = hook->fn;
+
+	raw_spin_unlock_irqrestore(&undef_lock, flags);
+
+	return fn ? fn(regs, instr) : 1;
+}
+
 asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 {
 	siginfo_t info;

@@ -266,6 +329,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 	if (!aarch32_break_handler(regs))
 		return;
 

arch/arm64/kernel/traps.c asmlinkage void __exception do_undefinstr(struct pt_regs *regs) · line 333

Quoted 2 lines

arch/arm64/kernel/traps.c +2 -0

+	if (call_undef_hook(regs) == 0)
+		return;

I'd like to reuse this hook for the aarch32 break hooks (you can see the direct call in the context above). That means adding support for thumb after all. Is there a reason you've been avoiding that?

Will

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

Quoted 8 lines · Will Deacon

Quoted 7 lines · Punit Agrawal

asmlinkage void __exception do_undefinstr(struct pt_regs *regs) {

arch/arm64/kernel/traps.c +0 -0

 	siginfo_t info;

@@ -266,6 +329,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 	if (!aarch32_break_handler(regs))
 		return;
 

Quoted 6 lines

arch/arm64/kernel/traps.c asmlinkage void __exception do_undefinstr(struct pt_regs *regs) · line 333

Quoted 2 lines

arch/arm64/kernel/traps.c +2 -0

+	if (call_undef_hook(regs) == 0)
+		return;

I'd like to reuse this hook for the aarch32 break hooks (you can see the direct call in the context above). That means adding support for thumb after all. Is there a reason you've been avoiding that?

None, other than to not add code before it's needed. I've just had a quick look at break handler and it looks pretty straight forward to fold that change in this set. Are you OK with that?

Quoted 26 lines · Will Deacon

Quoted 6 lines · Punit Agrawal

Add support to register hooks for undefined instructions. The handlers will be called when the undefined instruction and the processor state (as contained in pstate) match criteria used at registration.

Note: The patch only deals with ARM instruction encodings and needs fixing to handle thumb instructions as well.

[...]

Quoted 16 lines

arch/arm64/kernel/traps.c +16 -0

+static int call_undef_hook(struct pt_regs *regs)
+{
+	struct undef_hook *hook;
+	unsigned long flags;
+	u32 instr;
+	int (*fn)(struct pt_regs *regs, u32 instr) = NULL;
+	void __user *pc = (void __user *)instruction_pointer(regs);
+
+	/*
+	 * Currently, undefined instruction patching is only supported
+	 * for user mode. Also, as we're not emulating any thumb
+	 * instructions lets not add thumb instruction decoding until
+	 * it is needed.
+	 */
+	if (!compat_user_mode(regs) || compat_thumb_mode(regs))
+		return 1;

Quoted 4 lines

I don't see anything
in the mechanism that means this can't be reused for kernel code, then we just register the SWP emulation hook for userspace only using the mode (like we do for kgdb).

There's nothing in the mechanism to prevent it's use for kernel code. I was erring on the side of caution as I hadn't tested it.

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the emulation statistics via debugfs.

Quoted 5 lines · On Tuesday 26 August 2014 11:28:49 Punit Agrawal wrote:

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the emulation statistics via debugfs.

I'm not sure that putting this into debugfs is a good idea in this
case: while in general that is considered a good place for this kind of debugging information, we already have a precedent on arm32 for using procfs, and I see no reason to introduce an incompatible interface for arm64.

You also add an interface for disabling the feature at runtime, which we don't have on arm32, but that interface is not available if debugfs is disabled or not mounted. Maybe a sysctl would be more appropriate? That one could also be shared with arm32.

Quoted 13 lines · Arnd Bergmann

Quoted 5 lines · On Tuesday 26 August 2014 11:28:49 Punit Agrawal wrote:

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the emulation statistics via debugfs.

I'm not sure that putting this into debugfs is a good idea in this
case: while in general that is considered a good place for this kind of debugging information, we already have a precedent on arm32 for using procfs, and I see no reason to introduce an incompatible interface for arm64.

Quoted 4 lines

You also add an interface for disabling the feature at runtime, which we don't have on arm32, but that interface is not available if debugfs is disabled or not mounted. Maybe a sysctl would be more appropriate? That one could also be shared with arm32.

One advantage of using debugfs is that it provides a place to keep controls/statistics for any emulations that we add in the future, as opposed to littering them around in /proc or (worse) having a mixture of the two.

Quoted 19 lines · On Tuesday 26 August 2014 13:25:43 Will Deacon wrote:

Quoted 17 lines · Arnd Bergmann

Quoted 5 lines · On Tuesday 26 August 2014 11:28:49 Punit Agrawal wrote:

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the emulation statistics via debugfs.

I'm not sure that putting this into debugfs is a good idea in this
case: while in general that is considered a good place for this kind of debugging information, we already have a precedent on arm32 for using procfs, and I see no reason to introduce an incompatible interface for arm64.

You also add an interface for disabling the feature at runtime, which we don't have on arm32, but that interface is not available if debugfs is disabled or not mounted. Maybe a sysctl would be more appropriate? That one could also be shared with arm32.

Quoted 3 lines

One advantage of using debugfs is that it provides a place to keep controls/statistics for any emulations that we add in the future, as opposed to littering them around in /proc or (worse) having a mixture of the two.

Yes, I understood that. I just had another idea: would it make sense to use a tracepoint rather than a simple counter? That way you can actually see who is using those instructions with ftrace.

You still wouldn't get the files in the same place as the enable switch though. The easiest way to implement that switch btw would be a
module_param: It can be passed on the command line (using swp_emulate.enable=0) or at runtime by writing to /sys/module/swp_emulate/parameters/enable.

If we do both, there is no longer a need to have any debugfs file logic, which is also a plus.

Quoted 24 lines · Arnd Bergmann

Quoted 22 lines · On Tuesday 26 August 2014 13:25:43 Will Deacon wrote:

Quoted 13 lines · Arnd Bergmann

Quoted 5 lines · On Tuesday 26 August 2014 11:28:49 Punit Agrawal wrote:

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the emulation statistics via debugfs.

I'm not sure that putting this into debugfs is a good idea in this
case: while in general that is considered a good place for this kind of debugging information, we already have a precedent on arm32 for using procfs, and I see no reason to introduce an incompatible interface for arm64.

Quoted 4 lines

You also add an interface for disabling the feature at runtime, which we don't have on arm32, but that interface is not available if debugfs is disabled or not mounted. Maybe a sysctl would be more appropriate? That one could also be shared with arm32.

One advantage of using debugfs is that it provides a place to keep controls/statistics for any emulations that we add in the future, as opposed to littering them around in /proc or (worse) having a mixture of the two.

Quoted 3 lines

Yes, I understood that. I just had another idea: would it make sense to use a tracepoint rather than a simple counter? That way you can actually see who is using those instructions with ftrace.

That would also be useful for perf, where the plain `emulation fault' event can be a little too broad.

Quoted 9 lines

You still wouldn't get the files in the same place as the enable switch though. The easiest way to implement that switch btw would be a
module_param: It can be passed on the command line (using swp_emulate.enable=0) or at runtime by writing to /sys/module/swp_emulate/parameters/enable.

If we do both, there is no longer a need to have any debugfs file logic, which is also a plus.

Sounds good to me.

Will

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

I'll replace the counters with trace points.

There is still the pr_warn which informs the user about applications using legacy instructions. Hopefully, this should encourage updating the software.

Quoted 4 lines

Quoted 2 lines

If we do both, there is no longer a need to have any debugfs file logic, which is also a plus.

Sounds good to me.

Just a note: instead of being 'swp_emulate.enable=0' this'll be 'v7_obsolete.swp_emulate=0' and correspondingly for the other features.

Quoted 5 lines · Punit Agrawal

I'll replace the counters with trace points.

There is still the pr_warn which informs the user about applications using legacy instructions. Hopefully, this should encourage updating the software.

pr_warn_ratelimit() please. There is no point printing this all the time if nobody reads the messages.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

If we do both, there is no longer a need to have any debugfs file logic, which is also a plus.

Quoted 4 lines

Quoted 1 line

Sounds good to me.

Just a note: instead of being 'swp_emulate.enable=0' this'll be 'v7_obsolete.swp_emulate=0' and correspondingly for the other features.

It would be nice if the module name could be the same for arm32 and arm64, and I don't know if we want to rename swp_emulate.c to v7_obsolete.c on arm32.

Other than that, I have no opinion on the specific name of the module or the option.

Arnd

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

The SWP instruction was deprecated in the ARMv6 architecture, superseded by the LDREX/STREX family of instructions for load-linked/store-conditional operations. The ARMv7 multiprocessing extensions mandate that SWP/SWPB instructions are treated as undefined from reset, with the ability to enable them through the System Control Register SW bit. With ARMv8, the option to enable these instructions through System Control Register was dropped as well.

This patch ports the alternative solution to emulate the SWP and SWPB instructions using LDXR/STXR sequences from the arm port to arm64. Additionaly, the patch also proivdes support to log the

emulation statistics via debugfs.

Signed-off-by Punit Agrawal <[email protected]>

---
 arch/arm64/Kconfig              |   41 +++++++
 arch/arm64/include/asm/insn.h   |    9 ++
 arch/arm64/kernel/Makefile      |    1 +
 arch/arm64/kernel/insn.c        |   11 ++
 arch/arm64/kernel/v7_obsolete.c |  241 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 303 insertions(+)
 create mode 100644 arch/arm64/kernel/v7_obsolete.c

arch/arm64/Kconfig +0 -0

index c52894e..ba780b1 100644

arch/arm64/include/asm/insn.h +9 -0

index dc1f73b..2861cc6 100644
@@ -105,6 +105,15 @@ bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
 int aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt);
 int aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt);
+
+#ifdef CONFIG_V7_OBSOLETE
+#define RN_OFFSET	16
+#define RT_OFFSET	12
+#define RT2_OFFSET	 0
+
+u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
+#endif /* CONFIG_V7_OBSOLETE */
+
 #endif /* __ASSEMBLY__ */
 
 #endif	/* __ASM_INSN_H */

arch/arm64/kernel/insn.c +1 -0

@@ -302,3 +302,14 @@ u32 __kprobes aarch64_insn_gen_nop(void)
 {
 	return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP);
 }
+

The CP15 barrier instructions (CP15ISB, CP15DSB and CP15DMB) are deprecated in the ARMv7 architecture, superseded by ISB, DSB and DMB instructions respectively. Some implementations may provide support for these instructions which can then be enabled by setting the CP15BEN bit in the SCTLR in ARMv7 or SCTLR_EL1 in ARMv8. If not enabled, the encodings for these instructions become undefined.

To support legacy software that uses these instructions, this patch emulates the barrier instructions by installing an undefined instruction handler. The patch also adds a debugfs entry to track the occurrence of the deprecated barrier instructions. It is possible to runtime disable them from debugfs.

arch/arm64/kernel/v7_obsolete.c +21 -0

+
+static int cp15barrier_handler(struct pt_regs *regs, u32 instr)
+{
+	if (!cp15_barrier_enabled)
+		return -EFAULT;
+
+	perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, 1, regs, regs->pc);
+
+	switch (arm_check_condition(instr, regs->pstate)) {
+	case ARM_OPCODE_CONDTEST_PASS:
+		break;
+	case ARM_OPCODE_CONDTEST_FAIL:
+		/* Condition failed - return to next instruction */
+		goto ret;
+	case ARM_OPCODE_CONDTEST_UNCOND:
+		/* If unconditional encoding - not a barrier instruction */
+		return -EFAULT;
+	default:
+		return -EINVAL;
+	}
+

arch/arm64/kernel/v7_obsolete.c +7 -0

+/* data barrier */
+static struct undef_hook cp15db_hook = {
+	.instr_mask	= 0x0fff0fdf,
+	.instr_val	= 0x0e070f9a,
+	.pstate_mask	= COMPAT_PSR_MODE_MASK,
+	.pstate_val	= COMPAT_PSR_MODE_USR,
+	.fn		= cp15barrier_handler,

Quoted 8 lines · Punit Agrawal

arch/arm64/kernel/v7_obsolete.c +0 -0

index e9427cb..ed77889 100644
@@ -227,6 +227,94 @@ static void __init swp_emulation_init(void)
 		pr_notice("Registered SWP/SWPB emulation handler\n");
 }
 

arch/arm64/kernel/v7_obsolete.c static void __init swp_emulation_init(void) · line 230

Quoted 1 line

arch/arm64/kernel/v7_obsolete.c +1 -0

+static atomic_t cp15_barrier_count;

Should we add counters for each barrier type? It may be more informative.

Quoted 14 lines

arch/arm64/kernel/v7_obsolete.c +13 -0

+/* data barrier */
+static struct undef_hook cp15db_hook = {
+	.instr_mask	= 0x0fff0fdf,
+	.instr_val	= 0x0e070f9a,
+	.pstate_mask	= COMPAT_PSR_MODE_MASK,
+	.pstate_val	= COMPAT_PSR_MODE_USR,
+	.fn		= cp15barrier_handler,
+};
+
+/* instruction barrier */
+static struct undef_hook cp15isb_hook = {
+	.instr_mask	= 0x0fff0fff,
+	.instr_val	= 0x0e070f95,

arch/arm64/kernel/v7_obsolete.c static void __init swp_emulation_init(void) · line 288

Quoted 4 lines

arch/arm64/kernel/v7_obsolete.c +4 -0

+	.pstate_mask	= COMPAT_PSR_MODE_MASK,
+	.pstate_val	= COMPAT_PSR_MODE_USR,
+	.fn		= cp15barrier_handler,
+};

It now crossed my mind that these CP15 barriers are valid in Thumb-2 as well, same encoding. But we need the hook and the masks here to trap them.

Quoted 9 lines · Catalin Marinas

Quoted 8 lines · Punit Agrawal

arch/arm64/kernel/v7_obsolete.c +0 -0

index e9427cb..ed77889 100644
@@ -227,6 +227,94 @@ static void __init swp_emulation_init(void)
 		pr_notice("Registered SWP/SWPB emulation handler\n");
 }
 

Quoted 4 lines

arch/arm64/kernel/v7_obsolete.c static void __init swp_emulation_init(void) · line 230

Quoted 1 line

arch/arm64/kernel/v7_obsolete.c +1 -0

+static atomic_t cp15_barrier_count;

Should we add counters for each barrier type? It may be more informative.

Arnd proposed to use trace points instead of counters. I can emit different trace points for the different barrier types.