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: <20110921171021.GV5795@redhat.com>
Date:	Wed, 21 Sep 2011 13:10:21 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Robert Richter <robert.richter@....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 Wed, Sep 21, 2011 at 07:24:54PM +0300, Avi Kivity 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.
> >
> >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.

Actually I was trying to remember what the argument for the optimization
was again?  I believe the virt team needed it right?

Cheers,
Don
--
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/