From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: VMX: Update instruction length on intercepted BP
Date: Sun, 14 Feb 2010 13:39:41 +0100 [thread overview]
Message-ID: <4B77EF0D.4050303@web.de> (raw)
In-Reply-To: <4B77EC14.4000302@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]
Avi Kivity wrote:
> On 02/14/2010 12:34 PM, Gleb Natapov wrote:
>>>>
>>>> event_exit_inst_len is only used for event reinjection. Since event
>>>> intercepted here will not be reinjected why updating
>>>> event_exit_inst_len
>>>> is needed here?
>>>>
>>> In guest debugging mode a #BP exception is always reported to user space
>>> to find out what caused it. If it was the guest itself, the exception is
>>> reinjected, on older kernels via KVM_SET_GUEST_DEBUG and since 2.6.33
>>> via KVM_SET_VCPU_EVENTS (the latter requires some qemu patch that I will
>>> post later).
>>>
>>> As we currently do not update event_exit_inst_len on #BP exits,
>>> reinjecting fails unless event_exit_inst_len happens to be 1 from some
>>> other exit.
>>>
>>>
>> Hmm, how does it work on SVM then where we do not have
>> event_exit_inst_len so execution will resume on the same rip that caused
>> #BP after event reinjection?
>>
>>
>
> Note, newer AMDs do have such a field (nRIP, 0xC8). We need to support
> older machines, though.
>
Nice.
[ /me goes updating his manual - September 07... ]
Actually, emulation via single-stepping should work as only #DB clears
the TF on entry. So this draft may fly (nothing to test on at hand):
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 52f78dd..450c1e7 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -109,6 +109,7 @@ struct vcpu_svm {
struct nested_state nested;
bool nmi_singlestep;
+ bool bp_singlestep;
};
/* enable NPT for AMD64 and X86 with PAE */
@@ -244,6 +245,19 @@ static void svm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
if (nested_svm_check_exception(svm, nr, has_error_code, error_code))
return;
+ if (nr == BP_VECTOR && vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
+ /*
+ * Temporarily disable BP interception so that the trap is
+ * properly delivered to the guest (if we left it on, SVM
+ * would push the wrong IP on the stack).
+ * We single-step into theexception handler in order to
+ * reenble interception ASAP.
+ */
+ svm->vmcb->control.intercept_exceptions &= ~(1 << BP_VECTOR);
+ svm->bp_singlestep = true;
+ svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
+ }
+
svm->vmcb->control.event_inj = nr
| SVM_EVTINJ_VALID
| (has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
@@ -1083,7 +1097,8 @@ static void update_db_intercept(struct kvm_vcpu *vcpu)
(KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))
svm->vmcb->control.intercept_exceptions |=
1 << DB_VECTOR;
- if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP &&
+ !svm->bp_singlestep)
svm->vmcb->control.intercept_exceptions |=
1 << BP_VECTOR;
} else
@@ -1214,7 +1229,7 @@ static int db_interception(struct vcpu_svm *svm)
if (!(svm->vcpu.guest_debug &
(KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) &&
- !svm->nmi_singlestep) {
+ !svm->nmi_singlestep && !svm->bp_singlestep) {
kvm_queue_exception(&svm->vcpu, DB_VECTOR);
return 1;
}
@@ -1227,6 +1242,14 @@ static int db_interception(struct vcpu_svm *svm)
update_db_intercept(&svm->vcpu);
}
+ if (svm->bp_singlestep) {
+ svm->bp_singlestep = false;
+ if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP))
+ svm->vmcb->save.rflags &=
+ ~(X86_EFLAGS_TF | X86_EFLAGS_RF);
+ update_db_intercept(&svm->vcpu);
+ }
+
if (svm->vcpu.guest_debug &
(KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)){
kvm_run->exit_reason = KVM_EXIT_DEBUG;
But it requires a bit more work as I just realized that already
nmi_singlestep could cause spurious #DB reports to user space that may
propagate to the guest in the end.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-02-14 12:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-13 9:31 [PATCH] KVM: VMX: Update instruction length on intercepted BP Jan Kiszka
2010-02-14 7:53 ` Gleb Natapov
2010-02-14 10:26 ` Jan Kiszka
2010-02-14 10:34 ` Gleb Natapov
2010-02-14 10:47 ` Jan Kiszka
2010-02-14 11:15 ` Gleb Natapov
2010-02-14 11:39 ` Jan Kiszka
2010-02-14 14:16 ` Avi Kivity
2010-02-14 16:38 ` Jan Kiszka
2010-02-14 16:44 ` Avi Kivity
2010-02-14 17:06 ` Jan Kiszka
2010-02-15 6:48 ` Avi Kivity
2010-02-14 14:45 ` Gleb Natapov
2010-02-14 16:37 ` Jan Kiszka
2010-02-14 16:53 ` Gleb Natapov
2010-02-14 17:06 ` Jan Kiszka
2010-02-14 17:26 ` Gleb Natapov
2010-02-14 17:49 ` Jan Kiszka
2010-02-15 13:20 ` Jan Kiszka
2010-02-15 13:30 ` Gleb Natapov
2010-02-15 14:25 ` Jan Kiszka
2010-02-17 11:11 ` Avi Kivity
2010-02-17 11:13 ` Gleb Natapov
2010-02-17 11:24 ` Jan Kiszka
2010-02-17 12:39 ` Gleb Natapov
2010-02-17 10:55 ` Gleb Natapov
2010-02-17 11:32 ` Jan Kiszka
2010-02-17 13:03 ` Gleb Natapov
2010-02-17 15:13 ` Jan Kiszka
2010-02-17 16:11 ` Gleb Natapov
2010-02-16 11:20 ` Gleb Natapov
2010-02-16 11:25 ` Gleb Natapov
2010-02-14 12:27 ` Avi Kivity
2010-02-14 12:39 ` Jan Kiszka [this message]
2010-02-14 12:43 ` Gleb Natapov
2010-02-14 12:47 ` Avi Kivity
2010-02-14 12:53 ` Gleb Natapov
2010-02-14 13:23 ` Jan Kiszka
2010-02-14 13:29 ` Jan Kiszka
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=4B77EF0D.4050303@web.de \
--to=jan.kiszka@web.de \
--cc=avi@redhat.com \
--cc=gleb@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox