From: "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"aryabinin@virtuozzo.com" <aryabinin@virtuozzo.com>,
"afzal.mohd.ma@gmail.com" <afzal.mohd.ma@gmail.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"labbott@redhat.com" <labbott@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"cdall@linaro.org" <cdall@linaro.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mawilcox@microsoft.com" <mawilcox@microsoft.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"thgarnie@google.com" <thgarnie@google.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"vladimir.murzin@arm.com" <vladimir.murzin@arm.com>,
"tixy@linaro.org" <tixy@linaro.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"grygorii.strashko@linaro.org" <grygorii.strashko@linaro.org>,
"glider@google.com" <glider@google.com>,
"dvyukov@google.com" <dvyukov@google.com>,
"opendmb@gmail.com" <opendmb@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Jiazhenghua <jiazhenghua@huawei.com>,
Dailei <dylix.dailei@huawei.com>,
Zengweilin <zengweilin@huawei.com>,
Heshaoliang <heshaoliang@huawei.com>
Subject: Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory
Date: Wed, 15 Nov 2017 13:16:36 +0000 [thread overview]
Message-ID: <B8AC3E80E903784988AB3003E3E97330C0063587@dggemm510-mbs.china.huawei.com> (raw)
In-Reply-To: <87a7znsubp.fsf@on-the-bus.cambridge.arm.com>
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)" <liuwenliang@huawei.com> 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 <asm/proc-fns.h>
>>>> #include <asm/tlbflush.h>
>>>> #include <asm/cp15.h>
>>>> +#include <asm/kvm_hyp.h>
>>>
>>>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.
next prev parent reply other threads:[~2017-11-15 13:19 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 8:22 [PATCH 00/11] KASan for arm Abbott Liu
2017-10-11 8:22 ` [PATCH 01/11] Initialize the mapping of KASan shadow memory Abbott Liu
2017-10-11 19:39 ` Florian Fainelli
2017-10-11 21:41 ` Russell King - ARM Linux
2017-10-17 13:28 ` Liuwenliang (Lamb)
2017-10-11 23:42 ` Dmitry Osipenko
2017-10-19 6:52 ` Liuwenliang (Lamb)
2017-10-19 12:01 ` Russell King - ARM Linux
2017-10-12 7:58 ` Marc Zyngier
2017-11-09 7:46 ` Liuwenliang (Abbott Liu)
2017-11-09 10:10 ` Marc Zyngier
2017-11-15 10:20 ` Liuwenliang (Abbott Liu)
2017-11-15 10:35 ` Marc Zyngier
2017-11-15 13:16 ` Liuwenliang (Abbott Liu) [this message]
2017-11-15 13:54 ` Marc Zyngier
2017-11-16 3:07 ` Liuwenliang (Abbott Liu)
2017-11-16 9:54 ` Marc Zyngier
2017-11-16 14:24 ` Liuwenliang (Abbott Liu)
2017-11-16 14:40 ` Marc Zyngier
2017-11-17 1:39 ` 答复: " Liuwenliang (Abbott Liu)
2017-11-17 7:18 ` Liuwenliang (Abbott Liu)
2017-11-17 7:35 ` Christoffer Dall
2017-11-18 10:40 ` Liuwenliang (Abbott Liu)
2017-11-18 13:48 ` Marc Zyngier
[not found] ` <B8AC3E80E903784988AB3003E3E97330C0068F12@dggemm510-mbx.china.huawei.com>
2017-11-21 9:40 ` 答复: " Russell King - ARM Linux
2017-11-21 9:46 ` Marc Zyngier
2017-11-21 12:29 ` Mark Rutland
2017-11-22 12:56 ` Liuwenliang (Abbott Liu)
2017-11-22 13:06 ` Marc Zyngier
2017-11-23 1:54 ` Liuwenliang (Abbott Liu)
2017-11-23 15:22 ` Russell King - ARM Linux
2017-11-27 1:23 ` Liuwenliang (Abbott Liu)
2017-11-23 15:31 ` Mark Rutland
2017-10-19 11:09 ` Russell King - ARM Linux
2018-02-24 14:28 ` Liuwenliang (Abbott Liu)
2017-10-11 8:22 ` [PATCH 02/11] replace memory function Abbott Liu
2017-10-19 12:05 ` Russell King - ARM Linux
2017-10-11 8:22 ` [PATCH 03/11] arm: Kconfig: enable KASan Abbott Liu
2017-10-11 19:15 ` Florian Fainelli
2017-10-19 12:34 ` Russell King - ARM Linux
2017-10-22 12:27 ` Liuwenliang (Lamb)
2017-10-11 8:22 ` [PATCH 04/11] Define the virtual space of KASan's shadow region Abbott Liu
2017-10-14 11:41 ` kbuild test robot
2017-10-16 11:42 ` Liuwenliang (Lamb)
2017-10-16 12:14 ` Ard Biesheuvel
2017-10-17 11:27 ` Liuwenliang (Lamb)
2017-10-17 11:52 ` Ard Biesheuvel
2017-10-17 13:02 ` Liuwenliang (Lamb)
2017-10-19 12:43 ` Russell King - ARM Linux
2017-10-22 12:12 ` Liuwenliang (Lamb)
2017-10-19 12:41 ` Russell King - ARM Linux
2017-10-19 12:40 ` Russell King - ARM Linux
2017-10-11 8:22 ` [PATCH 05/11] Disable kasan's instrumentation Abbott Liu
2017-10-11 19:16 ` Florian Fainelli
2017-10-19 12:47 ` Russell King - ARM Linux
2017-11-15 10:19 ` Liuwenliang (Abbott Liu)
2017-10-11 8:22 ` [PATCH 06/11] change memory_is_poisoned_16 for aligned error Abbott Liu
2017-10-11 23:23 ` Andrew Morton
2017-10-12 7:16 ` Dmitry Vyukov
2017-10-12 11:27 ` Liuwenliang (Lamb)
2017-10-19 12:51 ` Russell King - ARM Linux
2017-12-05 14:19 ` Liuwenliang (Abbott Liu)
2017-12-05 17:08 ` Ard Biesheuvel
2018-01-16 8:39 ` Liuwenliang (Abbott Liu)
2017-10-11 8:22 ` [PATCH 07/11] Avoid cleaning the KASan shadow area's mapping table Abbott Liu
2017-10-11 8:22 ` [PATCH 08/11] Add support arm LPAE Abbott Liu
2017-10-11 8:22 ` [PATCH 09/11] Don't need to map the shadow of KASan's shadow memory Abbott Liu
2017-10-19 12:55 ` Russell King - ARM Linux
2017-10-22 12:31 ` Liuwenliang (Lamb)
2017-10-11 8:22 ` [PATCH 10/11] Change mapping of kasan_zero_page int readonly Abbott Liu
2017-10-11 19:19 ` Florian Fainelli
2017-10-11 8:22 ` [PATCH 11/11] Add KASan layout Abbott Liu
2017-10-11 19:13 ` [PATCH 00/11] KASan for arm Florian Fainelli
2017-10-11 19:50 ` Florian Fainelli
2017-10-11 21:36 ` Florian Fainelli
2017-10-11 22:10 ` Laura Abbott
2017-10-11 22:58 ` Russell King - ARM Linux
2017-10-17 12:41 ` Liuwenliang (Lamb)
2017-10-12 4:55 ` Liuwenliang (Lamb)
2017-10-12 7:38 ` Arnd Bergmann
2017-10-17 1:04 ` 答复: " Liuwenliang (Lamb)
2018-02-13 18:40 ` Florian Fainelli
2018-02-23 2:10 ` Liuwenliang (Abbott Liu)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B8AC3E80E903784988AB3003E3E97330C0063587@dggemm510-mbs.china.huawei.com \
--to=liuwenliang@huawei.com \
--cc=afzal.mohd.ma@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=catalin.marinas@arm.com \
--cc=cdall@linaro.org \
--cc=dvyukov@google.com \
--cc=dylix.dailei@huawei.com \
--cc=f.fainelli@gmail.com \
--cc=glider@google.com \
--cc=grygorii.strashko@linaro.org \
--cc=heshaoliang@huawei.com \
--cc=jiazhenghua@huawei.com \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mawilcox@microsoft.com \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=opendmb@gmail.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=tixy@linaro.org \
--cc=vladimir.murzin@arm.com \
--cc=zengweilin@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).