linux-kernel - Re: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110921165451.GF6063@erda.amd.com>
Date:	Wed, 21 Sep 2011 18:54:51 +0200
From:	Robert Richter <robert.richter@....com>
To:	Avi Kivity <avi@...hat.com>
CC:	Don Zickus <dzickus@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"ying.huang@...el.com" <ying.huang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>,
	"jeremy@...p.org" <jeremy@...p.org>
Subject: Re: [V5][PATCH 4/6] x86, nmi:  add in logic to handle multiple
 events and unknown NMIs

On 21.09.11 12:24:54, Avi Kivity wrote:
> On 09/21/2011 07:13 PM, Don Zickus wrote:
> > On Wed, Sep 21, 2011 at 05:18:30PM +0200, Robert Richter wrote:
> > >  On 21.09.11 10:04:32, Don Zickus wrote:

> > >  But in rare cases there is the following:
> > >
> > >  1. The cpu executes some microcode or SMM code.
> > >  2. HW triggers the first NMI, an NMI is pending.
> > >  3. HW triggers a second NMI, the NMI is still pending.
> > >  4. The cpu finished microcode or SMM code.
> > >  5. NMI handler is called, no NMI pending anymore.
> > >  6. Return from NMI handler.
> > >
> > >  In this case the handler is called only once and the second nmi
> > >  remains unhandled with you implementation.
> > >
> > >  I don't see a way how this could be catched without serving all
> > >  handlers the first time. But as said, in favor of the optimization I
> > >  think we can live with losing some NMIs.

I have to revise this after thinking more about this. We may not lose
an nmi for sources where the nmi handler must always reenable the nmi,
e.g. IBS. Losing one nmi means for IBS that sample generation gets
stuck.

-Robert

> >
> > Ah, I get it know.  Crap.  Well I think Avi was pushing it to make those
> > ticket_spin_locks work in virt land.  It seems like we should lean towards
> > removing the optimization.  Avi?
> >
> 
> Well, in virt land there are no SMIs, and we can guarantee that the 
> queue length is always two.  So if these rare cases are okay for 
> upstream, it'll be fine for virt.
> 
> -- 
> error compiling committee.c: too many arguments to function
> 
> 

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/