Re: Understanding SPL(9)

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Aug 31, 2015 at 03:30:36PM +0000, Eduardo Horvath wrote:
> On Mon, 31 Aug 2015, Stephan wrote:
> 
> > I?m trying to understand interrupt priority levels using the example
> > of x86. From what I?ve seen so far I?d say that all spl*() functions
> > end up in either splraise() or spllower() from
> > sys/arch/i386/i386/spl.S. What these functions actually do is not
> > clear to me. For example, splraise() starts with this:
> > 
> > ENTRY(splraise)
> >         movl    4(%esp),%edx
> >         movl    CPUVAR(ILEVEL),%eax
> >         cmpl    %edx,%eax
> >         ja      1f
> >         movl    %edx,CPUVAR(ILEVEL)
> > ...
> > 
> > I?m unable to find out what CPUVAR(ILEVEL) means. I would guess that
> > something needs to happen to the APIC?s task priority register.
> > However I can?t see any coherence just now.
> 
> Don't look at x86, it doesn't have real interrupt levels.  Look at SPARC 
> or 68K which do.

Old x86 fed interrupts through (the equiv of) an 8259? interrupt
controller that dates from the 1970s (8080 cpu).
This has 8 interrupt priority levels and the spl() could (and used to)
modify the mask.
The problem is that these accesses are very, very slow. Since interrupts
are much rarer than spl calls it is much faster to not update the
hardware mask unless you get a level-sensitive interrupt that should
be masked.

Amd64 cpus have a built-in intertupt priority register (cr8) that can
be used to mask low priority interrupts.
Unlike all other control registers, accesses to cr8 aren't sequencing
instructions so are fast.
I don't know whether netbsd dynamically changes cr8.

> Most machines nowadays only have one interrupt line and an external 
> interrupt controller.  True interrupt levels are simulated by assigning 
> levels to individual interrupt sources and masking the appropriate ones in 
> the interrupt controller.  This makes the code rather complicated, 
> especially since interrupts can nest.

Multiple interrupt priorities for level sensitive interrupts require
hardware support.

	David

-- 
David Laight: david%l8s.co.uk@localhost