Re: [PATCH v2] KVM: Fix simultaneous NMIs

Avi Kivity
2011-09-21T08:46:07Z

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.
>> > >
>> > >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?

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