Re: Exposing host debug capabilities to userspace

[Paolo Bonzini <pbonzini@redhat.com>]

On 25/11/2014 17:35, Alexander Graf wrote:
> Unfortunately on ARM you also have a few other constraints - the debug
> register space is partitioned into magic super debug registers at the
> top (with an implementation specific amount) and normal debug registers
> in the lower end of the space.

Does the gdbstub ever need to use the magic super debug registers?  Even
if it does, the logic is the same as x86.  On x86 you might run out of
breakpoints, on ARM you might run out of breakpoints in general or magic
super breakpoints in particular.

> I would just treat gdbstub debugging as the ugly step child that it is
> and not introduce anything special for it (except for debug event
> deflection to user space). Then only ever work on guest debug registers
> and call it a day. Chances are just too high that we get the interfaces
> wrong and shoot ourselves in the foot.

I agree.  But we do need a way to retrieve the number of valid fields in
struct kvm_guest_debug_arch, if that is not architecturally defined
(e.g. on x86 it's just always 4).  A "hidden" ONE_REG, whose existence
is determined by (ARM || ARM64) &&
kvm_check_extension(KVM_CAP_SET_GUEST_DEBUG), is certainly fine and I
like it because it doesn't pollute the global KVM_CAP_* namespace.

The alternative is a capability; however, if you start with two
capabilities you'll end up needing four, and then realize that returning
a struct via ONE_REG would have been a better idea.  :)  We already have
how many breakpoints, how many watchpoints, how many magic super debug
registers,...

Paolo