Re: nmi is broken?

[Avi Kivity <avi@redhat.com>]

On 04/24/2011 05:08 PM, Jan Kiszka wrote:
> On 2011-04-24 08:44, Avi Kivity wrote:
> >  On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
> >>  OGAWA Hirofumi<hirofumi@mail.parknet.co.jp>   writes:
> >>
> >>  >   I noticed recently NMI on guest kernel is not working well.
> >>  host/guest
> >>  >   kernel is 2.6.39-rc4, and using vmx.
> >>  >
> >>  >   And test code is something like the following:
> >>  >
> >>  >       local_irq_disable();
> >>  >       for (i = 0; i<   10; i++) {
> >>  >           int cpu = get_cpu();
> >>  >           printk("%s: nmi %u, lapic %u\n", __FUNCTION__,
> >>  >               nmi_count(cpu), irq_stat[cpu].apic_timer_irqs);
> >>  >           mdelay(1000);
> >>  >           put_cpu();
> >>  >       }
> >>  >
> >>  >   the result is both of nmi and lapic are not increased. If I used
> >>  >   -no-kvm-irqchip, it works fine (increase nmi only). So, it seems to be
> >>  >   the bug of kvm driver side.
> >>
> >>  With some debug, the cause seems to be in pit_do_work(). With the
> >>  following patch, NMI watchdog seems to be working correctly (if irq
> >>  disabled for long time, NMI watchdog can detect it).
> >>
> >>  Is the following patch right?
> >
> >  This would cause IRQs to be delivered even if the PIT is masked, no?
> >
> >  Are you in fact using the PIT?  Linux prefers the HPET, and in my
> >  experience the -no-hpet option makes NMIs work.
>
> BTW, that's another bug of the in-kernel PIT model: It disables the
> timer in HPET legacy mode even if we are aware of NMI watchdog
> receivers. Actually, the whole legacy disabling looks a bit strange in
> the PIT (mode hackery + flag testing...).
>
> While this should be fixed/refactored, adding basic perf support to KVM
> will be the only option long-term as Linux dropped virtual-wire NMI
> watchdog support some releases ago.

Yes.  Unfortunately that is very vendor and model specific.  The 
architectural PMU is supported, but that is only available on Intel.

Perhaps we could emulate the architectural PMU on AMD as well, and make 
the detection code in the guest vendor agnostic.  Since it's based on a 
cpuid bit, it should be safe.

-- 
error compiling committee.c: too many arguments to function