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