From: "Clément Léger" <cleger@rivosinc.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: panqinglin2020@iscas.ac.cn, Guo Ren <guoren@linux.alibaba.com>,
keescook@chromium.org, wefu@redhat.com, peterz@infradead.org,
unicorn_wang@outlook.com, atishp@atishpatra.org,
chao.wei@sophgo.com, linux-kernel@vger.kernel.org,
bjorn@rivosinc.com, xiaoguang.xing@sophgo.com,
conor.dooley@microchip.com, leobras@redhat.com,
palmer@dabbelt.com, jszhang@kernel.org, paul.walmsley@sifive.com,
guoren@kernel.org, linux-riscv@lists.infradead.org,
wuwei2016@iscas.ac.cn
Subject: Re: [PATCH V2 1/3] riscv: Add Zicbop instruction definitions & cpufeature
Date: Thu, 11 Jan 2024 11:49:48 +0100 [thread overview]
Message-ID: <78afc7ce-c6ce-4edd-b91a-1f8a94ce298a@rivosinc.com> (raw)
In-Reply-To: <20240111-416377ebfcaff924b71fb419@orel>
On 11/01/2024 11:45, Andrew Jones wrote:
> On Thu, Jan 11, 2024 at 11:31:32AM +0100, Clément Léger wrote:
>>
>>
>> On 03/01/2024 13:00, Andrew Jones wrote:
>>> On Wed, Jan 03, 2024 at 10:31:37AM +0100, Clément Léger wrote:
>>>>
>>>>
>>>> On 31/12/2023 09:29, guoren@kernel.org wrote:
>>>>> From: Guo Ren <guoren@linux.alibaba.com>
>>>>>
>>>>> Cache-block prefetch instructions are HINTs to the hardware to
>>>>> indicate that software intends to perform a particular type of
>>>>> memory access in the near future. This patch adds prefetch.i,
>>>>> prefetch.r and prefetch.w instruction definitions by
>>>>> RISCV_ISA_EXT_ZICBOP cpufeature.
>>>>>
>>>>> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>> ---
>>>>> arch/riscv/Kconfig | 15 ++++++++
>>>>> arch/riscv/include/asm/hwcap.h | 1 +
>>>>> arch/riscv/include/asm/insn-def.h | 60 +++++++++++++++++++++++++++++++
>>>>> arch/riscv/kernel/cpufeature.c | 1 +
>>>>> 4 files changed, 77 insertions(+)
>>>>>
>>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>>>> index 24c1799e2ec4..fcbd417d65ea 100644
>>>>> --- a/arch/riscv/Kconfig
>>>>> +++ b/arch/riscv/Kconfig
>>>>> @@ -579,6 +579,21 @@ config RISCV_ISA_ZICBOZ
>>>>>
>>>>> If you don't know what to do here, say Y.
>>>>>
>>>>> +config RISCV_ISA_ZICBOP
>>>>> + bool "Zicbop extension support for cache block prefetch"
>>>>> + depends on MMU
>>>>> + depends on RISCV_ALTERNATIVE
>>>>> + default y
>>>>> + help
>>>>> + Adds support to dynamically detect the presence of the ZICBOP
>>>>> + extension (Cache Block Prefetch Operations) and enable its
>>>>> + usage.
>>>>> +
>>>>> + The Zicbop extension can be used to prefetch cache block for
>>>>> + read/write fetch.
>>>>> +
>>>>> + If you don't know what to do here, say Y.
>>>>> +
>>>>> config TOOLCHAIN_HAS_ZIHINTPAUSE
>>>>> bool
>>>>> default y
>>>>> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
>>>>> index 06d30526ef3b..77d3b6ee25ab 100644
>>>>> --- a/arch/riscv/include/asm/hwcap.h
>>>>> +++ b/arch/riscv/include/asm/hwcap.h
>>>>> @@ -57,6 +57,7 @@
>>>>> #define RISCV_ISA_EXT_ZIHPM 42
>>>>> #define RISCV_ISA_EXT_SMSTATEEN 43
>>>>> #define RISCV_ISA_EXT_ZICOND 44
>>>>> +#define RISCV_ISA_EXT_ZICBOP 45
>>>>
>>>> Hi Guo,
>>>>
>>>> Since you are adding support for the Zicbop extension, you could
>>>> probably also allow to probe it from userspace using hwprobe. Add a few
>>>> definitions to sys_riscv.c/hwprobe.h and it will be fine.
>>>
>>> To expose to userspace, we should also start parsing the block size,
>>> so it can also be exposed to userspace. Starting to parse the block
>>> size first requires that we decide we need to parse the block size
>>> (see [1]).
>>
>> Hi Andrew, thanks for the thread.
>>
>> I read it (and the other ones that are related to it) and basically, it
>> seems there was a first decision (expose Zicbop block size indivudally)
>> due to the fact the specification did not mentioned anything specific
>> about clock sizes but then after that, there was a clarification in the
>> spec stating that Zicbop and Zicbom have the same block size so the
>> first decision was questioned again.
>>
>> From a user coherency point of view, I think it would make more sense to
>> expose it individually in hwprobe so that zicboz, zicbop and zicbom
>> have their "own" block size (even though zicbop and zicbom would use the
>> same one). Moreover, it would allow us for future evolution easily
>> without breaking any userspace later if zicbop and zicbom block size are
>> decoupled.
>
> I agree and QEMU has already headed down the road of generating
> riscv,cbop-block-size (I guess Conor's ack on [1] was interpreted as
> being sufficient to merge the QEMU bits), so we can add the Linux
> support and test with QEMU now. The work could probably be a separate
> series to this one, though.
Yes, it QEMU had it merged. and agreed, since this requires a bit more
plumbing, it can probably be left out of this series. I could probably
take care of that later.
Thanks,
Clément
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-01-11 10:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 8:29 [PATCH V2 0/3] riscv: Add Zicbop & prefetchw support guoren
2023-12-31 8:29 ` [PATCH V2 1/3] riscv: Add Zicbop instruction definitions & cpufeature guoren
2024-01-02 10:32 ` Andrew Jones
2024-01-03 6:13 ` Guo Ren
2024-01-03 6:49 ` Andrew Jones
2024-01-03 19:44 ` Andrew Jones
2024-01-03 19:06 ` Leonardo Bras
2024-01-03 9:31 ` Clément Léger
2024-01-03 12:00 ` Andrew Jones
2024-01-11 10:31 ` Clément Léger
2024-01-11 10:45 ` Andrew Jones
2024-01-11 10:49 ` Clément Léger [this message]
2024-01-11 11:12 ` Conor Dooley
2024-01-03 18:52 ` Leonardo Bras
2024-01-03 19:29 ` Andrew Jones
2024-01-03 20:33 ` Leonardo Bras
2024-01-04 9:47 ` Andrew Jones
2024-01-04 15:03 ` Leonardo Bras
2024-01-04 16:40 ` Andrew Jones
2024-01-04 17:43 ` Leonardo Bras
2024-01-05 13:24 ` Andrew Jones
2024-01-08 14:34 ` Leonardo Bras
2024-01-08 15:24 ` Andrew Jones
2024-01-08 16:14 ` Leonardo Bras
2024-01-03 19:48 ` Andrew Jones
2024-01-03 20:34 ` Leonardo Bras
2023-12-31 8:29 ` [PATCH V2 2/3] riscv: Add ARCH_HAS_PRETCHW support with Zibop guoren
2024-01-01 2:29 ` Guo Ren
2024-01-03 19:04 ` Leonardo Bras
2024-01-02 10:45 ` Andrew Jones
2024-01-03 6:19 ` Guo Ren
2024-01-03 19:56 ` Andrew Jones
2024-01-05 13:31 ` Andrew Jones
2023-12-31 8:29 ` [PATCH V2 3/3] riscv: xchg: Prefetch the destination word for sc.w guoren
2024-01-02 11:18 ` Andrew Jones
2024-01-03 6:15 ` Guo Ren
2024-01-03 19:45 ` Leonardo Bras
2024-01-04 1:24 ` Guo Ren
2024-01-04 3:56 ` Leonardo Bras
2024-01-04 8:14 ` Guo Ren
2024-01-04 14:17 ` Leonardo Bras
2024-01-05 1:13 ` Guo Ren
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=78afc7ce-c6ce-4edd-b91a-1f8a94ce298a@rivosinc.com \
--to=cleger@rivosinc.com \
--cc=ajones@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=bjorn@rivosinc.com \
--cc=chao.wei@sophgo.com \
--cc=conor.dooley@microchip.com \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=jszhang@kernel.org \
--cc=keescook@chromium.org \
--cc=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=panqinglin2020@iscas.ac.cn \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=unicorn_wang@outlook.com \
--cc=wefu@redhat.com \
--cc=wuwei2016@iscas.ac.cn \
--cc=xiaoguang.xing@sophgo.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).