Re: [PATCH v2] KVM: Fix simultaneous NMIs

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Sep 21, 2011 at 11:46:03AM +0300, Avi Kivity wrote:
> On 09/20/2011 08:28 PM, Avi Kivity wrote:
> >On 09/20/2011 07:30 PM, Marcelo Tosatti wrote:
> >>> >
> >>> >>   We do have a small issue.  If we exit during
> >>NMI-blocked-by-STI and
> >>> >>   nmi_pending == 2, then we lose the second interrupt.
> >>Should rarely
> >>> >>   happen, since external interrupts never exit in that
> >>condition, but
> >>> >>   it's a wart.

Actually exits in the window between 

- increase of nmi_queued 
and 
- transfer to nmi_pending/nmi_injected

Lose all nmi_queued values, no?

> >>> >
> >>> >And the above system reset case, you should be able to handle it by
> >>> >saving/restoring nmi_queued (so that QEMU can zero it in vcpu_reset).
> >>>
> >>>  We could just add a KVM_CAP (and flag) that extends nmi_pending from
> >>>  a bool to a counter.
> >>
> >>Or just add a new field to the pad.
> >>
> >
> >Okay; I'll address this in a follow-on patch (my preference is
> >making nmi_pending a counter).
> >
> 
> Yet another way to do this is to redefine .injected (just in the
> API) to mean: inject immediately, unless blocked by interrupt
> shadow; in this case inject in the next instruction.  No KVM_CAP or
> anything.
> 
> The drawback is that if we hit the corner case of two NMIs queued
> and held back by interrupt shadow, an older kvm live migration
> target will not run the guest (exit with invalid state).  The
> advantage is that no user space or API changes are necessary.
> 
> Given that to get into this corner you need an NMI intensive load
> AND a sti; blah pair that spans two pages AND have the second page
> unavailable when those NMIs hit, I think it's better to avoid the
> API change.  Opinions?