From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH v2] KVM: Fix simultaneous NMIs Date: Wed, 21 Sep 2011 13:44:49 -0300 Message-ID: <20110921164449.GA21142@amt.cnet> References: <1316515394-24762-1-git-send-email-avi@redhat.com> <20110920132537.GA27075@amt.cnet> <4E789B72.2050904@redhat.com> <20110920145946.GA28219@amt.cnet> <4E78BE21.4070508@redhat.com> <20110920163021.GA29618@amt.cnet> <4E78CD23.5000705@redhat.com> <4E79A44B.8090704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Jan Kiszka To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16742 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752223Ab1IURea (ORCPT ); Wed, 21 Sep 2011 13:34:30 -0400 Content-Disposition: inline In-Reply-To: <4E79A44B.8090704@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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?