linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Balbir Singh <bsingharora@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:06:41 +1000	[thread overview]
Message-ID: <20161213160641.47a6332d@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <1481607371.11971.1.camel@gmail.com>

On Tue, 13 Dec 2016 16:36:11 +1100
Balbir Singh <bsingharora@gmail.com> wrote:

> 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

Other thing is, I would do the masked external interrupt as its own
patch. NMI is basically independent as far as I can see.

Thanks,
Nick

  reply	other threads:[~2016-12-13  6:06 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
2016-12-13  6:06       ` Nicholas Piggin [this message]
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=20161213160641.47a6332d@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).