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