From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v2 0/9] arm64: KVM: debug infrastructure support
Date: Wed, 28 May 2014 11:58:33 +0200
Message-ID: <20140528095833.GO16428@lvm>
References: <1400604945-25247-1-git-send-email-marc.zyngier@arm.com>
 <20140525153421.GA3866@lvm>
 <5385B2DD.8090200@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Anup Patel <anup.patel@linaro.org>,
	Peter Maydell <peter.maydell@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-la0-f49.google.com ([209.85.215.49]:64132 "EHLO
	mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751713AbaE1J6h (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 28 May 2014 05:58:37 -0400
Received: by mail-la0-f49.google.com with SMTP id pv20so7027893lab.8
        for <kvm@vger.kernel.org>; Wed, 28 May 2014 02:58:36 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <5385B2DD.8090200@arm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, May 28, 2014 at 10:56:45AM +0100, Marc Zyngier wrote:
> On 25/05/14 16:34, Christoffer Dall wrote:
> > On Tue, May 20, 2014 at 05:55:36PM +0100, Marc Zyngier wrote:
> >> This patch series adds debug support, a key feature missing from the
> >> KVM/arm64 port.
> >>
> >> The main idea is to keep track of whether the debug registers are
> >> "dirty" (changed by the guest) or not. In this case, perform the usual
> >> save/restore dance, for one run only. It means we only have a penalty
> >> if a guest is actively using the debug registers.
> >>
> >> The amount of registers is properly frightening, but CPUs actually
> >> only implement a subset of them. Also, there is a number of registers
> >> we don't bother emulating (things having to do with external debug and
> >> OSlock).
> > 
> > What is the rationale about not having to deal with external debug and
> > OSlock?
> 
> External debug is when you actually plug a physical JTAG into the CPU.
> OSlock is a way to prevent "other software" to play with the debug
> registers. My understanding is that it is only useful in combination
> with the external debug.
> 
> In both case, implementing support for this is probably not worth the
> effort, at least for the time being.
> 
OK, can we document that somewhere clearly in the code then so we know
how we can simply ignore those registers?

Thanks,
-Christoffer