From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932669AbdKONTJ convert rfc822-to-8bit (ORCPT ); Wed, 15 Nov 2017 08:19:09 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:13355 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932306AbdKONTB (ORCPT ); Wed, 15 Nov 2017 08:19:01 -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 Date: Wed, 15 Nov 2017 13:16:36 +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: <87a7znsubp.fsf@on-the-bus.cambridge.arm.com> 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="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5A0C3E45.0230,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: 656b33ec11cc64de7e525d8b592277a7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >>>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote: >>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c >>>> index 049ee0a..359a782 100644 >>>> --- a/arch/arm/mm/kasan_init.c >>>> +++ b/arch/arm/mm/kasan_init.c >>>> @@ -15,6 +15,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>> >>>No, please don't do that. You shouldn't have to include KVM stuff in >>>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the >>>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this >>>is where new definition should be added. >> >> Thanks for your review. You are right. It is better to move >> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think >> it is a good idea to move registers definition which is used in >> virtualization to cp15.h, Because there is no virtualization stuff in >> cp15.h. > >It is not about virtualization at all. > >It is about what is a CP15 register and what is not. This file is called >"cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But >at the end of the day, that's for Russell to decide. Thanks for your review. You are right, all __ACCESS_CP15* are cp15 registers. I splited normal cp15 register (such as TTBR0/TTBR1/SCTLR and so on) and virtualizaton cp15 registers(such as VTTBR/ CNTV_CVAL/HCR) because I didn't think we need use those virtualization cp15 registers in non virtualization system. But now I think all __ACCESS_CP15* move to cp15.h may be a better choise. >> >> Here is the code which I tested on vexpress_a15 and vexpress_a9: >> 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: B4.1.155 TTBR0, Translation Table Base Register 0, VMSA ... The Multiprocessing Extensions change the TTBR0 32-bit register format. The Large Physical Address Extension extends TTBR0 to a 64-bit register. In an implementation that includes the Large Physical Address Extension, TTBCR.EAE determines which TTBR0 format is used: EAE==0 32-bit format is used. TTBR0[63:32] are ignored. EAE==1 64-bit format is used. B4.1.156 TTBR1, Translation Table Base Register 1, VMSA ... The Multiprocessing Extensions change the TTBR0 32-bit register format. The Large Physical Address Extension extends TTBR1 to a 64-bit register. In an implementation that includes the Large Physical Address Extension, TTBCR.EAE determines which TTBR1 format is used: EAE==0 32-bit format is used. TTBR1[63:32] are ignored. EAE==1 64-bit format is used. B4.1.154 TTBCR, Translation Table Base Control Register, VMSA ... EAE, bit[31], if implementation includes the Large Physical Address Extension Extended Address Enable. The meanings of the possible values of this bit are: 0 Use the 32-bit translation system, with the Short-descriptor translation table format. In this case, the format of the TTBCR is as described in this section. 1 Use the 40-bit translation system, with the Long-descriptor translation table format. In this case, the format of the TTBCR is as described in TTBCR format when using the Long-descriptor translation table format on page B4-1692. B4.1.112 PAR, Physical Address Register, VMSA If the implementation includes the Large Physical Address Extension, the PAR is extended to be a 64-bit register and: * The 64-bit PAR is used: - when using the Long-descriptor translation table format - in an implementation that includes the Virtualization Extensions, for the result of an ATS1Cxx operation performed from Hyp mode. * The 32-bit PAR is used when using the Short-descriptor translation table format. In this case, PAR[63:32] is UNK/SBZP. Otherwise, the PAR is a 32-bit register.