On Tue, Apr 28, 2015 at 02:44:28PM -0400, Don Zickus wrote:
> RAS doesn't go through the legacy ports (ie get_nmi_reason()). Instead it
> triggers the external NMI through a different bit (ioapic I think).
Well, I see it getting registered with __register_nmi_handler() which
adds it to the NMI_LO
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, April 30, 2015 4:49 PM
>
> On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
> > Are there any such data around the SC and LL (MIPS)?
>
> What, you can't search the internet yourself?
I mean if LL can do what you exa
On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
> Are there any such data around the SC and LL (MIPS)?
What, you can't search the internet yourself?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscr
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, April 29, 2015 4:14 PM
> Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
> > > > We absolutely want to use ato
On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
> > > We absolutely want to use atomic_add_unless() because we get to save us
> > > the expensive
> > >
> > > LOCK; CMPXCHG
> > >
> > > if the value was already 1. Which is exactly what this patch is trying
> > > to avoid - a thundering h
Hi,
> From: Zheng, Lv
> Sent: Wednesday, April 29, 2015 8:25 AM
> Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Tuesday, April 28, 2015 9:59 PM
> > Subject
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, April 28, 2015 9:59 PM
> Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
> > > - raw_spin_lock(&am
On Tue, Apr 28, 2015 at 06:22:29PM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
> > Your solution seems much simpler. :-)
>
> ... and I love simpler :-)
>
> > I followed up in another email stating I mis-spoke. I forgot this still
> > uses the NMI_L
On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
> Your solution seems much simpler. :-)
... and I love simpler :-)
> I followed up in another email stating I mis-spoke. I forgot this still
> uses the NMI_LOCAL shared NMI. So every perf NMI, will also call the GHES
> handler to make
On Tue, Apr 28, 2015 at 04:55:48PM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> > On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> > >
> > > > From: Jiri Kosina
> > > >
> > > > Since
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> >
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> >
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> On Fri, 27 Mar 2015, Borislav Petkov wrote:
>
> > From: Jiri Kosina
> >
> > Since GHES sources are global, we theoretically need only a single CPU
> > reading them per NMI instead of a thundering herd of CPUs waiting on a
> > spinloc
On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
> > - raw_spin_lock(&ghes_nmi_lock);
> > + if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
> > + return ret;
> > +
>
> if (atomic_cmpxchg(&ghes_in_nmi, 0, 1))
> return ret;
Ok, now I understand what you mean.
We absolutel
Hi,
I was talking about this patch.
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, March 27, 2015 5:23 PM
> Subject: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically n
On Tue, Apr 28, 2015 at 02:24:16AM +, Zheng, Lv wrote:
> > > #APP
> > > # 177 "./arch/x86/include/asm/atomic.h" 1
> > > .pushsection .smp_locks,"a"
> > > .balign 4
> > > .long 671f - .
> > > .popsection
> > > 671:
> > > lock; cmpxchgl %edx,ghes_in_nmi(%rip) # D.37056, MEM[(volatile u32
>
Hi,
> From: Zheng, Lv
> Sent: Tuesday, April 28, 2015 8:44 AM
>
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Monday, April 27, 2015 4:47 PM
> >
> > On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned in
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, April 27, 2015 4:47 PM
>
> On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> > > pt_regs *regs)
> > > struct ghes *ghes;
> > > int sev,
On Thu, Apr 23, 2015 at 06:00:15PM +, Luck, Tony wrote:
> > I think we should apply this.
> >
> > Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
> > accesses
>
> This looks to be true.
>
> > Tony, objections?
>
> No objections.
Thanks, queued for 4.2, pending one las
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> > pt_regs *regs)
> > struct ghes *ghes;
> > int sev, ret = NMI_DONE;
> >
> > - raw_spin_lock(&ghes_nmi_lock);
> > + if (!atomic_add_unless(&ghes_in_
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, March 27, 2015 5:23 PM
>
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
> reading them per NMI instead of a thundering herd of CPUs waiting on a
> spinlock in NMI context for no r
> I think we should apply this.
>
> Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
> accesses
This looks to be true.
> Tony, objections?
No objections.
-Tony
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf�
On Thu, Apr 23, 2015 at 10:39:58AM +0200, Jiri Kosina wrote:
> Three weeks have passed, therefore I find this an appropriate time for a
> friendly ping :)
>
> Rafael? Naoya? Huang?
>
> This fixes a contention spinlock problem in NMI observed on a real HW, so
> it would be really nice to have it
On Wed, 1 Apr 2015, Borislav Petkov wrote:
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading them per NMI instead of a thundering herd of CPUs waiting on a
> > > spinlock in NMI context for no reason at all.
> >
> > I origin
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> On Fri, 27 Mar 2015, Borislav Petkov wrote:
>
> > From: Jiri Kosina
> >
> > Since GHES sources are global, we theoretically need only a single CPU
> > reading them per NMI instead of a thundering herd of CPUs waiting on a
> > spinloc
On Fri, 27 Mar 2015, Borislav Petkov wrote:
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
> reading them per NMI instead of a thundering herd of CPUs waiting on a
> spinlock in NMI context for no reason at all.
I originally wasn't 100% sure wheth
From: Jiri Kosina
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context for no reason at all.
Do that.
Signed-off-by: Jiri Kosina
Signed-off-by: Borislav Petkov
---
drivers/acpi/ap
27 matches
Mail list logo
