Re: [RFC 4/6] x86, NMI, Rewrite NMI handler

[Don Zickus]

On Mon, Sep 13, 2010 at 10:09:30AM +0800, Huang Ying wrote:
> > The reason I asked was, I thought it would be easier to have a global
> > variable that tells the nmi handler which cpu has the NMI's routed to its
> > io port.  This way if you want to swap out the bsp cpu, you could perhaps
> > just re-route the nmi to a new cpu and the global variable would be
> > updated accordingly?
> 
> Then we need some kind of protection or race condition between
> re-routing NMI and updating the variable. Do you think so?

Well, I thought the only reasonable place to update the variable is when
the cpu is being taken offline, during the MTRR update.  Since no NMIs can
be processed when the cpu's are syncing their MTRR, there shouldn't be a
race condition, no?

Then again I am probably missing something obvious.  Like I don't know how
cpu's deal with interrupts/NMIs when they are going offline.

It was just a thought to avoid the spinlock.

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