On Fri, Oct 25, 2019 at 10:07 AM Ken Hofsass <hofsass@xxxxxxxxxx> wrote: > > 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 Another possibility would be to add flags to KVM_SET_GET_DEBUG that request a SYNC_REGS on a breakpoint or single step.
