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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
