* [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
@ 2019-10-24 19:54 Jim Mattson
2019-10-24 20:21 ` Sean Christopherson
2019-10-24 22:17 ` Paolo Bonzini
0 siblings, 2 replies; 6+ messages in thread
From: Jim Mattson @ 2019-10-24 19:54 UTC (permalink / raw)
To: kvm, Paolo Bonzini; +Cc: Ken Hofsass, Jim Mattson, Peter Shier
From: Ken Hofsass <hofsass@google.com>
A userspace agent can use cr3 to quickly determine whether a
KVM_EXIT_DEBUG is associated with a guest process of interest.
KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
Signed-off-by: Ken Hofsass <hofsass@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Cc: Peter Shier <pshier@google.com>
---
v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
kvm_vcpu_check_breakpoint
Added svm support
arch/x86/include/uapi/asm/kvm.h | 1 +
arch/x86/kvm/svm.c | 3 +++
arch/x86/kvm/vmx/vmx.c | 2 ++
arch/x86/kvm/x86.c | 3 +++
include/uapi/linux/kvm.h | 1 +
5 files changed, 10 insertions(+)
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 503d3f42da167..cea355c7ee8e7 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -254,6 +254,7 @@ struct kvm_debug_exit_arch {
__u64 pc;
__u64 dr6;
__u64 dr7;
+ __u64 cr3; /* Depends on KVM_CAP_DEBUG_EVENT_PDBR */
};
#define KVM_GUESTDBG_USE_SW_BP 0x00010000
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f8ecb6df51066..1a774d2c78eef 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2738,6 +2738,7 @@ static int db_interception(struct vcpu_svm *svm)
kvm_run->exit_reason = KVM_EXIT_DEBUG;
kvm_run->debug.arch.pc =
svm->vmcb->save.cs.base + svm->vmcb->save.rip;
+ kvm_run->debug.arch.cr3 = kvm_read_cr3(vcpu);
kvm_run->debug.arch.exception = DB_VECTOR;
return 0;
}
@@ -2748,9 +2749,11 @@ static int db_interception(struct vcpu_svm *svm)
static int bp_interception(struct vcpu_svm *svm)
{
struct kvm_run *kvm_run = svm->vcpu.run;
+ struct kvm_vcpu *vcpu = &svm->vcpu;
kvm_run->exit_reason = KVM_EXIT_DEBUG;
kvm_run->debug.arch.pc = svm->vmcb->save.cs.base + svm->vmcb->save.rip;
+ kvm_run->debug.arch.cr3 = kvm_read_cr3(vcpu);
kvm_run->debug.arch.exception = BP_VECTOR;
return 0;
}
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index e7970a2e8eae9..736284d293c4a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4690,6 +4690,7 @@ static int handle_exception_nmi(struct kvm_vcpu *vcpu)
kvm_run->exit_reason = KVM_EXIT_DEBUG;
rip = kvm_rip_read(vcpu);
kvm_run->debug.arch.pc = vmcs_readl(GUEST_CS_BASE) + rip;
+ kvm_run->debug.arch.cr3 = kvm_read_cr3(vcpu);
kvm_run->debug.arch.exception = ex_no;
break;
default:
@@ -4909,6 +4910,7 @@ static int handle_dr(struct kvm_vcpu *vcpu)
vcpu->run->debug.arch.dr6 = vcpu->arch.dr6;
vcpu->run->debug.arch.dr7 = dr7;
vcpu->run->debug.arch.pc = kvm_get_linear_rip(vcpu);
+ vcpu->run->debug.arch.cr3 = kvm_read_cr3(vcpu);
vcpu->run->debug.arch.exception = DB_VECTOR;
vcpu->run->exit_reason = KVM_EXIT_DEBUG;
return 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 661e2bf385266..2fd18b55462a9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3222,6 +3222,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_GET_MSR_FEATURES:
case KVM_CAP_MSR_PLATFORM_INFO:
case KVM_CAP_EXCEPTION_PAYLOAD:
+ case KVM_CAP_DEBUG_EVENT_PDBR:
r = 1;
break;
case KVM_CAP_SYNC_REGS:
@@ -6490,6 +6491,7 @@ static int kvm_vcpu_do_singlestep(struct kvm_vcpu *vcpu)
if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | DR6_RTM;
kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
+ kvm_run->debug.arch.cr3 = kvm_read_cr3(vcpu);
kvm_run->debug.arch.exception = DB_VECTOR;
kvm_run->exit_reason = KVM_EXIT_DEBUG;
return 0;
@@ -6534,6 +6536,7 @@ static bool kvm_vcpu_check_breakpoint(struct kvm_vcpu *vcpu, int *r)
if (dr6 != 0) {
kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1 | DR6_RTM;
kvm_run->debug.arch.pc = eip;
+ kvm_run->debug.arch.cr3 = kvm_read_cr3(vcpu);
kvm_run->debug.arch.exception = DB_VECTOR;
kvm_run->exit_reason = KVM_EXIT_DEBUG;
*r = 0;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 52641d8ca9e83..cde4b28338482 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1000,6 +1000,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_PMU_EVENT_FILTER 173
#define KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 174
#define KVM_CAP_HYPERV_DIRECT_TLBFLUSH 175
+#define KVM_CAP_DEBUG_EVENT_PDBR 176
#ifdef KVM_CAP_IRQ_ROUTING
--
2.24.0.rc0.303.g954a862665-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
2019-10-24 19:54 [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch Jim Mattson
@ 2019-10-24 20:21 ` Sean Christopherson
2019-10-24 22:17 ` Paolo Bonzini
1 sibling, 0 replies; 6+ messages in thread
From: Sean Christopherson @ 2019-10-24 20:21 UTC (permalink / raw)
To: Jim Mattson; +Cc: kvm, Paolo Bonzini, Ken Hofsass, Peter Shier
On Thu, Oct 24, 2019 at 12:54:31PM -0700, Jim Mattson wrote:
> From: Ken Hofsass <hofsass@google.com>
>
> A userspace agent can use cr3 to quickly determine whether a
> KVM_EXIT_DEBUG is associated with a guest process of interest.
>
> KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
Isn't PDBR x86-specific terminology? If we're going to use something that
is x86-specific then just call it GUEST_CR3. If there's a chance that
this is useful on other architectures then it'd probably be better to go
with Linux's own terminology, e.g. KVM_CAP_DEBUG_EVENT_GUEST_PGD.
> Signed-off-by: Ken Hofsass <hofsass@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> Cc: Peter Shier <pshier@google.com>
> ---
> v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
> Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
> kvm_vcpu_check_breakpoint
> Added svm support
Heh, I wonder what the record is for longest time between legitimate
versions of a single patch.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
2019-10-24 19:54 [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch Jim Mattson
2019-10-24 20:21 ` Sean Christopherson
@ 2019-10-24 22:17 ` Paolo Bonzini
2019-10-25 17:07 ` Ken Hofsass
1 sibling, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2019-10-24 22:17 UTC (permalink / raw)
To: Jim Mattson, kvm; +Cc: Ken Hofsass, Peter Shier
On 24/10/19 21:54, Jim Mattson wrote:
> From: Ken Hofsass <hofsass@google.com>
>
> A userspace agent can use cr3 to quickly determine whether a
> KVM_EXIT_DEBUG is associated with a guest process of interest.
>
> KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
>
> Signed-off-by: Ken Hofsass <hofsass@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> Cc: Peter Shier <pshier@google.com>
> ---
> v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
> Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
> kvm_vcpu_check_breakpoint
> Added svm support
Perhaps you have already considered using KVM_CAP_SYNC_REGS instead,
since Google contributed it in the first place, but anyway... would it
be enough for userspace to request KVM_SYNC_X86_SREGS when it enables
breakpoints or singlestep?
Thanks,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
2019-10-24 22:17 ` Paolo Bonzini
@ 2019-10-25 17:07 ` Ken Hofsass
2019-11-05 19:59 ` Jim Mattson
2019-11-05 22:23 ` Paolo Bonzini
0 siblings, 2 replies; 6+ messages in thread
From: Ken Hofsass @ 2019-10-25 17:07 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Jim Mattson, kvm, Peter Shier
On Thu, Oct 24, 2019 at 3:18 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 24/10/19 21:54, Jim Mattson wrote:
> > From: Ken Hofsass <hofsass@google.com>
> >
> > A userspace agent can use cr3 to quickly determine whether a
> > KVM_EXIT_DEBUG is associated with a guest process of interest.
> >
> > KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
> >
> > Signed-off-by: Ken Hofsass <hofsass@google.com>
> > Signed-off-by: Jim Mattson <jmattson@google.com>
> > Cc: Peter Shier <pshier@google.com>
> > ---
> > v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
> > Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
> > kvm_vcpu_check_breakpoint
> > Added svm support
>
> Perhaps you have already considered using KVM_CAP_SYNC_REGS instead,
> since Google contributed it in the first place, but anyway... would it
> be enough for userspace to request KVM_SYNC_X86_SREGS when it enables
> breakpoints or singlestep?
Hi Paolo, from a functional perspective, using KVM_SYNC_X86_SREGS is
totally reasonable. But it currently introduces a non-trivial amount
of overhead because it affects all exits.
This change is a targeted optimization for use in instrumentation
scenarios. Specifically where debug breakpoint exits are a small
percentage of total exits and only a small percentage of the debug
exits are from processes of interest.
thanks,
Ken
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
2019-10-25 17:07 ` Ken Hofsass
@ 2019-11-05 19:59 ` Jim Mattson
2019-11-05 22:23 ` Paolo Bonzini
1 sibling, 0 replies; 6+ messages in thread
From: Jim Mattson @ 2019-11-05 19:59 UTC (permalink / raw)
To: Ken Hofsass; +Cc: Paolo Bonzini, kvm, Peter Shier
On Fri, Oct 25, 2019 at 10:07 AM Ken Hofsass <hofsass@google.com> wrote:
>
> On Thu, Oct 24, 2019 at 3:18 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 24/10/19 21:54, Jim Mattson wrote:
> > > From: Ken Hofsass <hofsass@google.com>
> > >
> > > A userspace agent can use cr3 to quickly determine whether a
> > > KVM_EXIT_DEBUG is associated with a guest process of interest.
> > >
> > > KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
> > >
> > > Signed-off-by: Ken Hofsass <hofsass@google.com>
> > > Signed-off-by: Jim Mattson <jmattson@google.com>
> > > Cc: Peter Shier <pshier@google.com>
> > > ---
> > > v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
> > > Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
> > > kvm_vcpu_check_breakpoint
> > > Added svm support
> >
> > Perhaps you have already considered using KVM_CAP_SYNC_REGS instead,
> > since Google contributed it in the first place, but anyway... would it
> > be enough for userspace to request KVM_SYNC_X86_SREGS when it enables
> > breakpoints or singlestep?
>
> Hi Paolo, from a functional perspective, using KVM_SYNC_X86_SREGS is
> totally reasonable. But it currently introduces a non-trivial amount
> of overhead because it affects all exits.
>
> This change is a targeted optimization for use in instrumentation
> scenarios. Specifically where debug breakpoint exits are a small
> percentage of total exits and only a small percentage of the debug
> exits are from processes of interest.
>
> thanks,
> Ken
Another possibility would be to add flags to KVM_SET_GET_DEBUG that
request a SYNC_REGS on a breakpoint or single step.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch
2019-10-25 17:07 ` Ken Hofsass
2019-11-05 19:59 ` Jim Mattson
@ 2019-11-05 22:23 ` Paolo Bonzini
1 sibling, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2019-11-05 22:23 UTC (permalink / raw)
To: Ken Hofsass; +Cc: Jim Mattson, kvm, Peter Shier
On 25/10/19 19:07, Ken Hofsass wrote:
> On Thu, Oct 24, 2019 at 3:18 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 24/10/19 21:54, Jim Mattson wrote:
>>> From: Ken Hofsass <hofsass@google.com>
>>>
>>> A userspace agent can use cr3 to quickly determine whether a
>>> KVM_EXIT_DEBUG is associated with a guest process of interest.
>>>
>>> KVM_CAP_DEBUG_EVENT_PDBR indicates support for the extension.
>>>
>>> Signed-off-by: Ken Hofsass <hofsass@google.com>
>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>> Cc: Peter Shier <pshier@google.com>
>>> ---
>>> v1 -> v2: Changed KVM_CAP_DEBUG_EVENT_PG_BASE_ADDR to KVM_CAP_DEBUG_EVENT_PDBR
>>> Set debug.arch.cr3 in kvm_vcpu_do_singlestep and
>>> kvm_vcpu_check_breakpoint
>>> Added svm support
>>
>> Perhaps you have already considered using KVM_CAP_SYNC_REGS instead,
>> since Google contributed it in the first place, but anyway... would it
>> be enough for userspace to request KVM_SYNC_X86_SREGS when it enables
>> breakpoints or singlestep?
>
> Hi Paolo, from a functional perspective, using KVM_SYNC_X86_SREGS is
> totally reasonable. But it currently introduces a non-trivial amount
> of overhead because it affects all exits.
>
> This change is a targeted optimization for use in instrumentation
> scenarios. Specifically where debug breakpoint exits are a small
> percentage of total exits and only a small percentage of the debug
> exits are from processes of interest.
Sorry for the delayed response, mostly due to KVM Forum.
Is this due to Google's non-upstream userspace emulation patches? With
a properly configured guest and in-kernel emulation, userspace exits
should be so few as to make KVM_CAP_SYNC_REGS's overhead low.
But in any case, what about adding a new KVM_SYNC_X86_CR3 that is a
subset of SREGS?
Thanks,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-05 22:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-24 19:54 [PATCH v2] kvm: x86: Add cr3 to struct kvm_debug_exit_arch Jim Mattson
2019-10-24 20:21 ` Sean Christopherson
2019-10-24 22:17 ` Paolo Bonzini
2019-10-25 17:07 ` Ken Hofsass
2019-11-05 19:59 ` Jim Mattson
2019-11-05 22:23 ` Paolo Bonzini
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).