On Thu, Oct 24, 2019 at 3:18 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 24/10/19 21:54, Jim Mattson wrote: > > From: Ken Hofsass <hofsass@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx> > > Cc: Peter Shier <pshier@xxxxxxxxxx> > > --- > > 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
