From: Gleb Natapov <gleb@redhat.com>
To: Jiaqing Du <jiaqing@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: NMI Injection to Guest
Date: Sun, 2 Aug 2009 12:15:39 +0300 [thread overview]
Message-ID: <20090802091539.GT30449@redhat.com> (raw)
In-Reply-To: <6d8082040908010836ka77f4c9hbffc94468448cd3d@mail.gmail.com>
On Sat, Aug 01, 2009 at 05:36:16PM +0200, Jiaqing Du wrote:
> Hi Gleb,
>
> Another problem on AMD processors.
>
> After each vm-exit, I need to check if this vm-exit is due to NMI. For
> vmx.c, I add the check in vmx_complete_interrupts().
>
> The code snippet is:
>
> 3539 if ((exit_intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> INTR_TYPE_NMI_INTR &&
> 3540 (exit_intr_info & INTR_INFO_VALID_MASK)) {
> 3541
> 3542 printk(KERN_INFO "kvm-oprofile: vm exit due to NMI.\n");
> 3543
> 3544 /* indicate vm-exit due to conter overflow */
> 3545 vcpu->vm_exit_on_cntr_overflow = 1;
> 3546 }
>
> This works on Intel chips.
>
> I did the similar check in svm_complete_interrupts().
>
> 2501 static void svm_complete_interrupts(struct vcpu_svm *svm)
> 2502 {
> 2503 u8 vector;
> 2504 int type;
> 2505 u32 exitintinfo = svm->vmcb->control.exit_int_info;
> 2506 struct kvm_vcpu *vcpu = &svm->vcpu;
> 2507
> 2508 if (svm->vcpu.arch.hflags & HF_IRET_MASK)
> 2509 svm->vcpu.arch.hflags &= ~(HF_NMI_MASK | HF_IRET_MASK);
> 2510
> 2511 svm->vcpu.arch.nmi_injected = false;
> 2512 kvm_clear_exception_queue(&svm->vcpu);
> 2513 kvm_clear_interrupt_queue(&svm->vcpu);
> 2514
> 2515 if (!(exitintinfo & SVM_EXITINTINFO_VALID))
> 2516 return;
> 2517
> 2518 vector = exitintinfo & SVM_EXITINTINFO_VEC_MASK;
> 2519 type = exitintinfo & SVM_EXITINTINFO_TYPE_MASK;
> 2520
> 2521 /* kvm-oprofile */
> 2522 if (type == SVM_EXITINTINFO_TYPE_NMI) {
> 2523
> 2524 printk(KERN_INFO "kvm-oprofile:
> counter_overflowed & vm exit.\n");
> 2525 vcpu->vm_exit_on_cntr_overflow = 1;
> 2526 }
>
> However, this part (2522 to 2526) never got executed. By using qemu
> monitor, I managed to inject NMI to the guests. But this check, after
> vm-exit due to NMI, does not succeed.
>
>
The check on AMD is very different from the check on Intel. On AMD you
are checking for IDT access fault during NMI delivery and on Intel you
are checking if the last vmexit was due to NMI delivered to a CPU by HW
while guest was running. On AMD nmi_interception() is called in this
case.
And since MNI interception intercepts only HW NMIs not NMIs that
hypervisor injects your test (using qemu monitor to inject NMI) is
also not valid.
--
Gleb.
prev parent reply other threads:[~2009-08-02 9:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 20:46 NMI Injection to Guest Jiaqing Du
2009-07-26 5:47 ` Gleb Natapov
2009-07-26 19:25 ` Jiaqing Du
2009-07-26 19:41 ` Nipun sehrawat
2009-07-27 5:19 ` Gleb Natapov
2009-07-27 5:17 ` Gleb Natapov
2009-07-30 13:24 ` Jiaqing Du
2009-08-01 15:36 ` Jiaqing Du
2009-08-02 9:15 ` Gleb Natapov [this message]
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=20090802091539.GT30449@redhat.com \
--to=gleb@redhat.com \
--cc=jiaqing@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).