On 25/10/19 19:07, Ken Hofsass 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. 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
