From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758975AbdKPDIq (ORCPT ); Wed, 15 Nov 2017 22:08:46 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:14772 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758946AbdKPDIk (ORCPT ); Wed, 15 Nov 2017 22:08:40 -0500 From: "Liuwenliang (Abbott Liu)" To: Marc Zyngier CC: "linux@armlinux.org.uk" , "aryabinin@virtuozzo.com" , "afzal.mohd.ma@gmail.com" , "f.fainelli@gmail.com" , "labbott@redhat.com" , "kirill.shutemov@linux.intel.com" , "mhocko@suse.com" , "cdall@linaro.org" , "catalin.marinas@arm.com" , "akpm@linux-foundation.org" , "mawilcox@microsoft.com" , "tglx@linutronix.de" , "thgarnie@google.com" , "keescook@chromium.org" , "arnd@arndb.de" , "vladimir.murzin@arm.com" , "tixy@linaro.org" , "ard.biesheuvel@linaro.org" , "robin.murphy@arm.com" , "mingo@kernel.org" , "grygorii.strashko@linaro.org" , "glider@google.com" , "dvyukov@google.com" , "opendmb@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "kasan-dev@googlegroups.com" , "linux-mm@kvack.org" , Jiazhenghua , Dailei , Zengweilin , Heshaoliang Subject: Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory Thread-Topic: [PATCH 01/11] Initialize the mapping of KASan shadow memory Thread-Index: AQHTXf16Z5ece1W6v0+GfMCIss4ZwaMVU5Gg//+c1oCAAVb7QA== Date: Thu, 16 Nov 2017 03:07:54 +0000 Message-ID: References: <20171011082227.20546-1-liuwenliang@huawei.com> <20171011082227.20546-2-liuwenliang@huawei.com> <227e2c6e-f479-849d-8942-1d5ff4ccd440@arm.com> <8e959f69-a578-793b-6c32-18b5b0cd08c2@arm.com> <87a7znsubp.fsf@on-the-bus.cambridge.arm.com> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.90.243] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5A0D0119.00F0,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=169.254.11.85, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 902178c3f21c86561dbedc3fb2c69c2e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vAG38rrb010864 >On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote: >> On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" wrote: >>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h >>>> index dbdbce1..6db1f51 100644 >>>> --- a/arch/arm/include/asm/cp15.h >>>> +++ b/arch/arm/include/asm/cp15.h >>>> @@ -64,6 +64,43 @@ >>>> #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) >>>> #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) >>>> >>>> +#ifdef CONFIG_ARM_LPAE >>>> +#define TTBR0 __ACCESS_CP15_64(0, c2) >>>> +#define TTBR1 __ACCESS_CP15_64(1, c2) >>>> +#define PAR __ACCESS_CP15_64(0, c7) >>>> +#else >>>> +#define TTBR0 __ACCESS_CP15(c2, 0, c0, 0) >>>> +#define TTBR1 __ACCESS_CP15(c2, 0, c0, 1) >>>> +#define PAR __ACCESS_CP15(c7, 0, c4, 0) >>>> +#endif >>> Again: there is no point in not having these register encodings >>> cohabiting. They are both perfectly defined in the architecture. Just >>> suffix one (or even both) with their respective size, making it obvious >>> which one you're talking about. >> >> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way >> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE. >> The following description is the reason: >> Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf: >[...] > >You're missing the point. TTBR0 existence as a 64bit CP15 register has >nothing to do the kernel being compiled with LPAE or not. It has >everything to do with the HW supporting LPAE, and it is the kernel's job >to use the right accessor depending on how it is compiled. On a CPU >supporting LPAE, both TTBR0 accessors are valid. It is the kernel that >chooses to use one rather than the other. Thanks for your review. I don't think both TTBR0 accessors(64bit accessor and 32bit accessor) are valid on a CPU supporting LPAE which the LPAE is enabled. Here is the description come form DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition) which you can get the document by google "ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition". 64-bit TTBR0 and TTBR1 format The bit assignments for the 64-bit implementations of TTBR0 and TTBR1 are identical, and are: Bits[63:56] UNK/SBZP. ASID, bits[55:48]: An ASID for the translation table base address. The TTBCR.A1 field selects either TTBR0.ASID or TTBR1.ASID. Bits[47:40] UNK/SBZP. BADDR, bits[39:x]: Translation table base address, bits[39:x]. Defining the translation table base address width on page B4-1698 describes how x is defined. The value of x determines the required alignment of the translation table, which must be aligned to 2x bytes. Bits[x-1:0] UNK/SBZP. ... To access a 64-bit TTBR0, software performs a 64-bit read or write of the CP15 registers with set to c2 and set to 0. For example: MRRC p15,0,,, c2 ; Read 64-bit TTBR0 into Rt (low word) and Rt2 (high word) MCRR p15,0,,, c2 ; Write Rt (low word) and Rt2 (high word) to 64-bit TTBR0 So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is 32bit version (__ACCESS_CP15), even if the CPU doesn't report error, you also lose the high or low 32bit of the TTBR0/TTBR1. >Also, if I follow your reasoning, why are you bothering defining PAR in >the non-LPAE case? It is not used by anything, as far as I can see... I don't use the PAR, I change the defining PAR just because I think it will be wrong in a non LPAE CPU.