Messages in this thread | | | Date | Sun, 25 Sep 2011 15:54:34 +0300 | From | Avi Kivity <> | 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
| |