From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
Subject: Re: Exposing host debug capabilities to userspace
Date: Fri, 21 Nov 2014 10:29:00 +0000
Message-ID: <871towetjn.fsf@linaro.org>
References: <87mw7l3j7x.fsf@linaro.org> <20141121100823.GT19598@cbox>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Will Deacon <will.deacon@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvmarm@lists.cs.columbia.edu,
	KVM devel mailing list <kvm@vger.kernel.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:46196
	"EHLO socrates.bennee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750810AbaKUK26 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 21 Nov 2014 05:28:58 -0500
In-reply-to: <20141121100823.GT19598@cbox>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


Christoffer Dall <christoffer.dall@linaro.org> writes:

> On Thu, Nov 20, 2014 at 04:55:14PM +0000, Alex Benn=C3=A9e 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 deb=
ug
>> registers are available for GDB to use.
>> * 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 tha=
t
> this is also the vcpu state...

Yeah I was getting confused as to the difference between the two API
calls. Is this just an x86 version of what GET/SET_ONE_REG replaced?

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

However it is general information which might be useful to the whole
system (although I suspect KVM and PTRACE are the only two). It would b=
e
a shame to have an informational API wrapped up in the extra
boiler-plate of a specific API.

--=20
Alex Benn=C3=A9e