lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Date
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



\
 
 \ /
  Last update: 2008-09-25 05:59    [W:1.285 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site