From: Julien Thierry <jthierry@redhat.com> To: Mark Rutland <mark.rutland@arm.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org Subject: Re: [RFC PATCH 3/5] arm64: aarch64-insn: Add barrier encodings Date: Wed, 3 Feb 2021 09:47:14 +0100 [thread overview] Message-ID: <a2466e6b-5b9b-6db6-496e-f8353e097d7e@redhat.com> (raw) In-Reply-To: <20210202111512.GC59049@C02TD0UTHF1T.local> On 2/2/21 12:15 PM, Mark Rutland wrote: > On Wed, Jan 20, 2021 at 06:17:43PM +0100, Julien Thierry wrote: >> Create necessary functions to encode/decode aarch64 data/instruction >> barriers. >> >> Signed-off-by: Julien Thierry <jthierry@redhat.com> >> --- >> arch/arm64/include/asm/aarch64-insn.h | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/arch/arm64/include/asm/aarch64-insn.h b/arch/arm64/include/asm/aarch64-insn.h >> index 200bee726172..d0fee47bbe6e 100644 >> --- a/arch/arm64/include/asm/aarch64-insn.h >> +++ b/arch/arm64/include/asm/aarch64-insn.h >> @@ -379,6 +379,9 @@ __AARCH64_INSN_FUNCS(eret_auth, 0xFFFFFBFF, 0xD69F0BFF) >> __AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000) >> __AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F) >> __AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000) >> +__AARCH64_INSN_FUNCS(dmb, 0xFFFFF0FF, 0xD50330BF) >> +__AARCH64_INSN_FUNCS(dsb, 0xFFFFF0FF, 0xD503309F) >> +__AARCH64_INSN_FUNCS(isb, 0xFFFFF0FF, 0xD50330DF) > > These match the encodings in ARM DDI 0487G.a, with a couple of caveats > for DSB. > > Per section C6.2.82 on page C6-1000, when CRm != 0x00, the instruction > isn't considered a DSB. I believe per the "barriers" decode table on > page C4-289 that here "0x00" is actually a binary string and 'x' is a > "don't care" -- I've raised a ticket to get the documentation clarified. > I suspect we need to write a function to handle that. > Ah, I did miss that part. Thanks for pointing it out (and for clarifying it's probably not hexa, but the binary string makes sense since it's a 4 bits field) > There's also a secondary encoding for DSB with FEAT_XS, which we don't > currently use but might want to add. > Ah, yes, had to pick up a newer version of the Arm ARM! I'll add it. >> #undef __AARCH64_INSN_FUNCS >> >> @@ -390,6 +393,12 @@ static inline bool aarch64_insn_is_adr_adrp(u32 insn) >> return aarch64_insn_is_adr(insn) || aarch64_insn_is_adrp(insn); >> } >> >> +static inline bool aarch64_insn_is_barrier(u32 insn) >> +{ >> + return aarch64_insn_is_dmb(insn) || aarch64_insn_is_dsb(insn) || >> + aarch64_insn_is_isb(insn); >> +} > > I assume this is meant to match the barriers instruction class, as per > the table on page C4-289? That also contains CLREX, SB, SSBB, and PSSBB, > and it might be worth adding them at the same time. > Yes, I have to admit I only added the ones that objtool saw and complained about "unreachable instruction" (mostly barriers after ret/eret). I'll add them as well. Thanks, -- Julien Thierry
WARNING: multiple messages have this Message-ID (diff)
From: Julien Thierry <jthierry@redhat.com> To: Mark Rutland <mark.rutland@arm.com> Cc: catalin.marinas@arm.com, broonie@kernel.org, will@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 3/5] arm64: aarch64-insn: Add barrier encodings Date: Wed, 3 Feb 2021 09:47:14 +0100 [thread overview] Message-ID: <a2466e6b-5b9b-6db6-496e-f8353e097d7e@redhat.com> (raw) In-Reply-To: <20210202111512.GC59049@C02TD0UTHF1T.local> On 2/2/21 12:15 PM, Mark Rutland wrote: > On Wed, Jan 20, 2021 at 06:17:43PM +0100, Julien Thierry wrote: >> Create necessary functions to encode/decode aarch64 data/instruction >> barriers. >> >> Signed-off-by: Julien Thierry <jthierry@redhat.com> >> --- >> arch/arm64/include/asm/aarch64-insn.h | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/arch/arm64/include/asm/aarch64-insn.h b/arch/arm64/include/asm/aarch64-insn.h >> index 200bee726172..d0fee47bbe6e 100644 >> --- a/arch/arm64/include/asm/aarch64-insn.h >> +++ b/arch/arm64/include/asm/aarch64-insn.h >> @@ -379,6 +379,9 @@ __AARCH64_INSN_FUNCS(eret_auth, 0xFFFFFBFF, 0xD69F0BFF) >> __AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000) >> __AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F) >> __AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000) >> +__AARCH64_INSN_FUNCS(dmb, 0xFFFFF0FF, 0xD50330BF) >> +__AARCH64_INSN_FUNCS(dsb, 0xFFFFF0FF, 0xD503309F) >> +__AARCH64_INSN_FUNCS(isb, 0xFFFFF0FF, 0xD50330DF) > > These match the encodings in ARM DDI 0487G.a, with a couple of caveats > for DSB. > > Per section C6.2.82 on page C6-1000, when CRm != 0x00, the instruction > isn't considered a DSB. I believe per the "barriers" decode table on > page C4-289 that here "0x00" is actually a binary string and 'x' is a > "don't care" -- I've raised a ticket to get the documentation clarified. > I suspect we need to write a function to handle that. > Ah, I did miss that part. Thanks for pointing it out (and for clarifying it's probably not hexa, but the binary string makes sense since it's a 4 bits field) > There's also a secondary encoding for DSB with FEAT_XS, which we don't > currently use but might want to add. > Ah, yes, had to pick up a newer version of the Arm ARM! I'll add it. >> #undef __AARCH64_INSN_FUNCS >> >> @@ -390,6 +393,12 @@ static inline bool aarch64_insn_is_adr_adrp(u32 insn) >> return aarch64_insn_is_adr(insn) || aarch64_insn_is_adrp(insn); >> } >> >> +static inline bool aarch64_insn_is_barrier(u32 insn) >> +{ >> + return aarch64_insn_is_dmb(insn) || aarch64_insn_is_dsb(insn) || >> + aarch64_insn_is_isb(insn); >> +} > > I assume this is meant to match the barriers instruction class, as per > the table on page C4-289? That also contains CLREX, SB, SSBB, and PSSBB, > and it might be worth adding them at the same time. > Yes, I have to admit I only added the ones that objtool saw and complained about "unreachable instruction" (mostly barriers after ret/eret). I'll add them as well. Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-03 8:48 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-20 17:17 [RFC PATCH 0/5] arm64: Prepare instruction decoder for objtool Julien Thierry 2021-01-20 17:17 ` Julien Thierry 2021-01-20 17:17 ` [RFC PATCH 1/5] arm64: Move instruction encoder/decoder under lib/ Julien Thierry 2021-02-02 10:17 ` Mark Rutland 2021-02-03 8:26 ` Julien Thierry 2021-02-03 8:26 ` Julien Thierry 2021-02-03 11:12 ` Mark Rutland 2021-02-03 11:12 ` Mark Rutland 2021-02-03 17:30 ` Julien Thierry 2021-02-03 17:30 ` Julien Thierry 2021-01-20 17:17 ` [RFC PATCH 2/5] arm64: aarch64-insn: Add SVE instruction class Julien Thierry 2021-01-20 17:17 ` Julien Thierry 2021-01-20 17:17 ` [RFC PATCH 3/5] arm64: aarch64-insn: Add barrier encodings Julien Thierry 2021-01-20 17:17 ` Julien Thierry 2021-02-02 11:15 ` Mark Rutland 2021-02-02 11:15 ` Mark Rutland 2021-02-03 8:47 ` Julien Thierry [this message] 2021-02-03 8:47 ` Julien Thierry 2021-01-20 17:17 ` [RFC PATCH 4/5] arm64: aarch64-insn: Add some opcodes to instruction decoder Julien Thierry 2021-01-20 17:17 ` Julien Thierry 2021-01-20 17:17 ` [RFC PATCH 5/5] arm64: Add load/store decoding helpers Julien Thierry 2021-01-20 17:17 ` Julien Thierry
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=a2466e6b-5b9b-6db6-496e-f8353e097d7e@redhat.com \ --to=jthierry@redhat.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=will@kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.