Hi Andrea, On Wed, Jul 10, 2024 at 1:51 AM Andrea Parri <parri.andrea@xxxxxxxxx> wrote: > > > > I admit that I found this all quite difficult to read; IIUC, this is > > > missing an IS_ENABLED(CONFIG_RISCV_ISA_ZACAS) check. > > > > I'm not sure we need the zacas check here, since we could use a toolchain > > that supports zabha but not zacas, run this on a zabha/zacas platform and it > > would work. > > One specific set-up I was concerned about is as follows: > > 1) hardware implements both zabha and zacas > 2) toolchain supports both zabha and zacas > 3) CONFIG_RISCV_ISA_ZABHA=y and CONFIG_RISCV_ISA_ZACAS=n > > Since CONFIG_RISCV_ISA_ZABHA=y, the first asm goto will get executed > and, since the hardware implements zacas, that will result in a nop. > Then the second asm goto will get executed and, since the hardware > implements zabha, it will result in the j zabha. In conclusion, the > amocas instruction following the zabha: label will get executed, thus > violating (the semantics of) CONFIG_RISCV_ISA_ZACAS=n. IIUC, the diff > I've posted previously in this thread shared a similar limitation/bug. So you mean that when disabling Zacas, we should actually disable *all* the CAS instructions, even the Zabha ones. It makes sense and allows for a single way to disable the CAS instructions but keeping the other atomic operations. I'll fix that and add a comment. Thanks, Alex > > Andrea
