Exposing host debug capabilities to userspace

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

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