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] [day] [month] [year] [list]

Date:	Sun, 25 Sep 2011 15:54:34 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Robert Richter <robert.richter@....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 09/21/2011 07:54 PM, Robert Richter wrote:
> 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.
>

Well, that pretty much kills the whole idea.  This thing has to be reliable.

I'll ask Intel if they can guarantee a length 2 queue on their 
processors (or maybe Andi you can find this out).

-- 
error compiling committee.c: too many arguments to function

--
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/