From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] Initialize the mapping of KASan shadow memory
Date: Thu, 16 Nov 2017 14:40:40 +0000 [thread overview]
Message-ID: <87375eqobb.fsf@on-the-bus.cambridge.arm.com> (raw)
In-Reply-To: <B8AC3E80E903784988AB3003E3E97330C006371B@dggemm510-mbs.china.huawei.com> (liuwenliang@huawei.com's message of "Thu, 16 Nov 2017 14:24:31 +0000")
On Thu, Nov 16 2017 at 2:24:31 pm GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> On 16/11/17 17:54 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>On Thu, Nov 16 2017 at 3:07:54 am GMT, "Liuwenliang (Abbott Liu)"
>> <liuwenliang@huawei.com> wrote:
>>>>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
>>>>> On 09/11/17 18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)"
>>>>>> <liuwenliang@huawei.com> 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.
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.
What I have said is:
- If the CPU supports LPAE, then both 32 and 64bit accessors work
- If the CPU doesn't support LPAE, then only the 32bit accssor work
- In both cases, that's a function of the CPU, and not of the kernel
configuration.
- Both accessors can be safely defined as long as we ensure that they
are used in the right context.
> 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)
You still need to add the 32bit accessors.
M.
--
Jazz is not dead, it just smell funny.
next prev parent reply other threads:[~2017-11-16 14:40 UTC|newest]
Thread overview: 85+ 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
2018-02-26 13:09 ` 答复: " Liuwenliang (Abbott Liu)
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)
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 [this message]
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
2017-11-21 7:59 ` 答复: " Liuwenliang (Abbott Liu)
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-11-27 1:26 ` 答复: " Liuwenliang (Abbott Liu)
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-22 12:42 ` 答复: " Liuwenliang (Lamb)
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
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
[not found] ` <44c86924-930b-3eff-55b8-b02c9060ebe3@gmail.com>
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=87375eqobb.fsf@on-the-bus.cambridge.arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).