All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Julien Thierry <jthierry@redhat.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: Tue, 2 Feb 2021 11:15:12 +0000	[thread overview]
Message-ID: <20210202111512.GC59049@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20210120171745.1657762-4-jthierry@redhat.com>

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.

There's also a secondary encoding for DSB with FEAT_XS, which we don't
currently use but might want to add.

>  #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.

Thanks,
Mark.

>  enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
>  bool aarch64_insn_uses_literal(u32 insn);
>  bool aarch64_insn_is_branch(u32 insn);
> -- 
> 2.25.4
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Julien Thierry <jthierry@redhat.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: Tue, 2 Feb 2021 11:15:12 +0000	[thread overview]
Message-ID: <20210202111512.GC59049@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20210120171745.1657762-4-jthierry@redhat.com>

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.

There's also a secondary encoding for DSB with FEAT_XS, which we don't
currently use but might want to add.

>  #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.

Thanks,
Mark.

>  enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
>  bool aarch64_insn_uses_literal(u32 insn);
>  bool aarch64_insn_is_branch(u32 insn);
> -- 
> 2.25.4
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-02-02 11:16 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 [this message]
2021-02-02 11:15     ` Mark Rutland
2021-02-03  8:47     ` Julien Thierry
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=20210202111512.GC59049@C02TD0UTHF1T.local \
    --to=mark.rutland@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jthierry@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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: link
Be 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.