Re: Exposing host debug capabilities to userspace

[Christoffer Dall <christoffer.dall@linaro.org>]

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