All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@ozlabs.org, Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [powerpc/nmi: RFC 2/2] Keep interrupts enabled even on soft disable
Date: Tue, 13 Dec 2016 16:36:11 +1100	[thread overview]
Message-ID: <1481607371.11971.1.camel@gmail.com> (raw)
In-Reply-To: <20161212233111.1712ba79@roar.ozlabs.ibm.com>

On Mon, 2016-12-12 at 23:31 +1000, Nicholas Piggin wrote:
> On Mon, 12 Dec 2016 20:50:03 +1100
> Balbir Singh <bsingharora@gmail.com> wrote:
> 
> > This patch removes the disabling of interrupts
> > in soft-disable mode, when interrupts are received
> > (in lazy mode). The new scheme keeps the interrupts
> > enabled when we receive an interrupt and does the
> > following
> > 
> > a. On decrementer interrupt, instead of setting
> > dec to maximum and returning, we do the following
> >   i. Call a function handle_nmi_dec, which in
> >      turn calls handle_soft_nmi
> >   ii. handle_soft_nmi sets the decrementer value
> >       to 1 second and checks if more than 30
> >       seconds have passed since starting it. If
> >       so it calls BUG_ON(1), we can do an NMI
> >       panic as well.
> > b. When an external interrupt is received, we
> >    store the interrupt in local_paca via
> >    ppc_md.get_irq(). Later when interrupts are
> >    enabled and replayed, we reuse the stored
> >    interrupt and process it via generic_handle_irq
> 
> This seems pretty good. My NMI handler should plug in just
> the same to the masked decrementer, so that wouldn't be a
> problem.

Thats good to know, I believe so as well.

<snip>

> > while soft-disable */
> > +	u32 irq;			/* IRQ pending */
> >  	u8 nap_state_lost;		/* NV GPR values lost in
> > power7_idle */
> >  	u64 sprg_vdso;			/* Saved user-
> > visible sprg */
> 
> Can you avoid some padding if you move it to below irq_happened?
>

Will do
 
> > +EXC_COMMON(handle_nmi_dec, 0x900, handle_soft_nmi)
> > +EXC_COMMON(elevate_save_irq, 0x500, handle_elevated_irq)
> 
> I wonder if the name should match the type of interrupt rather than
> implementation detail (elevated?), and match the existing handlers
> e.g, hardware_interrupt_masked common handler could call
> do_IRQ_masked.
>

Sure, will rename them
 
> As for the NMI, I would prefer just to keep it out of the timer path
> completely and schedule a Linux timer for it as I had.
> 
> Otherwise, this looks nice if it does the right thing with the
> interrupt
> controller. It hasn't taken a lot of lines to implement which is very
> cool.
> 

Yep, although the code works for PPC_XICS only which is good for now.
When we do XIVE, we can add more bits

Balbir

  parent reply	other threads:[~2016-12-13  5:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-12  9:50 [powerpc/nmi: RFC 0/2] Support Soft NMI Balbir Singh
2016-12-12  9:50 ` [powerpc/nmi: RFC 1/2] Merge IPI and DEFAULT priorities Balbir Singh
2016-12-12  9:50 ` [powerpc/nmi: RFC 2/2] Keep interrupts enabled even on soft disable Balbir Singh
2016-12-12 13:31   ` Nicholas Piggin
2016-12-12 15:24     ` Benjamin Herrenschmidt
2016-12-13  3:28       ` Balbir Singh
2016-12-13 15:22         ` Benjamin Herrenschmidt
2016-12-13  5:36     ` Balbir Singh [this message]
2016-12-13  6:06       ` Nicholas Piggin
2016-12-13 15:27       ` Benjamin Herrenschmidt
2016-12-14  0:41         ` Balbir Singh
2016-12-15 15:15           ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1481607371.11971.1.camel@gmail.com \
    --to=bsingharora@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.