All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH v2] KVM: Fix simultaneous NMIs
Date: Tue, 20 Sep 2011 16:56:02 +0300	[thread overview]
Message-ID: <4E789B72.2050904@redhat.com> (raw)
In-Reply-To: <20110920132537.GA27075@amt.cnet>

On 09/20/2011 04:25 PM, Marcelo Tosatti wrote:
> >
> >  @@ -2827,6 +2828,7 @@ static int kvm_vcpu_ioctl_x86_set_mce(struct kvm_vcpu *vcpu,
> >   static void kvm_vcpu_ioctl_x86_get_vcpu_events(struct kvm_vcpu *vcpu,
> >   					struct kvm_vcpu_events *events)
> >   {
> >  +	process_nmi(vcpu);
> >   	events->exception.injected =
> >   		vcpu->arch.exception.pending&&
> >   		!kvm_exception_is_soft(vcpu->arch.exception.nr);
> >  @@ -2844,7 +2846,7 @@ static void kvm_vcpu_ioctl_x86_get_vcpu_events(struct kvm_vcpu *vcpu,
> >   			KVM_X86_SHADOW_INT_MOV_SS | KVM_X86_SHADOW_INT_STI);
> >
> >   	events->nmi.injected = vcpu->arch.nmi_injected;
> >  -	events->nmi.pending = vcpu->arch.nmi_pending;
> >  +	events->nmi.pending = vcpu->arch.nmi_pending != 0;
> >   	events->nmi.masked = kvm_x86_ops->get_nmi_mask(vcpu);
> >   	events->nmi.pad = 0;
>
> nmi_queued should also be saved and restored. Not sure if its necessary
> though.
>
> Should at least reset nmi_queued somewhere (set_vcpu_events?).

Did you miss the call to process_nmi()?

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.

>
> >  @@ -2864,6 +2866,7 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu,
> >   			| KVM_VCPUEVENT_VALID_SHADOW))
> >   		return -EINVAL;
> >
> >  +	process_nmi(vcpu);
>
> This should be after nmi fields are set, not before?
>

It's actually to clear queued NMIs in case we set nmi_pending (which 
should never happen unless the machine is completely quiet, since it's 
asynchronous to the vcpu; same as the IRR).

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


  reply	other threads:[~2011-09-20 13:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 10:43 [PATCH v2] KVM: Fix simultaneous NMIs Avi Kivity
2011-09-20 13:25 ` Marcelo Tosatti
2011-09-20 13:56   ` Avi Kivity [this message]
2011-09-20 14:59     ` Marcelo Tosatti
2011-09-20 16:24       ` Avi Kivity
2011-09-20 16:30         ` Marcelo Tosatti
2011-09-20 17:28           ` Avi Kivity
2011-09-21  8:46             ` Avi Kivity
2011-09-21 16:44               ` Marcelo Tosatti
2011-09-23 11:54                 ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E789B72.2050904@redhat.com \
    --to=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.