From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934141AbdKQHTj (ORCPT ); Fri, 17 Nov 2017 02:19:39 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:14229 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757103AbdKQHTW (ORCPT ); Fri, 17 Nov 2017 02:19:22 -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: AQHTXujfZ5ece1W6v0+GfMCIss4ZwaMXzeBA Date: Fri, 17 Nov 2017 07:18:45 +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> <87375eqobb.fsf@on-the-bus.cambridge.arm.com> In-Reply-To: <87375eqobb.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="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5A0E8D61.000C,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: f43fb9288a7b6ddd7754ee4d6db6d42d 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 vAH7JhPw021366 On 16/11/17 22:41 Marc Zyngier [mailto:marc.zyngier@arm.com] wrote: >No, it doesn't. It cannot work, because Cortex-A9 predates the invention >of the 64bit accessor. I suspect that you are testing stuff in QEMU, >which is giving you a SW model that always supports LPAE. I suggest you >test this code on *real* HW, and not only on QEMU. I am sorry. My test is fault. I only defined TTBR0 as __ACCESS_CP15_64, but I don't use the definition TTBR0 as __ACCESS_CP15_64. Now I use the definition TTBR0 as __ACCESS_CP15_64 on CPU supporting LPAE(vexpress_a9), I find it doesn't work and report undefined instruction error when execute "mrrc" instruction. So, you are right that 64bit accessor of TTBR0 cannot work on LPAE.