Re: Interrupt flow in the NetBSD kernel

[Matt Thomas <matt%3am-software.com@localhost>]

> On Jun 21, 2015, at 7:30 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> 
> I have got few questions regarding the interrupt flow in the kernel.
> Please tell whether my understanding is correct.

You are confusing interrupts with exceptions.  Interrupts are 
asynchronous events.  Exceptions are (usually) synchronous and
are the result of an instruction.

> There are software and hardware interrupts.
> Part of the hardware interrupts are maskable with the spl(9) levels.
> Some are unmaskable and must be handled unconditionally, like the
> exception data abort from ARM.

data abort is a synchronous exception, not an interrupt.

> Hardware interrupts are handled by the hardware interrupt handler.
> System calls (syscalls) and softint(9) are software interrupts handled
> by the same software interrupt handler.

syscalls are synchronous exceptions, softint can be either a real
interrupt (like mips or VAX) or emulated in the SPL code (ARM).

> Syscalls come from the userland with the user address space context,

Currently, only syscalls from user mode are handled.

> softint(9) come from the kernel with kernel address space context.

But softint(9) use interrups as a mechanism, they don’t require them.
In fact, I’d like to see that die.

> The spl(9) calls mask maskable interrupts, both software and hardware
> ones - with the exception to the unmaskable ones -- like data abort on ARM.

Again, data abort is an exception, not an interrupt.

> There are three contexts in the kernel:
> - hardware interrupt (within hardware interrupt handler),
> - software interrupt (within software interrupt handler) for syscalls
> and softint(9),
> - thread context for LWP (lightweight processes).
> 
> Bottom half (BSD naming) is responsible for the hardware interrupts, top
> half (BSD naming) is responsible for the software and thread contexts.

Bottom half talks to the hardware and processor.  Top deal with requests
from userland.  The pmap is bottom half even though it’s only invoked by
the top half (UVM).

> Process is heavy with user address space oneness running in the
> user-space, thread is lightweight with shared kernel address space for
> all threads. Kernel can access the whole physical memory, but doesn't
> know the user address mapping. There is one process running in the
> kernel address space -- proc0 = swapper.

A process is a collection of threads sharing the same address space.
That address space be a user address space or a kernel address space.

> How physically works the spl(9) interrupt masking for software
> interrupts? On ARM svc (or monitors) aren't maskable, like IRQ
> (exception), a type of (ARM naming) exception and (kernel naming)
> hardware interrupt.

That depends on the implementation and the underlying hardware.

> I'm trying to get the big picture first, before getting to details.
> 
> When I look into details, I don't get the things, like the line 268
> here:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/arm32/exception.S?annotate=1.17.2.2
> Is it a leftover from line 252 and should be erased?

It’s gone now.

> Back to the big picture. How technically works IPL_SOFT, does it mask
> syscalls and softint(9) the same way? If it's not maskable (to my
> understanding) are we scheduling it in some sort of queue or stack
> waiting for the spl(9) level change?

IMO, softints are an abberation and should really be thread priorities and
dealt by the thread scheduler.