From patchwork Thu Nov 16 14:24:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Abbott Liu X-Patchwork-Id: 10061317 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 40F78604D3 for ; Thu, 16 Nov 2017 14:29:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 32B9F2AA92 for ; Thu, 16 Nov 2017 14:29:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 26AFE2AA99; Thu, 16 Nov 2017 14:29:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5A4202AA92 for ; Thu, 16 Nov 2017 14:29:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Fdreh08eRIYJml3ljEoHNvQ8Ypr7PuZVb+9cfo9DM7U=; b=ugfEEBZLRptVqO trUbp2ngFcjdpzSL65xxFdOWK1tTabfL4kS0TTZEN2LoCBljwdICD0XY92XsxJDXi9QfzzqgkoMEJ mlSkaU3yqJDEOLWszovjzUkhhXla1/nWKMlLwIz2bwU19RskMUYtgPuUlTK/NtWk7KcBGIoDm+CkV DYaLC4jq/TVMknDQFENERFu1aE/+hJugo2VUqw2aizaNLJJDpaBURb36IZeOra/avzU87TQN2ktB3 zJ7HDQ3laXBl/upvPQ51n6ZgWM2HKqo0x1jMMB5zPoyW6ZiQR/bIKgqx4RKIwwkul08tuY+a4nRH1 DGQc8r5f6vsi839anM3Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eFLAK-0004mn-Dz; Thu, 16 Nov 2017 14:29:16 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1eFLAE-0004l6-Ib for linux-arm-kernel@lists.infradead.org; Thu, 16 Nov 2017 14:29:14 +0000 Received: from 172.30.72.56 (EHLO DGGEMM402-HUB.china.huawei.com) ([172.30.72.56]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AYV44319; Thu, 16 Nov 2017 22:24:42 +0800 (CST) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by DGGEMM402-HUB.china.huawei.com (10.3.20.210) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 22:24:40 +0800 Received: from DGGEMM510-MBS.china.huawei.com ([169.254.11.85]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 22:24:32 +0800 From: "Liuwenliang (Abbott Liu)" To: Marc Zyngier 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: AQHTXsDhZ5ece1W6v0+GfMCIss4ZwaMW+j4w Date: Thu, 16 Nov 2017 14:24:31 +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> <87po8ir1kg.fsf@on-the-bus.cambridge.arm.com> In-Reply-To: <87po8ir1kg.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] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A0D9FAD.0109, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171116_062911_545159_29377187 X-CRM114-Status: GOOD ( 14.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "tixy@linaro.org" , "mhocko@suse.com" , "grygorii.strashko@linaro.org" , "catalin.marinas@arm.com" , "linux-mm@kvack.org" , "glider@google.com" , "afzal.mohd.ma@gmail.com" , "mingo@kernel.org" , "cdall@linaro.org" , "f.fainelli@gmail.com" , "mawilcox@microsoft.com" , "linux@armlinux.org.uk" , "kasan-dev@googlegroups.com" , Dailei , "linux-arm-kernel@lists.infradead.org" , "aryabinin@virtuozzo.com" , "labbott@redhat.com" , "vladimir.murzin@arm.com" , "keescook@chromium.org" , "arnd@arndb.de" , Zengweilin , "opendmb@gmail.com" , Heshaoliang , "tglx@linutronix.de" , "dvyukov@google.com" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , Jiazhenghua , "akpm@linux-foundation.org" , "robin.murphy@arm.com" , "thgarnie@google.com" , "kirill.shutemov@linux.intel.com" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 16/11/17 17:54 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >On Thu, Nov 16 2017 at 3:07:54 am GMT, "Liuwenliang (Abbott Liu)" wrote: >>>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". >Trust me, from where I seat, I have a much better source than Google for >that document. Who would have thought? >Nothing in what you randomly quote invalids what I've been saying. And >to show you what's wrong with your reasoning, let me describe a >scenario, >I have a non-LPAE kernel that runs on my system. It uses the 32bit >version of the TTBRs. It turns out that this kernel runs under a >hypervisor (KVM, Xen, or your toy of the day). The hypervisor >context-switches vcpus without even looking at whether the configuration >of that guest. It doesn't have to care. It just blindly uses the 64bit >version of the TTBRs. >The architecture *guarantees* that it works (it even works with a 32bit >guest under a 64bit hypervisor). In your world, this doesn't work. I >guess the architecture wins. >> 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. >It is not about "supporting LPAE". It is about using the accessor that >makes sense in a particular context. Yes, the architecture allows you to >do something stupid. Don't do it. It doesn't mean the accessors cannot >be used, and I hope that my example above demonstrates it. >Conclusion: I still stand by my request that both versions of TTBRs/PAR >are described without depending on the kernel configuration, because >this has nothing to do with the kernel configuration. Thanks for your reviews. Yes, you are right. I have tested that "mcrr/mrrc" instruction (__ACCESS_CP15_64) can work on non LPAE on vexpress_a9. Here is the code I tested on vexpress_a9 and vexpress_a15: --- a/arch/arm/include/asm/cp15.h +++ b/arch/arm/include/asm/cp15.h @@ -64,6 +64,56 @@ #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v))) #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__) +#define TTBR0 __ACCESS_CP15_64(0, c2) +#define TTBR1 __ACCESS_CP15_64(1, c2) +#define PAR __ACCESS_CP15_64(0, c7) +#define VTTBR __ACCESS_CP15_64(6, c2) +#define CNTV_CVAL __ACCESS_CP15_64(3, c14) +#define CNTVOFF __ACCESS_CP15_64(4, c14) + +#define MIDR __ACCESS_CP15(c0, 0, c0, 0) +#define CSSELR __ACCESS_CP15(c0, 2, c0, 0) +#define VPIDR __ACCESS_CP15(c0, 4, c0, 0) +#define VMPIDR __ACCESS_CP15(c0, 4, c0, 5) +#define SCTLR __ACCESS_CP15(c1, 0, c0, 0) +#define CPACR __ACCESS_CP15(c1, 0, c0, 2) +#define HCR __ACCESS_CP15(c1, 4, c1, 0) +#define HDCR __ACCESS_CP15(c1, 4, c1, 1) +#define HCPTR __ACCESS_CP15(c1, 4, c1, 2) +#define HSTR __ACCESS_CP15(c1, 4, c1, 3) +#define TTBCR __ACCESS_CP15(c2, 0, c0, 2) +#define HTCR __ACCESS_CP15(c2, 4, c0, 2) +#define VTCR __ACCESS_CP15(c2, 4, c1, 2) +#define DACR __ACCESS_CP15(c3, 0, c0, 0) +#define DFSR __ACCESS_CP15(c5, 0, c0, 0) +#define IFSR __ACCESS_CP15(c5, 0, c0, 1) +#define ADFSR __ACCESS_CP15(c5, 0, c1, 0) +#define AIFSR __ACCESS_CP15(c5, 0, c1, 1) +#define HSR __ACCESS_CP15(c5, 4, c2, 0) +#define DFAR __ACCESS_CP15(c6, 0, c0, 0) +#define IFAR __ACCESS_CP15(c6, 0, c0, 2) +#define HDFAR __ACCESS_CP15(c6, 4, c0, 0) +#define HIFAR __ACCESS_CP15(c6, 4, c0, 2) +#define HPFAR __ACCESS_CP15(c6, 4, c0, 4) +#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0) +#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0) +#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0) +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0) +#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4) +#define PRRR __ACCESS_CP15(c10, 0, c2, 0) +#define NMRR __ACCESS_CP15(c10, 0, c2, 1) +#define AMAIR0 __ACCESS_CP15(c10, 0, c3, 0) +#define AMAIR1 __ACCESS_CP15(c10, 0, c3, 1) +#define VBAR __ACCESS_CP15(c12, 0, c0, 0) +#define CID __ACCESS_CP15(c13, 0, c0, 1) +#define TID_URW __ACCESS_CP15(c13, 0, c0, 2) +#define TID_URO __ACCESS_CP15(c13, 0, c0, 3) +#define TID_PRIV __ACCESS_CP15(c13, 0, c0, 4) +#define HTPIDR __ACCESS_CP15(c13, 4, c0, 2) +#define CNTKCTL __ACCESS_CP15(c14, 0, c1, 0) +#define CNTV_CTL __ACCESS_CP15(c14, 0, c3, 1) +#define CNTHCTL __ACCESS_CP15(c14, 4, c1, 0) + extern unsigned long cr_alignment; /* defined in entry-armv.S */ static inline unsigned long get_cr(void) diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h index 14b5903..8db8a8c 100644 --- a/arch/arm/include/asm/kvm_hyp.h +++ b/arch/arm/include/asm/kvm_hyp.h @@ -37,56 +37,6 @@ __val; \ }) -#define TTBR0 __ACCESS_CP15_64(0, c2) -#define TTBR1 __ACCESS_CP15_64(1, c2) -#define VTTBR __ACCESS_CP15_64(6, c2) -#define PAR __ACCESS_CP15_64(0, c7) -#define CNTV_CVAL __ACCESS_CP15_64(3, c14) -#define CNTVOFF __ACCESS_CP15_64(4, c14) - -#define MIDR __ACCESS_CP15(c0, 0, c0, 0) -#define CSSELR __ACCESS_CP15(c0, 2, c0, 0) -#define VPIDR __ACCESS_CP15(c0, 4, c0, 0) -#define VMPIDR __ACCESS_CP15(c0, 4, c0, 5) -#define SCTLR __ACCESS_CP15(c1, 0, c0, 0) -#define CPACR __ACCESS_CP15(c1, 0, c0, 2) -#define HCR __ACCESS_CP15(c1, 4, c1, 0) -#define HDCR __ACCESS_CP15(c1, 4, c1, 1) -#define HCPTR __ACCESS_CP15(c1, 4, c1, 2) -#define HSTR __ACCESS_CP15(c1, 4, c1, 3) -#define TTBCR __ACCESS_CP15(c2, 0, c0, 2) -#define HTCR __ACCESS_CP15(c2, 4, c0, 2) -#define VTCR __ACCESS_CP15(c2, 4, c1, 2) -#define DACR __ACCESS_CP15(c3, 0, c0, 0) -#define DFSR __ACCESS_CP15(c5, 0, c0, 0) -#define IFSR __ACCESS_CP15(c5, 0, c0, 1) -#define ADFSR __ACCESS_CP15(c5, 0, c1, 0) -#define AIFSR __ACCESS_CP15(c5, 0, c1, 1) -#define HSR __ACCESS_CP15(c5, 4, c2, 0) -#define DFAR __ACCESS_CP15(c6, 0, c0, 0) -#define IFAR __ACCESS_CP15(c6, 0, c0, 2) -#define HDFAR __ACCESS_CP15(c6, 4, c0, 0) -#define HIFAR __ACCESS_CP15(c6, 4, c0, 2) -#define HPFAR __ACCESS_CP15(c6, 4, c0, 4) -#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0) -#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0) -#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0) -#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0) -#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4) -#define PRRR __ACCESS_CP15(c10, 0, c2, 0) -#define NMRR __ACCESS_CP15(c10, 0, c2, 1) -#define AMAIR0 __ACCESS_CP15(c10, 0, c3, 0) -#define AMAIR1 __ACCESS_CP15(c10, 0, c3, 1) -#define VBAR __ACCESS_CP15(c12, 0, c0, 0) -#define CID __ACCESS_CP15(c13, 0, c0, 1) -#define TID_URW __ACCESS_CP15(c13, 0, c0, 2) -#define TID_URO __ACCESS_CP15(c13, 0, c0, 3) -#define TID_PRIV __ACCESS_CP15(c13, 0, c0, 4) -#define HTPIDR __ACCESS_CP15(c13, 4, c0, 2) -#define CNTKCTL __ACCESS_CP15(c14, 0, c1, 0) -#define CNTV_CTL __ACCESS_CP15(c14, 0, c3, 1) -#define CNTHCTL __ACCESS_CP15(c14, 4, c1, 0) -