Re: [PATCH v2] KVM: Fix simultaneous NMIs

[Avi Kivity <avi@redhat.com>]

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