Re: [Xen-devel] [PATCH v2] x86/NMI: Allow processing unknown NMIs when watchdog is enabled

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.14 at 18:45, <ross.lagerwall@xxxxxxxxxx> wrote:
> ________________________________________
> From: Jan Beulich [JBeulich@xxxxxxxx]
> Sent: Wednesday, August 27, 2014 4:35 PM
> To: Ross Lagerwall
> Cc: Xen-devel; Keir (Xen.org)
> Subject: Re: [PATCH v2] x86/NMI: Allow processing unknown NMIs when watchdog 
> is enabled
> 
>>>>> On 27.08.14 at 17:11, <ross.lagerwall@xxxxxxxxxx> wrote:
>>> @@ -473,14 +496,26 @@ void nmi_watchdog_tick(const struct cpu_user_regs 
> *regs)
>>>          }
>>>          else if ( nmi_perfctr_msr == MSR_P6_PERFCTR0 )
>>>          {
>>> +            rdmsrl(MSR_P6_PERFCTR0, msr_content);
>>> +            if ( msr_content & (1ULL << P6_EVENT_WIDTH) )
>>> +                watchdog_tick = 0;
>>> +
>>>              /*
>>>               * Only P6 based Pentium M need to re-unmask the apic vector 
>>> but
>>>               * it doesn't hurt other P6 variants.
>>>               */
>>>              apic_write(APIC_LVTPC, APIC_DM_NMI);
>>>          }
>>> +        else if ( nmi_perfctr_msr == MSR_K7_PERFCTR0 )
>>> +        {
>>> +            rdmsrl(MSR_K7_PERFCTR0, msr_content);
>>> +            if ( msr_content & (1ULL << K7_EVENT_WIDTH) )
>>> +                watchdog_tick = 0;
>>> +        }
>>
>>Looking at the top counter bits is rather weak a check, but I guess
>>there's nothing better (and considering a few more of the top
>>bits would only shrink the window of mis-detection, not eliminate
>>it)...
>>
> 
> Well the counter counts down from some large negative number to zero. It is
> sign-extended beyond *_EVENT_WIDTH, so I don't think checking (one of) the 
> sign
> bits to confirm whether it has overflowed is that bad.

Oh, indeed, I forgot that this gets programmed with a large initial
value (as, being a performance counter, counts upwards). Indeed,
that renders the above pretty reliable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel