Re: [PATCH v2] KVM: Fix simultaneous NMIs

Marcelo Tosatti
2011-09-21T17:34:30Z

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?