Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption

[Milton Miller]

On Sep 24, 2008, at 4:16 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
> > I was trying to understand why the mask and early eoi, but I guess its
> > to handle other more limited interrupt controllers where the 
> > interrupts
> > stack in hardware instead of software.
>
> No Milton, we must do it that way, because the EOI must be done on the
> right CPU even on XICS, or we won't get the CPU priority back properly.

Ben and I had a online chat, and he pointed out I needed to be more 
specific in saying what I was thinking.

> > I think the flows we want on xics are:
> >
> > (non-threaded)
> > 	getirq (implicit source specific mask until eoi)
> > 	handle interrupt
> > 	eoi (implicit cpu priority restore)
> >
> > (threaded)
> > 	getirq (implicit source specific mask until eoi)
> > 	explicit cpu priority restore
> > 	handle interrupt
> > 	eoi (implicit cpu priority restore to same as explicit level)


cpu takes interrupt, checks soft disabled
if so,
	set hard disabled
else
	call get_irq
	if threaded
		write cppr to restore this cpu irq dispatch state to non-interrupt
		mark irq thread as irq pending
	else
		handle interrupt
		eoi (cppr = base)

irq thread will
	handle interrupt
	eoi
	wait for marked pending again

The part Ben did not follow was that the cppr write to base priority is 
done by the interrupted cpu (like the mask and eoi in the current flow) 
and only the final eoi (where the mask is in the existing flow) is done 
on which ever cpu happens to run the irq thread.


(optional) As I was discussing with Paul, when taking an irq when 
soft-disabled but still hard enabled, it is possible to write the cppr 
such that it would reject the pending irq and have it be considered for 
dispatch to another cpu.   But it would increase pathlength on both the 
go-to-hard-disabled and return-from-hard-disabled and the hardware will 
have some latency as it will likely send it back to the io source until 
it retrys, so we would only want to do this if the hard-disable period 
is sufficiently long.

milton

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/