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

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/28/2011 10:44 AM, Don Zickus wrote:
> On Wed, Sep 28, 2011 at 09:51:33AM -0700, Jeremy Fitzhardinge wrote:
>> On 09/28/2011 05:37 AM, Don Zickus wrote:
>>> On Wed, Sep 28, 2011 at 12:31:40PM +0200, Robert Richter wrote:
>>>> On 23.09.11 15:17:13, Don Zickus wrote:
>>>>> @@ -89,6 +89,15 @@ static int notrace __kprobes nmi_handle(unsigned int type, struct pt_regs *regs)
>>>>>  
>>>>>  		handled += a->handler(type, regs);
>>>>>  
>>>>> +		/*
>>>>> + 		 * Optimization: only loop once if this is not a 
>>>>> + 		 * back-to-back NMI.  The idea is nothing is dropped
>>>>> + 		 * on the first NMI, only on the second of a back-to-back
>>>>> + 		 * NMI.  No need to waste cycles going through all the
>>>>> + 		 * handlers.
>>>>> + 		 */
>>>>> +		if (!b2b && handled)
>>>>> +			break;
>>>> I don't think we can leave this in. As said, there are cases that 2
>>>> nmis trigger but the handler is called only once. Only the first would
>>>> be handled then, and the second get lost cause there is no 2nd nmi
>>>> call.
>>> Right.  Avi, Jeremy what was your objection that needed this optimization
>>> in the first place?
>> My only interest in the NMI code is its use of spinlocks, which seem
>> inappropriate.
> Right.  But I thought this was going to clash with your ticketed spinlock
> stuff?

To be honest I haven't really been following this thread; it didn't
appear to me to relate to the spinlock issue any more.  At least in the
Xen case, I don't *think* we'll be sending NMIs to domains which are
using pv ticketlocks, so the issue is moot.  It's more pressing for Avi
because he's thinking of using NMIs to implement pv ticketlocks in kvm.

    J