[RFC PATCH 5/9] powerpc: reverse the soft_enable logic
Nicholas Piggin
npiggin at gmail.com
Tue Jul 26 15:31:03 AEST 2016
On Mon, 25 Jul 2016 20:22:18 +0530
Madhavan Srinivasan <maddy at linux.vnet.ibm.com> wrote:
> "paca->soft_enabled" is used as a flag to mask some of interrupts.
> Currently supported flags values and their details:
>
> soft_enabled MSR[EE]
>
> 0 0 Disabled (PMI and HMI not masked)
> 1 1 Enabled
>
> "paca->soft_enabled" is initialed to 1 to make the interripts as
> enabled. arch_local_irq_disable() will toggle the value when
> interrupts needs to disbled. At this point, the interrupts are not
> actually disabled, instead, interrupt vector has code to check for
> the flag and mask it when it occurs. By "mask it", it updated
> interrupt paca->irq_happened and return. arch_local_irq_restore() is
> called to re-enable interrupts, which checks and replays interrupts
> if any occured.
>
> Now, as mentioned, current logic doesnot mask "performance monitoring
> interrupts" and PMIs are implemented as NMI. But this patchset
> depends on local_irq_* for a successful local_* update. Meaning, mask
> all possible interrupts during local_* update and replay them after
> the update.
>
> So the idea here is to reserve the "paca->soft_enabled" logic. New
> values and details:
>
> soft_enabled MSR[EE]
>
> 1 0 Disabled (PMI and HMI not masked)
> 0 1 Enabled
>
> Reason for the this change is to create foundation for a third flag
> value "2" for "soft_enabled" to add support to mask PMIs. When
> arch_irq_disable_* is called with a value "2", PMI interrupts are
> mask. But when called with a value of "1", PMI are not mask.
>
> With new flag value for "soft_enabled", states looks like:
>
> soft_enabled MSR[EE]
>
> 2 0 Disbaled PMIs also
> 1 0 Disabled (PMI and HMI not masked)
> 0 1 Enabled
>
> And interrupt handler code for checking has been modified to check for
> for "greater than or equal" to 1 condition instead.
This bit of the patch seems to have been moved into other part
of the series. Ideally (unless there is a good reason), it is nice
to have each individual patch result in a working kernel before
and after.
Nice way to avoid adding more branches though.
Thanks,
Nick
More information about the Linuxppc-dev
mailing list