Re: Exposing host debug capabilities to userspace

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

Fixed CC:kvmarm, Added: Alexander Graf, Fixed: my From:

Replying to myself with additional information on each option

Alex Bennée <alex.bennee@linaro.org> writes:

> 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)
Nope, guest state API
> * ptrace(PTRACE_GETREGSET, NT_ARM_HW_WATCH)
Nope, ptrace requires attachment and you can't attach to your own thread
group.
> * 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?

I'm minded to re-use this ioctl and define it for ARM as reading the
host debug architecture state ID_AA64DFR0/1_EL1. Currently for x86 it's
used for getting vcpu debug registers which on ARM is handled via the
GET/SET one reg interface.

> * 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.

I suspect this would get complicated depending on the architecture.

> * 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.

So unless there are any objections my intention to re-use the existing
API calls for ARM architectures.

-- 
Alex Bennée