linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 7/9] arm64: KVM: add trap handlers for AArch32 debug registers
Date: Wed, 28 May 2014 17:00:48 +0100	[thread overview]
Message-ID: <53860830.4080707@arm.com> (raw)
In-Reply-To: <20140525153546.GH3866@lvm>

On 25/05/14 16:35, Christoffer Dall wrote:
> On Tue, May 20, 2014 at 05:55:43PM +0100, Marc Zyngier wrote:
>> Add handlers for all the AArch32 debug registers that are accessible
>> from EL0 or EL1. The code follow the same strategy as the AArch64
>> counterpart with regards to tracking the dirty state of the debug
>> registers.
>>
>> Reviewed-by: Anup Patel <anup.patel@linaro.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_asm.h |   9 +++
>>  arch/arm64/kvm/sys_regs.c        | 137 ++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 145 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
>> index 12f9dd7..993a7db 100644
>> --- a/arch/arm64/include/asm/kvm_asm.h
>> +++ b/arch/arm64/include/asm/kvm_asm.h
>> @@ -93,6 +93,15 @@
>>  #define c10_AMAIR0	(AMAIR_EL1 * 2)	/* Aux Memory Attr Indirection Reg */
>>  #define c10_AMAIR1	(c10_AMAIR0 + 1)/* Aux Memory Attr Indirection Reg */
>>  #define c14_CNTKCTL	(CNTKCTL_EL1 * 2) /* Timer Control Register (PL1) */
>> +
>> +#define cp14_DBGDSCRext	(MDSCR_EL1 * 2)
>> +#define cp14_DBGBCR0	(DBGBCR0_EL1 * 2)
>> +#define cp14_DBGBVR0	(DBGBVR0_EL1 * 2)
>> +#define cp14_DBGBXVR0	(cp14_DBGBVR0 + 1)
>> +#define cp14_DBGWCR0	(DBGWCR0_EL1 * 2)
>> +#define cp14_DBGWVR0	(DBGWVR0_EL1 * 2)
>> +#define cp14_DBGDCCINT	(MDCCINT_EL1 * 2)
>> +
>>  #define NR_COPRO_REGS	(NR_SYS_REGS * 2)
>>  
>>  #define ARM_EXCEPTION_IRQ	  0
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 98d60d1..5960d5b 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -474,12 +474,148 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	  NULL, reset_val, FPEXC32_EL2, 0x70 },
>>  };
>>  
>> +static bool trap_dbgidr(struct kvm_vcpu *vcpu,
>> +			const struct sys_reg_params *p,
>> +			const struct sys_reg_desc *r)
>> +{
>> +	if (p->is_write) {
>> +		return ignore_write(vcpu, p);
>> +	} else {
>> +		u64 dfr = read_cpuid(ID_AA64DFR0_EL1);
>> +		u64 pfr = read_cpuid(ID_AA64PFR0_EL1);
>> +		u32 el3 = !!((pfr >> 12) & 0xf);
>> +
>> +		*vcpu_reg(vcpu, p->Rt) = ((((dfr >> 20) & 0xf) << 28) |
>> +					  (((dfr >> 12) & 0xf) << 24) |
>> +					  (((dfr >> 28) & 0xf) << 20) |
>> +					  (6 << 16) | (el3 << 14) | (el3 << 12));
>> +		return true;
>> +	}
>> +}
>> +
>> +static bool trap_debug32(struct kvm_vcpu *vcpu,
>> +			 const struct sys_reg_params *p,
>> +			 const struct sys_reg_desc *r)
>> +{
>> +	if (p->is_write) {
>> +		vcpu_cp14(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
>> +		vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
>> +	} else {
>> +		*vcpu_reg(vcpu, p->Rt) = vcpu_cp14(vcpu, r->reg);
>> +	}
>> +
>> +	return true;
>> +}
>> +
>> +#define DBG_BCR_BVR_WCR_WVR(n)					\
>> +	/* DBGBCRn */						\
>> +	{ Op1( 0), CRn( 0), CRm((n)), Op2( 4), trap_debug32,	\
>> +	  NULL, (cp14_DBGBCR0 + (n) * 2) },			\
>> +	/* DBGBVRn */						\
>> +	{ Op1( 0), CRn( 0), CRm((n)), Op2( 5), trap_debug32,	\
>> +	  NULL, (cp14_DBGBVR0 + (n) * 2) },			\
> 
> I think you switched the order of DBGBCRn and DBGBVRn here?  Opc2==4 is
> the DBGBVR and Opc2==5 is the DBGBCR0.

I can't get it right, can I? It's amazing that it worked...

>> +	/* DBGWVRn */						\
>> +	{ Op1( 0), CRn( 0), CRm((n)), Op2( 6), trap_debug32,	\
>> +	  NULL, (cp14_DBGWVR0 + (n) * 2) },			\
>> +	/* DBGWCRn */						\
>> +	{ Op1( 0), CRn( 0), CRm((n)), Op2( 7), trap_debug32,	\
>> +	  NULL, (cp14_DBGWCR0 + (n) * 2) }
>> +
>> +#define DBGBXVR(n)						\
>> +	{ Op1( 0), CRn( 1), CRm((n)), Op2( 1), trap_debug32,	\
>> +	  NULL, cp14_DBGBXVR0 + n * 2 }
>> +
>>  /* Trapped cp14 registers */
>>  static const struct sys_reg_desc cp14_regs[] = {
>> +	/* DBGIDR */
>> +	{ Op1( 0), CRn( 0), CRm( 0), Op2( 0), trap_dbgidr },
>> +	/* DBGDTRRXext */
>> +	{ Op1( 0), CRn( 0), CRm( 0), Op2( 2), trap_raz_wi },
>> +
>> +	DBG_BCR_BVR_WCR_WVR(0),
>> +	/* DBGDSCRint */
>> +	{ Op1( 0), CRn( 0), CRm( 1), Op2( 0), trap_raz_wi },
>> +	DBG_BCR_BVR_WCR_WVR(1),
>> +	/* DBGDCCINT */
>> +	{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), trap_debug32 },
>> +	/* DBGDSCRext */
>> +	{ Op1( 0), CRn( 0), CRm( 2), Op2( 2), trap_debug32 },
>> +	DBG_BCR_BVR_WCR_WVR(2),
>> +	/* DBGDTRTXext */
>> +	{ Op1( 0), CRn( 0), CRm( 3), Op2( 2), trap_raz_wi },
>> +	DBG_BCR_BVR_WCR_WVR(3),
>> +	DBG_BCR_BVR_WCR_WVR(4),
> 
> So we don't have a handler for the TRRX_int (nor the TRRX_EL0).  I
> understand that it doesn't make sense to keep state for them or
> context-switch them, but do we never trap on these and if we do, is it
> then always valid to inject an undefined exception?

TRRXint has clearly been forgotten (Linux doesn't use it). TRRX_EL0 is
actually handled (see the comment that says DBGDTR[TR]X_EL0 in patch 3).

>> +	DBG_BCR_BVR_WCR_WVR(5),
>> +	/* DBGWFAR */
>> +	{ Op1( 0), CRn( 0), CRm( 6), Op2( 0), trap_raz_wi },
>> +	/* DBGOSECCR */
>> +	{ Op1( 0), CRn( 0), CRm( 6), Op2( 2), trap_raz_wi },
> 
> So it seems that we generally ignore everything related to external
> debug state, but we don't really document anywhere what our behavior is
> and what is and what is not supported towards the guest...

Happy to document that.

>> +	DBG_BCR_BVR_WCR_WVR(6),
>> +	/* DBGVCR */
>> +	{ Op1( 0), CRn( 0), CRm( 7), Op2( 0), trap_debug32 },
>> +	DBG_BCR_BVR_WCR_WVR(7),
>> +	DBG_BCR_BVR_WCR_WVR(8),
>> +	DBG_BCR_BVR_WCR_WVR(9),
>> +	DBG_BCR_BVR_WCR_WVR(10),
>> +	DBG_BCR_BVR_WCR_WVR(11),
>> +	DBG_BCR_BVR_WCR_WVR(12),
>> +	DBG_BCR_BVR_WCR_WVR(13),
>> +	DBG_BCR_BVR_WCR_WVR(14),
>> +	DBG_BCR_BVR_WCR_WVR(15),
>> +
>> +	/* DBGDRAR (32bit) */
>> +	{ Op1( 0), CRn( 1), CRm( 0), Op2( 0), trap_raz_wi },
>> +
>> +	DBGBXVR(0),
>> +	/* DBGOSLAR */
>> +	{ Op1( 0), CRn( 1), CRm( 0), Op2( 4), trap_raz_wi },
>> +	DBGBXVR(1),
>> +	/* DBGOSLSR */
>> +	{ Op1( 0), CRn( 1), CRm( 1), Op2( 4), trap_oslsr_el1 },
>> +	DBGBXVR(2),
>> +	DBGBXVR(3),
>> +	/* DBGOSDLR */
>> +	{ Op1( 0), CRn( 1), CRm( 3), Op2( 4), trap_raz_wi },
>> +	DBGBXVR(4),
>> +	/* DBGPRCR */
>> +	{ Op1( 0), CRn( 1), CRm( 4), Op2( 4), trap_raz_wi },
>> +	DBGBXVR(5),
>> +	DBGBXVR(6),
>> +	DBGBXVR(7),
>> +	DBGBXVR(8),
>> +	DBGBXVR(9),
>> +	DBGBXVR(10),
>> +	DBGBXVR(11),
>> +	DBGBXVR(12),
>> +	DBGBXVR(13),
>> +	DBGBXVR(14),
>> +	DBGBXVR(15),
>> +
>> +	/* DBGDSAR (32bit) */
>> +	{ Op1( 0), CRn( 2), CRm( 0), Op2( 0), trap_raz_wi },
>> +
> 
> we don't handle access to any implementation defined debug registers?
> Did we actually check what would be implemented for the cores we
> support?

No. So far, I've stuck with what the ARM ARM describe. Unless you're
thinking of a particular register I may ignored?

>> +	/* DBGDEVID2 */
>> +	{ Op1( 0), CRn( 7), CRm( 0), Op2( 7), trap_raz_wi },
>> +	/* DBGDEVID1 */
>> +	{ Op1( 0), CRn( 7), CRm( 1), Op2( 7), trap_raz_wi },
>> +	/* DBGDEVID */
>> +	{ Op1( 0), CRn( 7), CRm( 2), Op2( 7), trap_raz_wi },
>> +	/* DBGCLAIMSET */
>> +	{ Op1( 0), CRn( 7), CRm( 8), Op2( 6), trap_raz_wi },
>> +	/* DBGCLAIMCLR */
>> +	{ Op1( 0), CRn( 7), CRm( 9), Op2( 6), trap_raz_wi },
>> +
> 
> nit: why the sudden blank line?
> 
>> +	/* DBGAUTHSTATUS */
>> +	{ Op1( 0), CRn( 7), CRm(14), Op2( 6), trap_dbgauthstatus_el1 },
>>  };
>>  
>>  /* Trapped cp14 64bit registers */
>>  static const struct sys_reg_desc cp14_64_regs[] = {
>> +	/* DBGDRAR (64bit) */
>> +	{ Op1( 0), CRm( 1), .access = trap_raz_wi },
>> +
>> +	/* DBGDSAR (64bit) */
>> +	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
>>  };
>>  
>>  /*
>> @@ -527,7 +663,6 @@ static const struct sys_reg_desc cp15_regs[] = {
>>  	{ Op1( 0), CRn(10), CRm( 3), Op2( 0), access_vm_reg, NULL, c10_AMAIR0 },
>>  	{ Op1( 0), CRn(10), CRm( 3), Op2( 1), access_vm_reg, NULL, c10_AMAIR1 },
>>  	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
>> -
>>  };
>>  
>>  static const struct sys_reg_desc cp15_64_regs[] = {
>> -- 
>> 1.8.3.4
>>
> 


-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2014-05-28 16:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 16:55 [PATCH v2 0/9] arm64: KVM: debug infrastructure support Marc Zyngier
2014-05-20 16:55 ` [PATCH v2 1/9] arm64: KVM: rename pm_fake handler to trap_raz_wi Marc Zyngier
2014-05-25 15:34   ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 2/9] arm64: move DBG_MDSCR_* to asm/debug-monitors.h Marc Zyngier
2014-05-25 15:34   ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 3/9] arm64: KVM: add trap handlers for AArch64 debug registers Marc Zyngier
2014-05-25 15:34   ` Christoffer Dall
2014-05-28 10:27     ` Marc Zyngier
2014-05-20 16:55 ` [PATCH v2 4/9] arm64: KVM: common infrastructure for handling AArch32 CP14/CP15 Marc Zyngier
2014-05-25 15:34   ` Christoffer Dall
2014-05-28 10:34     ` Marc Zyngier
2014-05-20 16:55 ` [PATCH v2 5/9] arm64: KVM: use separate tables for AArch32 32 and 64bit traps Marc Zyngier
2014-05-25 15:35   ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 6/9] arm64: KVM: check ordering of all system register tables Marc Zyngier
2014-05-25 15:35   ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 7/9] arm64: KVM: add trap handlers for AArch32 debug registers Marc Zyngier
2014-05-25 15:35   ` Christoffer Dall
2014-05-28 16:00     ` Marc Zyngier [this message]
2014-05-29  8:53       ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 8/9] arm64: KVM: implement lazy world switch for " Marc Zyngier
2014-05-25 15:35   ` Christoffer Dall
2014-05-20 16:55 ` [PATCH v2 9/9] arm64: KVM: enable trapping of all " Marc Zyngier
2014-05-25 15:36   ` Christoffer Dall
2014-05-28 16:10     ` Marc Zyngier
2014-05-29  8:55       ` Christoffer Dall
2014-05-25 15:34 ` [PATCH v2 0/9] arm64: KVM: debug infrastructure support Christoffer Dall
2014-05-28  9:56   ` Marc Zyngier
2014-05-28  9:58     ` Christoffer Dall
2014-05-28 10:11       ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53860830.4080707@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).