From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aReYo-0004wG-N0 for qemu-devel@nongnu.org; Fri, 05 Feb 2016 06:28:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aReYn-0001dw-O8 for qemu-devel@nongnu.org; Fri, 05 Feb 2016 06:28:22 -0500 Received: from mail-vk0-x22b.google.com ([2607:f8b0:400c:c05::22b]:34667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aReYn-0001cw-8J for qemu-devel@nongnu.org; Fri, 05 Feb 2016 06:28:21 -0500 Received: by mail-vk0-x22b.google.com with SMTP id e185so54543856vkb.1 for ; Fri, 05 Feb 2016 03:28:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <87powbo1ei.fsf@linaro.org> References: <1454506721-11843-1-git-send-email-peter.maydell@linaro.org> <1454506721-11843-3-git-send-email-peter.maydell@linaro.org> <87powbo1ei.fsf@linaro.org> From: Peter Maydell Date: Fri, 5 Feb 2016 11:28:01 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/7] target-arm: Implement MDCR_EL3 and SDCR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: "Edgar E. Iglesias" , qemu-arm , QEMU Developers , Patch Tracking On 5 February 2016 at 11:13, Alex Benn=C3=A9e wrot= e: > Peter Maydell writes: >> Implement the MDCR_EL3 register (which is SDCR for AArch32). >> For the moment we implement it as reads-as-written. >> >> Signed-off-by: Peter Maydell >> +/* Some secure-only AArch32 registers trap to EL3 if used from >> + * Secure EL1 (but are just ordinary UNDEF in other non-EL3 contexts). >> + * We assume that the .access field is set to PL1_RW. >> + */ >> +static CPAccessResult access_trap_aa32s_el1(CPUARMState *env, >> + const ARMCPRegInfo *ri) >> +{ > > I wonder if we should assert the fact we are in AArch32 here in case the > wrong access function gets added to a AArch64 register? We mostly don't do that kind of checking in these access functions. If you add the wrong access function to your regdef then your register misbehaves anyway :-) >> + if (arm_current_el(env) =3D=3D 3) { >> + return CP_ACCESS_OK; >> + } >> + if (arm_is_secure_below_el3(env)) { >> + return CP_ACCESS_TRAP_EL3; >> + } >> + /* This will be EL1 NS and EL2 NS, which just UNDEF */ >> + return CP_ACCESS_TRAP_UNCATEGORIZED; >> +} >> + >> static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64= _t value) >> { >> ARMCPU *cpu =3D arm_env_get_cpu(env); >> @@ -3532,6 +3549,13 @@ static const ARMCPRegInfo el3_cp_reginfo[] =3D { >> .cp =3D 15, .opc1 =3D 0, .crn =3D 1, .crm =3D 1, .opc2 =3D 0, >> .access =3D PL3_RW, .fieldoffset =3D offsetoflow32(CPUARMState, c= p15.scr_el3), >> .writefn =3D scr_write }, >> + { .name =3D "MDCR_EL3", .state =3D ARM_CP_STATE_AA64, >> + .opc0 =3D 3, .opc1 =3D 6, .crn =3D 1, .crm =3D 3, .opc2 =3D 1, >> + .access =3D PL3_RW, .fieldoffset =3D offsetof(CPUARMState, cp15.m= dcr_el3) }, >> + { .name =3D "SDCR", .type =3D ARM_CP_ALIAS, >> + .cp =3D 15, .opc1 =3D 0, .crn =3D 1, .crm =3D 3, .opc2 =3D 1, >> + .access =3D PL1_RW, .accessfn =3D access_trap_aa32s_el1, >> + .fieldoffset =3D offsetoflow32(CPUARMState, cp15.mdcr_el3) }, > > Does anything ensure the fields are reset to 0 on a warm reset? Yes, the cpreg framework resets things. arm_cpu_reset() calls cp_reg_reset() on every register the CPU knows about. Note that .resetvalue is 0 as usual for unspecified fields in structure initializers, but it would be clearer to specifically state it (ie ".resetvalue =3D 0") as we do in most cases. thanks -- PMM