Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

[Russell King - ARM Linux]

On Tue, Apr 08, 2014 at 03:46:38AM +0000, Wuqixuan wrote:
> Second question is important for us, because the instruction of
> updation is too slow(about 100 cycles) in our chip, we want to remove
> the updation instruction for low latency reason, so need your opinion. 

What about it is slow - is the 100 cycles from the mcr itself?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

[Wuqixuan]

On Tue, Apr 14, 2014 at 03:30:00AM +0000, Russell King wrote:

>> Second question is important for us, because the instruction of
>> updation is too slow(about 100 cycles) in our chip, we want to remove
>> the updation instruction for low latency reason, so need your opinion.

> What about it is slow - is the 100 cycles from the mcr itself?

Yes, in our ARMv7 Cortex A15 SOC, only single mcr instruction need 
about 100 cycles, so we want to remove it. 
Can you help to give some idea about the risk to remove it ? 

Regards and Thanks  a lot.
Wuqixuan

Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

[Wuqixuan]

On Sat, Apr 05, 2014 at 5:43:00 PM +0800, Russell King wrote:

> This code in arch/arm/kernel/head-common.S:
> 
>         bicne   r4, r0, #CR_A                   @ Clear 'A' bit
>         stmneia r7, {r0, r4}                    @ Save control register values
> saves different values to cr_alignment and cr_no_alignment.  One always
> has the A bit cleared, the other may have the A bit set.
> For ARMv5 and older, we must have the A bit set while in the kernel so
> misaligned loads are aborted, so that they can be fixed up.  This
> behaviour is relied upon by the networking code amongst other places.

Thank you very much for your reply, King. 

Our chip is ARMv7, as per our observation, the cr_alignment and cr_no_alignment are the same, i think it's below code cause it: 

static int __init alignment_init(void) {
...
 /*
  * ARMv6 and later CPUs can perform unaligned accesses for
  * most single load and store instructions up to word size.
  * LDM, STM, LDRD and STRD still need to be handled.
  *
  * Ignoring the alignment fault is not an option on these
  * CPUs since we spin re-faulting the instruction without
  * making any progress.
  */         /*Actually, above comments are copied from 2.6.34, and code is from 3.10.18 */
#ifdef CONFIG_CPU_CP15
 if (cpu_is_v6_unaligned()) {
  cr_alignment &= ~CR_A;
  cr_no_alignment &= ~CR_A;
  set_cr(cr_alignment);
  ai_usermode = safe_usermode(ai_usermode, false);
 }
#endif
...
}

static bool cpu_is_v6_unaligned(void){
 return cpu_architecture() >= CPU_ARCH_ARMv6 && (cr_alignment & CR_U);
}

So whether it means:

1. In ARMv7 or later CPUs, CPU has the ability to handle the alignment automatically for some case, so cr_alignment and cr_no_alignment are the same, both clearing the A bit. 

2. Remove the updation for SCTLR every syscall,IRQ,exception has no risk. 
Second question is important for us, because the instruction of updation is too slow(about 100 cycles) in our chip, we want to remove the updation instruction for low latency reason, so need your opinion. 

Regards and Thanks a lot.
Wuqixuan. 

Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

[Russell King - ARM Linux]

On Sat, Apr 05, 2014 at 01:41:17PM +0800, qixuan wu wrote:
> Dear King, all,
> 
> If we enable CONFIG_ALIGNMENT_TRAP:

This code in arch/arm/kernel/head-common.S:

        bicne   r4, r0, #CR_A                   @ Clear 'A' bit
        stmneia r7, {r0, r4}                    @ Save control register values

saves different values to cr_alignment and cr_no_alignment.  One always
has the A bit cleared, the other may have the A bit set.

For ARMv5 and older, we must have the A bit set while in the kernel so
misaligned loads are aborted, so that they can be fixed up.  This
behaviour is relied upon by the networking code amongst other places.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Help for doubt about why update SCTLR by cr_alignment every syscall,IRQ,exception ?

[qixuan wu]

Dear King, all,

If we enable CONFIG_ALIGNMENT_TRAP:

1. I don't know why each syscall and user_entry for IRQ or exception,
need update SCTLR using cr_alignment.
(below code is from kernel 3.10.18 for ARM SMP)

1) First scenario, each syscall will reset the SCTLR
   using cr_alignment.

ENTRY(vector_swi)
  ....

#ifdef CONFIG_ALIGNMENT_TRAP
    ldr    ip, __cr_alignment
    ldr    ip, [ip]
    mcr    p15, 0, ip, c1, c0      @ update SCTLR
#endif
  ....
ENDPROC(vector_swi)

2) Second scenario, each IRQ or exception to the user space,
   will reset the SCTLR using cr_alignment.

    .macro    usr_entry
  ....
    @ Enable the alignment trap while in kernel mode
    alignment_trap r0    @ ******** Here is a macro which will update
SCTLR *********
  ....
    .endm

2. Actually, I search in the code, SCTLR is initialized during
system init in some place, after that only do_alignment()
will change the value to cr_no_alignment, but cr_no_alignment
seems like always be same as cr_alignment.

static int __init alignment_init(void) {
...
        cr_alignment &= ~CR_A;
        cr_no_alignment &= ~CR_A;
        set_cr(cr_alignment);
...
}

In some case:
static int __init early_cachepolicy(char *p){
....
    cr_alignment &= ~cache_policies[i].cr_mask;
    cr_no_alignment &= ~cache_policies[i].cr_mask;
....
    set_cr(cr_alignment);
}

do_alignment(){
...
    set_cr(cr_no_alignment);
...
}

3. That means after system init, SCTLR will not be changed.

So is there anyone who has idea about:

1) Why need update SCTLR on above two scenarios?
2) If I remove the updation on above two scenarios, is there
any risk ?

Any comments is welcome and helpful.

Regards and Thanks a lot,
Wuqixuan.