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. * 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. * 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? * 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. I'm open to any suggestions and look forward to your valued feedback ;-) -- 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
