Re: Exposing host debug capabilities to userspace

["Alex Bennée" <alex.bennee@linaro.org>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.

By default gdbstub uses normal software breakpoints unless a) the user
asks for a HW one or b) the memory is RO (i.e a ROM). For watchpoints
the situation is reversed and they are used by default if available.

>> 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).

It's IMPDEF (implementation defined) up to a maximum of 16.

> 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.

My original implementation more or less did that but my main worry is
migration code tends to iterate over the whole ONE_REG list and
introducing a value that doesn't happen to be strictly the guests is
semantically impure. Of course if you mean by "hidden" don't export it
via GET_REG_LIST then I guess that would work. Does seem a little ugly
as the internal KVM code now needs to learn about hidden and non-hidden
registers.

> 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,...

Only two, not sure what the super debug registers are?

Certainly on the QEMU side the capability based approach is beautifully
simple:

    max_hw_wp = kvm_check_extension(cs->kvm_state, KVM_CAP_GUEST_DEBUG_HW_WPS);
    max_hw_bp = kvm_check_extension(cs->kvm_state, KVM_CAP_GUEST_DEBUG_HW_BPS);

thanks to kvm_check_extension zeroing failure modes.

And in it's defence it's a generic enough capability to be used across
any other architectures that need to expose this information compared to
the many PPC specific capabilities. Perhaps a KVM_ARCH_EXTENSION ioctl
would be more useful in reducing the growth of the space?

>
> Paolo

-- 
Alex Bennée