On Mon, 25 Jul 2016 20:22:18 +0530 Madhavan Srinivasan <ma...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
