Linux Interrupt Context maps to ARM CPSR.mode = IRQ

Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Mj Embd]

Hi,

As per a lot of linux documentation some components work in process
context and some work in interrupt context.

If we try to map these contexts to ARM processor modes then is it
safely to assume that
Process Context : CPSR.mode = SVC
Interrupt Context : CPSR.mode = IRQ

If not how to define interrupt context properly. Confusing at times.

-- 
-mj

Re: Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Mj Embd]

Adding Marc to comment
Marc Please clarify the doubt



On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd@gmail.com> wrote:
> Hi,
>
> As per a lot of linux documentation some components work in process
> context and some work in interrupt context.
>
> If we try to map these contexts to ARM processor modes then is it
> safely to assume that
> Process Context : CPSR.mode = SVC
> Interrupt Context : CPSR.mode = IRQ
>
> If not how to define interrupt context properly. Confusing at times.
>
> --
> -mj



-- 
-mj

Re: Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Marc Zyngier]

On 2014-05-02 13:34, Mj Embd wrote:
> Adding Marc to comment
> Marc Please clarify the doubt
>
>
>
> On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd@gmail.com> wrote:
>> Hi,
>>
>> As per a lot of linux documentation some components work in process
>> context and some work in interrupt context.
>>
>> If we try to map these contexts to ARM processor modes then is it
>> safely to assume that
>> Process Context : CPSR.mode = SVC
>> Interrupt Context : CPSR.mode = IRQ
>>
>> If not how to define interrupt context properly. Confusing at times.

Well, none of this is completely true.

Process context exists both in USR (process in user mode) and SVC 
(process in kernel mode, executing a syscall for example).

As for interrupts, the processor indeed starts executing the interrupt 
in IRQ mode, but this is a useless complication as far as Linux is 
concerned, and we quickly switch to SVC (see the definition of the 
vector_stub macro in arch/arm/kernel/entry-armv.S).

Hope this helps.

         M.
-- 
Fast, cheap, reliable. Pick two.

Re: Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Mj Embd]

On Fri, May 2, 2014 at 7:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 2014-05-02 13:34, Mj Embd wrote:
>>
>> Adding Marc to comment
>> Marc Please clarify the doubt
>>
>>
>>
>> On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> As per a lot of linux documentation some components work in process
>>> context and some work in interrupt context.
>>>
>>> If we try to map these contexts to ARM processor modes then is it
>>> safely to assume that
>>> Process Context : CPSR.mode = SVC
>>> Interrupt Context : CPSR.mode = IRQ
>>>
>>> If not how to define interrupt context properly. Confusing at times.
>
>
> Well, none of this is completely true.
>
> Process context exists both in USR (process in user mode) and SVC (process
> in kernel mode, executing a syscall for example).
>
> As for interrupts, the processor indeed starts executing the interrupt in
> IRQ mode, but this is a useless complication as far as Linux is concerned,

I didn't understood the term useless here, I hope it is not about the
question itself.

> and we quickly switch to SVC (see the definition of the vector_stub macro in
> arch/arm/kernel/entry-armv.S).
>
So what is the mode of the processor when Linux is executing in the
Academic / Bookish Term "Interrupt Context"
There is a function called in_interrupt which tells if linux is in
interrupt context.
But How to define/quantify Interrupt Context as a whole

Also, Some texts say there are two contexts Hard IRQ Context , Soft IRQ Context.
HardIRQ = interrupts Disabled , (possibly CPSR.I=1, mode=IRQ)
SoftIRQ = interrupts Enabled , (possibly CPSR.I=0, mode=IRQ)

SoftIRQs when executed from Ksoftirqd daemon  (possibly CPSR.I=0, mode=SVC)

We have a client query on this.

> Hope this helps.
>
>         M.
> --
> Fast, cheap, reliable. Pick two.



-- 
-mj

Re: Linux Interrupt Context maps to ARM CPSR.mode = IRQ

[Marc Zyngier]

On Fri, May 02 2014 at  3:07:55 pm BST, Mj Embd <mj.embd@gmail.com> wrote:
> On Fri, May 2, 2014 at 7:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 2014-05-02 13:34, Mj Embd wrote:
>>>
>>> Adding Marc to comment
>>> Marc Please clarify the doubt
>>>
>>>
>>>
>>> On Fri, May 2, 2014 at 5:15 PM, Mj Embd <mj.embd@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> As per a lot of linux documentation some components work in process
>>>> context and some work in interrupt context.
>>>>
>>>> If we try to map these contexts to ARM processor modes then is it
>>>> safely to assume that
>>>> Process Context : CPSR.mode = SVC
>>>> Interrupt Context : CPSR.mode = IRQ
>>>>
>>>> If not how to define interrupt context properly. Confusing at times.
>>
>>
>> Well, none of this is completely true.
>>
>> Process context exists both in USR (process in user mode) and SVC (process
>> in kernel mode, executing a syscall for example).
>>
>> As for interrupts, the processor indeed starts executing the interrupt in
>> IRQ mode, but this is a useless complication as far as Linux is concerned,
>
> I didn't understood the term useless here, I hope it is not about the
> question itself.

Not about the question at all. The IRQ mode itself is a useless
complication for Linux.

>> and we quickly switch to SVC (see the definition of the vector_stub
>> macro in arch/arm/kernel/entry-armv.S).
>>
> So what is the mode of the processor when Linux is executing in the
> Academic / Bookish Term "Interrupt Context"

As I said above, Linux runs mostly in SVC when the interrupt code is
executed.

> There is a function called in_interrupt which tells if linux is in
> interrupt context.
> But How to define/quantify Interrupt Context as a whole

You're in "Interrupt Context" when executing an interrupt. That's the
very definition. Interrupts are disabled, you cannot sleep, you cannot
be preempted. The mode the processor is in at that time is an orthogonal
issue, and different architectures implement this requirement
differently.

> Also, Some texts say there are two contexts Hard IRQ Context , Soft IRQ Context.
> HardIRQ = interrupts Disabled , (possibly CPSR.I=1, mode=IRQ)
> SoftIRQ = interrupts Enabled , (possibly CPSR.I=0, mode=IRQ)

Again, it you care to *read* the code, you'll notice that we're in IRQ
mode for about 12 instructions per interrupt. The actual interrupt
handling code runs in SVC.

> SoftIRQs when executed from Ksoftirqd daemon  (possibly CPSR.I=0, mode=SVC)
>
> We have a client query on this.

Awesome!

	M.
-- 
AAAFNRAA