On Thu, Nov 20, 2014 at 04:55:14PM +0000, Alex Bennée wrote: > Hi, > > I've almost finished the ARMv8 guest debug support but I have one > problem left to solve. userspace needs to know how many hardware debug > registers are available for GDB to use. This information is available > from the ID_AA64DFR0_EL1 register. Currently I abuse GET_ONE_REG to > fetch it's value however semantically this is poor as it's API is for > getting guest state not host state and they could theoretically have > different values. > > So far the options I've examined are: > > * KVM ioctl GET_ONE_REG(ID_AA64DFR0_EL1) > > As explained above, abusing a guest state API for host configuration. It's just wrong, and we should only do this if there's absolutely no other way to do this. > > * ptrace(PTRACE_GETREGSET, NT_ARM_HW_WATCH) > > This is used by GDB to access the host details in debug-monitors. > However the ptrace API really wants you to attach to a process before > calling PTRACE_GETREGSET. Currently I've tried attaching to the > thread_id of the vCPU but this fails with EPERM, I suspect because > attaching to your own threads likely upsets the kernel. Can you confirm your suspicion? This seems like a rather good approach so we should really investigate why this doesn't work and explore ways to get it working. > > * KVM ioctl KVM_GET_DEBUGREGS > > This is currently x86 only and looks like it's more aimed at debug > registers than capability stuff. Also I'm not sure what the state of > this ioctl is compared to KVM_SET_GUEST_DEBUG. Do these APIs overlap or > is one an older deprecated x86 only API? The API text and a brief glance of the x86 code seems to indicate that this is also the vcpu state... > > * Export the information via sysfs > > I suppose the correct canonical non-subsystem specific way to make this > information available it to expose the data in some sort of sysfs node? > However I don't see any existing sysfs structure for the CPU. > > * Expand /proc/cpuinfo > > I suspect adding extra text to be badly parsed by userspace is just > horrid and unacceptable behaviour ;-) > > * Add another KVM ioctl? > > This would have the downside of being specific to KVM and of course > proliferating the API space again. > This may not be that bad, for example, could we ever imaging that we'd only want to export a few of the debug registers for host gdbstub usage? -Christoffer -- 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
