[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code

[Kumar Gala]

On May 1, 2008, at 9:26 AM, Josh Boyer wrote:

> On Thu, 2008-05-01 at 08:22 -0500, Kumar Gala wrote:
>>>> So we have 4 actual exceptions:
>>>> * CriticalInput (some external device signaled this.  There are two
>>>> concepts of critical.  One is error the other is high priority)
>>>> However this would have the same caveats as any ExternalInput
>>>> handler.
>>>
>>> No, it's worse. It can interrupt code that normally has
>>> local_irq_disabled() and thus doesn't expect to be interrupted. That
>>> means that everything becomes unsafe including locks etc....
>>
>> Fair.  Should local_irq_disable() clear MSR_SE & MSR_BE on classic
>> parts?
>>
>>> Note that driver that want to make active use of that probably want
>>> some
>>> explicit local_crit_irq_disable/enable functions to be able to
>>> implement
>>> some sort of synchronization.
>>
>> Or we could just have local_irq_disable -- clear MSR_EE and MSR_CE
>
> That sort of defeats the purpose of using critical interrupts in the
> "higher priority" sense, doesn't it?  Seems it would effectively
> eliminate that level altogether.  And it would also mask off the
> watchdog interrupt, which I don't think you want to do.
>
> Ben suggested local_crit_irq_disable.  That would suffice for drivers
> that know they are configured as CE and need to do locking primitives,
> but that isn't very common.  On 4xx there isn't even an interface  
> for a
> driver to request it's interrupts be set to CE and we init all UICs to
> have UIC_CR be 0.
>
> So for 4xx at least, most of this discussion is theoretical for now.
> However, I can see value in having CEs being used for certain devices,
> etc so it would be nice to figure it out in the long run.

I agree.  my first priority is to get debug interrupts cleaned up so  
we can kprobe and do other debug things in the kernel.

I'm only aware of one case of someone asking for critical inputs on  
our parts w/linux.

- k

- k