On Mon, Nov 05, 2018 at 02:51:33PM +0100, Arnd Bergmann wrote: > With the stricter policy you suggest, we'd loose the ability to support > some extensions that might be common: > > - an extension for user space that adds new registers that must be > saved and restored on a task switch, e.g. FPU, DSP or NPU > instructions. ARM supports several incompatible extensions like > that in one kernel, and this is really ugly, but I suspect RISC-V > will already need the same thing to support all combinations of > standard extensions, so from a practical perspective it's not > much different for custom extension, aside from the question > how far you want to go to discourage custom extensions by > requiring users to patch their kernels.
Palmer already explain that this is supposed to be handled by the XS bit + SBI calls. I'm personally not totally sold on the SBI call and standard ways to save the state in the instruction set, similar to modern x86 might be a better option, but that is something the privileged spec working group will have to decide. > - A crypto instruction for a cipher that is used in the kernel > for speeding up network or block data encryption. > This would typically be a standalone loadable module, so > the impact of allowing custom extensions in addition to > standard ones is minimal. And that is a prime example for something that should never be vendor specific. If an instruction set extension is useful for something entirely generic it should be standardized in a working group as an extension.
