On Thu, May 18, 2023 at 04:19:34PM +0000, Andy Chiu wrote: > Vector unit is disabled by default for all user processes. Thus, a > process will take a trap (illegal instruction) into kernel at the first > time when it uses Vector. Only after then, the kernel allocates V > context and starts take care of the context for that user process. > > Suggested-by: Richard Henderson <richard.henderson@xxxxxxxxxx> > Link: https://lore.kernel.org/r/3923eeee-e4dc-0911-40bf-84c34aee962d@xxxxxxxxxx > Signed-off-by: Andy Chiu <andy.chiu@xxxxxxxxxx> > --- > Hey Heiko and Conor, I am dropping you guys' A-b, T-b, and R-b because I > added a check in riscv_v_first_use_handler(). > +bool riscv_v_first_use_handler(struct pt_regs *regs) > +{ > + u32 __user *epc = (u32 __user *)regs->epc; > + u32 insn = (u32)regs->badaddr; > + > + /* Do not handle if V is not supported, or disabled */ > + if (!has_vector() || !(elf_hwcap & COMPAT_HWCAP_ISA_V)) > + return false; Remind me please, in what situation is this actually even possible? The COMPAT_HWCAP_ISA_V flag only gets set if CONFIG_RISCV_ISA_V is enabled & v is in the DT. has_vector() is backed by different things whether alternatives are enabled or not. With alternatives, it depends on the bit being set in the riscv_isa bitmap & the Kconfig option. Without alternatives it is backed by __riscv_isa_extension_available() which only depends in the riscv_isa bitmap. Since the bit in the bitmap does not get cleared if CONFIG_RISCV_ISA_V is not set, unlike the elf_hwcap bit which does, it seems like this might be the condition you are trying to prevent? If so, Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> Otherwise, please let me know where I have gone wrong! Thanks, Conor.
Attachment:
signature.asc
Description: PGP signature