All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alexander Graf <agraf@suse.de>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/5] Implement #NMI exiting for nested SVM
Date: Fri, 18 Sep 2009 15:33:34 +0200	[thread overview]
Message-ID: <4AB38C2E.307@siemens.com> (raw)
In-Reply-To: <1253278832-31803-2-git-send-email-agraf@suse.de>

Alexander Graf wrote:
> When injecting an NMI to the l1 guest while it was running the l2 guest, we
> didn't #VMEXIT but just injected the NMI to the l2 guest.
> 
> Let's be closer to real hardware and #VMEXIT if we're supposed to do so.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/x86/kvm/svm.c |   38 ++++++++++++++++++++++++++++++++------
>  1 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 9a4daca..f12a669 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1375,6 +1375,21 @@ static int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr,
>  	return nested_svm_exit_handled(svm);
>  }
>  
> +static inline int nested_svm_nmi(struct vcpu_svm *svm)
> +{
> +	if (!is_nested(svm))
> +		return 0;
> +
> +	svm->vmcb->control.exit_code = SVM_EXIT_NMI;
> +
> +	if (nested_svm_exit_handled(svm)) {
> +		nsvm_printk("VMexit -> NMI\n");
> +		return 1;
> +	}
> +
> +	return 0;
> +}
> +
>  static inline int nested_svm_intr(struct vcpu_svm *svm)
>  {
>  	if (!is_nested(svm))
> @@ -2462,7 +2477,9 @@ static int svm_nmi_allowed(struct kvm_vcpu *vcpu)
>  	struct vcpu_svm *svm = to_svm(vcpu);
>  	struct vmcb *vmcb = svm->vmcb;
>  	return !(vmcb->control.int_state & SVM_INTERRUPT_SHADOW_MASK) &&
> -		!(svm->vcpu.arch.hflags & HF_NMI_MASK);
> +		!(svm->vcpu.arch.hflags & HF_NMI_MASK) &&
> +		gif_set(svm) &&
                ^^^^^^^^^^^^
I'm not claiming to be up-to-date with the SVM code around NMI
injection, but this addition irritates me. Can you explain why I don't
have to worry that a cleared IF could now defer NMI injections for L1
guests?

> +		!is_nested(svm);
>  }
>  
>  static int svm_interrupt_allowed(struct kvm_vcpu *vcpu)
> @@ -2488,22 +2505,31 @@ static void enable_irq_window(struct kvm_vcpu *vcpu)
>  	struct vcpu_svm *svm = to_svm(vcpu);
>  	nsvm_printk("Trying to open IRQ window\n");
>  
> -	nested_svm_intr(svm);
> +	if (nested_svm_intr(svm))
> +		return;
>  
>  	/* In case GIF=0 we can't rely on the CPU to tell us when
>  	 * GIF becomes 1, because that's a separate STGI/VMRUN intercept.
>  	 * The next time we get that intercept, this function will be
>  	 * called again though and we'll get the vintr intercept. */
> -	if (gif_set(svm)) {
> -		svm_set_vintr(svm);
> -		svm_inject_irq(svm, 0x0);
> -	}
> +	if (!gif_set(svm))
> +		return;
> +
> +	svm_set_vintr(svm);
> +	svm_inject_irq(svm, 0x0);

The last change is pure refactoring that should not belong into this
patch, should it?

>  }
>  
>  static void enable_nmi_window(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_svm *svm = to_svm(vcpu);
>  
> +	if (nested_svm_nmi(svm))
> +		return;
> +
> +	/* NMI is deferred until GIF == 1. Setting GIF will cause a #VMEXIT */
> +	if (!gif_set(svm))
> +		return;
> +

The second half is an unrelated optimization? Then please file a
separate patch.

>  	if ((svm->vcpu.arch.hflags & (HF_NMI_MASK | HF_IRET_MASK))
>  	    == HF_NMI_MASK)
>  		return; /* IRET will cause a vm exit */

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

  parent reply	other threads:[~2009-09-18 13:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 13:00 [PATCH 0/5] Nested SVM Interrupt Fixes Alexander Graf
2009-09-18 13:00 ` [PATCH 1/5] Implement #NMI exiting for nested SVM Alexander Graf
2009-09-18 13:00   ` [PATCH 2/5] Don't call svm_complete_interrupts for nested guests Alexander Graf
2009-09-18 13:00     ` [PATCH 3/5] Don't #VMEXIT(INTR) if we still have event_inj waiting Alexander Graf
2009-09-18 13:00       ` [PATCH 4/5] Don't bail when injecting an event in nested SVM Alexander Graf
2009-09-18 13:00         ` [PATCH 5/5] Notify nested hypervisor of lost event injections Alexander Graf
2009-09-23  1:22           ` Joerg Roedel
2009-09-27 14:18           ` Joerg Roedel
2009-09-23  1:39       ` [PATCH 3/5] Don't #VMEXIT(INTR) if we still have event_inj waiting Joerg Roedel
2009-09-23  8:09         ` Alexander Graf
2009-09-18 13:39     ` [PATCH 2/5] Don't call svm_complete_interrupts for nested guests Jan Kiszka
2009-09-23  1:26     ` Joerg Roedel
2009-09-23  8:04       ` Alexander Graf
2009-09-23  8:05       ` Alexander Graf
2009-09-23  8:28         ` Gleb Natapov
2009-09-18 13:33   ` Jan Kiszka [this message]
2009-09-18 15:44     ` [PATCH 1/5] Implement #NMI exiting for nested SVM Alexander Graf
2009-09-18 16:01       ` Jan Kiszka
2009-09-23  1:06   ` Joerg Roedel

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=4AB38C2E.307@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    /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.