Re: Exposing host debug capabilities to userspace

[Paolo Bonzini <pbonzini@redhat.com>]

On 24/11/2014 14:59, Alex Bennée wrote:
> Alexander Graf pointed out that KVM_CHECK_EXTENSION can return any
> positive number for success. How about using:
> 
> max_hw_bps = kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW_BPS);
> max_hw_wps = kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW_WPS);
> 
> Seems pretty sane, doesn't change the semantics of an API and is
> architecture agnostic if others need the number?

Yes, this was going to be my suggestion as well.  Just I would use a
bitmask in case some register can act as both breakpoint and watchpoint.

On x86, each of the four bp/wp registers (each register can act as both)
can be used for either guest or gdbstub debugging.  If the
KVM_GUESTDBG_USE_HW_BP feature is enabled, the guest is entered with
"made up" debug register contents, that we pass via
KVM_SET_GUEST_DEBUG's struct kvm_guest_debug_arch.  Otherwise, the guest
is entered with real debug register contents passed via
KVM_SET_DEBUGREGS.  Reads/writes of the debug registers trap to KVM
(which helps the guest see the expected values of the debug registers in
the former case).  There is no KVM_GET_GUEST_DEBUG because the
corresponding info is passed via struct kvm_debug_exit_arch.

If gdbstub hardware breakpoints are enabled, all hardware breakpoints
exit to userspace.  QEMU then decides whether the breakpoint came from
guest debugging (and then injects an exception), or from gdbstub
debugging (and then suspends execution).  Same for software breakpoints.
 If the total request is >4 hardware breakpoints, someone will have to
lose and some gdbstub breakpoints will be missed.

Paolo