From: Deepak Gupta <debug@rivosinc.com> To: Andrew Jones <ajones@ventanamicro.com> Cc: Samuel Holland <samuel.holland@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, linux-kernel@vger.kernel.org, tech-j-ext@lists.risc-v.org, Conor Dooley <conor@kernel.org>, kasan-dev@googlegroups.com, Evgenii Stepanov <eugenis@google.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, Guo Ren <guoren@kernel.org>, Heiko Stuebner <heiko@sntech.de>, Paul Walmsley <paul.walmsley@sifive.com> Subject: Re: [RISC-V] [tech-j-ext] [RFC PATCH 5/9] riscv: Split per-CPU and per-thread envcfg bits Date: Fri, 22 Mar 2024 09:52:48 -0700 [thread overview] Message-ID: <CAKC1njTGSMPekhvyRW0gz6+mY2S_==voCcspoLAyp38X-BcWcw@mail.gmail.com> (raw) In-Reply-To: <20240322-3c32873c4021477383a15f7d@orel> On Fri, Mar 22, 2024 at 1:09 AM Andrew Jones <ajones@ventanamicro.com> wrote: > > On Tue, Mar 19, 2024 at 09:39:52PM -0700, Deepak Gupta wrote: > ... > > I am not sure of the practicality of this heterogeneity for Zicboz and > > for that matter any of the upcoming > > features that'll be enabled via senvcfg (control flow integrity, > > pointer masking, etc). > > > > As an example if cache zeroing instructions are used by app binary, I > > expect it to be used in following > > manner > > > > - Explicitly inserting cbo.zero by application developer > > - Some compiler flag which ensures that structures larger than cache > > line gets zeroed by cbo.zero > > > > In either of the cases, the developer is not expecting to target it to > > a specific hart on SoC and instead expect it to work. > > There might be libraries (installed via sudo apt get) with cache zero > > support in them which may run in different address spaces. > > Should the library be aware of the CPU on which it's running. Now > > whoever is running these binaries should be aware which CPUs > > they get assigned to in order to avoid faults? > > > > That seems excessive, doesn't it? > > > > It might be safe to assume extensions like Zicboz will be on all harts if > any, but I wouldn't expect all extensions in the future to be present on > all available harts. For example, some Arm big.LITTLE boards only have > virt extensions on big CPUs. When a VMM wants to launch a guest it must > be aware of which CPUs it will use for the VCPU threads. For riscv, we > have the which-cpus variant of the hwprobe syscall to try and make this > type of thing easier to manage, but I agree it will still be a pain for > software since it will need to make that query and then set its affinity, > which is something it hasn't needed to do before. > Sure, the future may be a world where heterogeneous ISA is a thing. But that's not the present. Let's not try to build for something which doesn't exist. It has been (heterogeneous ISA) tried earlier many times and mostly have fallen flat (remember on Intel alder lake, Intel had to ship a ucode patch to disable AVX512 exactly for same reason) https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/2 As and when ISA features get enabled, they get compiled into libraries/binaries and end user many times use things like `taskset` to set affinity without even realizing there is some weirdness going on under the hood. For majority of use cases -- heterogeneous ISA doesn't make sense. Sure if someone is willing to build a custom SoC with heterogeneous ISA for their strict usecase, they control their software and hardware and thus they can do that. But littering linux kernel to support wierd usecases and putting a burden of that on majority of usecases and software is not wise. If something like this has to be done, I expect first that it doesn't force end users to learn about ISA differences between harts on their system and then figure out which installed packages have which ISA features compiled in. This is like walking on eggshells from the end user perspective. Sure, end user can be extremely intelligent / smart and figure it all out but that population is rare and that rare population can develop their custom kernel and libc patches to do something like this. This is a good science project to support heterogeneous ISA but practically not viable unless there is a high level end user use case. > Thanks, > drew
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com> To: Andrew Jones <ajones@ventanamicro.com> Cc: Samuel Holland <samuel.holland@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, linux-kernel@vger.kernel.org, tech-j-ext@lists.risc-v.org, Conor Dooley <conor@kernel.org>, kasan-dev@googlegroups.com, Evgenii Stepanov <eugenis@google.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, Guo Ren <guoren@kernel.org>, Heiko Stuebner <heiko@sntech.de>, Paul Walmsley <paul.walmsley@sifive.com> Subject: Re: [RISC-V] [tech-j-ext] [RFC PATCH 5/9] riscv: Split per-CPU and per-thread envcfg bits Date: Fri, 22 Mar 2024 09:52:48 -0700 [thread overview] Message-ID: <CAKC1njTGSMPekhvyRW0gz6+mY2S_==voCcspoLAyp38X-BcWcw@mail.gmail.com> (raw) In-Reply-To: <20240322-3c32873c4021477383a15f7d@orel> On Fri, Mar 22, 2024 at 1:09 AM Andrew Jones <ajones@ventanamicro.com> wrote: > > On Tue, Mar 19, 2024 at 09:39:52PM -0700, Deepak Gupta wrote: > ... > > I am not sure of the practicality of this heterogeneity for Zicboz and > > for that matter any of the upcoming > > features that'll be enabled via senvcfg (control flow integrity, > > pointer masking, etc). > > > > As an example if cache zeroing instructions are used by app binary, I > > expect it to be used in following > > manner > > > > - Explicitly inserting cbo.zero by application developer > > - Some compiler flag which ensures that structures larger than cache > > line gets zeroed by cbo.zero > > > > In either of the cases, the developer is not expecting to target it to > > a specific hart on SoC and instead expect it to work. > > There might be libraries (installed via sudo apt get) with cache zero > > support in them which may run in different address spaces. > > Should the library be aware of the CPU on which it's running. Now > > whoever is running these binaries should be aware which CPUs > > they get assigned to in order to avoid faults? > > > > That seems excessive, doesn't it? > > > > It might be safe to assume extensions like Zicboz will be on all harts if > any, but I wouldn't expect all extensions in the future to be present on > all available harts. For example, some Arm big.LITTLE boards only have > virt extensions on big CPUs. When a VMM wants to launch a guest it must > be aware of which CPUs it will use for the VCPU threads. For riscv, we > have the which-cpus variant of the hwprobe syscall to try and make this > type of thing easier to manage, but I agree it will still be a pain for > software since it will need to make that query and then set its affinity, > which is something it hasn't needed to do before. > Sure, the future may be a world where heterogeneous ISA is a thing. But that's not the present. Let's not try to build for something which doesn't exist. It has been (heterogeneous ISA) tried earlier many times and mostly have fallen flat (remember on Intel alder lake, Intel had to ship a ucode patch to disable AVX512 exactly for same reason) https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/2 As and when ISA features get enabled, they get compiled into libraries/binaries and end user many times use things like `taskset` to set affinity without even realizing there is some weirdness going on under the hood. For majority of use cases -- heterogeneous ISA doesn't make sense. Sure if someone is willing to build a custom SoC with heterogeneous ISA for their strict usecase, they control their software and hardware and thus they can do that. But littering linux kernel to support wierd usecases and putting a burden of that on majority of usecases and software is not wise. If something like this has to be done, I expect first that it doesn't force end users to learn about ISA differences between harts on their system and then figure out which installed packages have which ISA features compiled in. This is like walking on eggshells from the end user perspective. Sure, end user can be extremely intelligent / smart and figure it all out but that population is rare and that rare population can develop their custom kernel and libc patches to do something like this. This is a good science project to support heterogeneous ISA but practically not viable unless there is a high level end user use case. > Thanks, > drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-03-22 16:52 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-19 21:58 [RFC PATCH 0/9] riscv: Userspace pointer masking and tagged address ABI Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 1/9] dt-bindings: riscv: Add pointer masking ISA extensions Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 2/9] riscv: Add ISA extension parsing for pointer masking Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 3/9] riscv: Add CSR definitions " Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 4/9] riscv: Define is_compat_thread() Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 5/9] riscv: Split per-CPU and per-thread envcfg bits Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 23:55 ` [RISC-V] [tech-j-ext] " Deepak Gupta 2024-03-19 23:55 ` Deepak Gupta 2024-03-20 2:20 ` Samuel Holland 2024-03-20 2:20 ` Samuel Holland 2024-03-20 4:39 ` Deepak Gupta 2024-03-20 4:39 ` Deepak Gupta 2024-03-22 0:13 ` Samuel Holland 2024-03-22 0:13 ` Samuel Holland 2024-03-22 17:13 ` Deepak Gupta 2024-03-22 17:13 ` Deepak Gupta 2024-03-23 9:35 ` Andrew Jones 2024-03-23 9:35 ` Andrew Jones 2024-03-23 20:37 ` Deepak Gupta 2024-03-23 20:37 ` Deepak Gupta 2024-03-22 8:09 ` Andrew Jones 2024-03-22 8:09 ` Andrew Jones 2024-03-22 16:52 ` Deepak Gupta [this message] 2024-03-22 16:52 ` Deepak Gupta 2024-03-20 8:06 ` Conor Dooley 2024-03-20 8:06 ` Conor Dooley [not found] ` <17BE5F38AFE245E5.29196@lists.riscv.org> 2024-03-20 23:27 ` Deepak Gupta 2024-03-20 23:27 ` Deepak Gupta 2024-03-22 3:43 ` Samuel Holland 2024-03-22 3:43 ` Samuel Holland 2024-03-22 7:58 ` Andrew Jones 2024-03-22 7:58 ` Andrew Jones 2024-03-28 1:58 ` Deepak Gupta 2024-03-28 1:58 ` Deepak Gupta [not found] ` <17C0CB122DBB0EAE.6770@lists.riscv.org> 2024-03-28 19:34 ` Deepak Gupta 2024-03-28 19:34 ` Deepak Gupta 2024-03-19 21:58 ` [RFC PATCH 6/9] riscv: Add support for userspace pointer masking Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 7/9] riscv: Add support for the tagged address ABI Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 8/9] riscv: Allow ptrace control of " Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-19 21:58 ` [RFC PATCH 9/9] selftests: riscv: Add a pointer masking test Samuel Holland 2024-03-19 21:58 ` Samuel Holland 2024-03-20 17:21 ` Conor Dooley 2024-03-20 17:21 ` Conor Dooley 2024-03-20 18:04 ` Samuel Holland 2024-03-20 18:04 ` Samuel Holland
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='CAKC1njTGSMPekhvyRW0gz6+mY2S_==voCcspoLAyp38X-BcWcw@mail.gmail.com' \ --to=debug@rivosinc.com \ --cc=ajones@ventanamicro.com \ --cc=catalin.marinas@arm.com \ --cc=conor@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=eugenis@google.com \ --cc=guoren@kernel.org \ --cc=heiko@sntech.de \ --cc=kasan-dev@googlegroups.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=robh+dt@kernel.org \ --cc=samuel.holland@sifive.com \ --cc=tech-j-ext@lists.risc-v.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.