On Monday 01 August 2016 10:59 AM, Nicholas Piggin wrote:
On Mon,  1 Aug 2016 00:36:27 +0530
Madhavan Srinivasan <ma...@linux.vnet.ibm.com> wrote:

  /*
   * flags for paca->soft_enabled
   */
  #define IRQ_DISABLE_LEVEL_NONE                0
  #define IRQ_DISABLE_LEVEL_LINUX               1
+#define IRQ_DISABLE_LEVEL_PMU          2
+
+#define MASK_IRQ_LEVEL         IRQ_DISABLE_LEVEL_LINUX | IRQ_DISABLE_LEVEL_PMU
#endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 2c87e82ecbe4..56dc71b82824 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -256,11 +256,11 @@ hardware_interrupt_pSeries:
  hardware_interrupt_hv:
        BEGIN_FTR_SECTION
                _MASKABLE_EXCEPTION_PSERIES(0x502, hardware_interrupt,
-                                           EXC_HV, SOFTEN_TEST_HV, 
IRQ_DISABLE_LEVEL_LINUX)
+                                           EXC_HV, SOFTEN_TEST_HV, 
MASK_IRQ_LEVEL)
So what I was expecting is that each exception handler would specify the
level (or bit, if we use bitmask) at which it gets disabled. The test code
will then test the exception level with the enable level (or s/level/mask).

The way you have now is each exception handler specifying the bits which
cause it to be disabled, but I think that's kind of backwards -- the
disabler knows which interrupts it wants to disable, the exception handler
does not know what disablers want to disable it :)

Yep. My bad. Implemented backwards.


So to disable PMU and "linux" interrupts for local_t operations, you would
have:

local_irq_set_mask(IRQ_DISABLE_LEVEL_LINUX|IRQ_DISABLE_LEVEL_PMU)

Yep. Right now I made the exception handler to specify this and
 soft_irq_set_level() set the level. But this a minor change.


And that would disable both handlers that test with IRQ_DISABLE_LEVEL_LINUX
and IRQ_DISABLE_LEVEL_PMU

Does that make sense? What do you think?

Yes. it make sense.
But would like to get comments for the SOFTEN_TEST changes.

Maddy


Thanks,
Nick


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to