Paolo Bonzini <pbonzini@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
