On Fri, Mar 22, 2024 at 1:09 AM Andrew Jones <ajones@xxxxxxxxxxxxxxxx> 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
