From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: Exposing host debug capabilities to userspace Date: Fri, 21 Nov 2014 11:08:23 +0100 Message-ID: <20141121100823.GT19598@cbox> References: <87mw7l3j7x.fsf@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Will Deacon , Marc Zyngier , Peter Maydell , Paolo Bonzini , kvmarm@list.cs.columbia.edu, KVM devel mailing list To: Alex =?iso-8859-1?Q?Benn=E9e?= Return-path: Received: from mail-lb0-f175.google.com ([209.85.217.175]:51759 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755399AbaKUKOt (ORCPT ); Fri, 21 Nov 2014 05:14:49 -0500 Received: by mail-lb0-f175.google.com with SMTP id u10so852270lbd.20 for ; Fri, 21 Nov 2014 02:14:47 -0800 (PST) Content-Disposition: inline In-Reply-To: <87mw7l3j7x.fsf@linaro.org> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 20, 2014 at 04:55:14PM +0000, Alex Benn=E9e wrote: > Hi, >=20 > I've almost finished the ARMv8 guest debug support but I have one > problem left to solve. userspace needs to know how many hardware debu= g > 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. >=20 > So far the options I've examined are: >=20 > * KVM ioctl GET_ONE_REG(ID_AA64DFR0_EL1) >=20 > 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. >=20 > * ptrace(PTRACE_GETREGSET, NT_ARM_HW_WATCH) >=20 > 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. >=20 > * KVM ioctl KVM_GET_DEBUGREGS >=20 > 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... >=20 > * Export the information via sysfs >=20 > I suppose the correct canonical non-subsystem specific way to make th= is > information available it to expose the data in some sort of sysfs nod= e? > However I don't see any existing sysfs structure for the CPU. >=20 > * Expand /proc/cpuinfo >=20 > I suspect adding extra text to be badly parsed by userspace is just > horrid and unacceptable behaviour ;-) >=20 > * Add another KVM ioctl? >=20 > This would have the downside of being specific to KVM and of course > proliferating the API space again. >=20 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