Hi Christoph, On 2023-11-22 2:40 AM, Christoph Hellwig wrote: >> - select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG)) >> + select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG >> + select DRM_AMD_DC_FP if PPC64 && ALTIVEC >> + select DRM_AMD_DC_FP if RISCV && FPU >> + select DRM_AMD_DC_FP if LOONGARCH || X86 > > This really is a mess. Can you add a ARCH_HAS_KERNEL_FPU_SUPPORT > symbol that all architetures that have it select instead, and them > make DRM_AMD_DC_FP depend on it? Yes, I have done this for v2, which I will send shortly. >> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) >> +#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) || defined(CONFIG_RISCV) >> kernel_fpu_begin(); >> #elif defined(CONFIG_PPC64) >> if (cpu_has_feature(CPU_FTR_VSX_COMP)) >> @@ -122,7 +124,7 @@ void dc_fpu_end(const char *function_name, const int line) >> >> depth = __this_cpu_dec_return(fpu_recursion_depth); >> if (depth == 0) { >> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) >> +#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) || defined(CONFIG_RISCV) >> kernel_fpu_end(); >> #elif defined(CONFIG_PPC64) >> if (cpu_has_feature(CPU_FTR_VSX_COMP)) > > And then this mess can go away. We'll need to decide if we want to > cover all the in-kernel vector support as part of it, which would > seem reasonable to me, or have a separate generic kernel_vector_begin > with it's own option. I think we may want to keep vector separate for performance on architectures with separate FP and vector register files. For now, I have limited my changes to FPU support only, which means I have removed VSX/Altivec from here; the AMDGPU code doesn't need Altivec anyway. >> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile >> index ea7d60f9a9b4..5c8f840ef323 100644 >> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile >> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile >> @@ -43,6 +43,12 @@ dml_ccflags := -mfpu=64 >> dml_rcflags := -msoft-float >> endif >> >> +ifdef CONFIG_RISCV >> +include $(srctree)/arch/riscv/Makefile.isa >> +# Remove V from the ISA string, like in arch/riscv/Makefile, but keep F and D. >> +dml_ccflags := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/') >> +endif >> + >> ifdef CONFIG_CC_IS_GCC >> ifneq ($(call gcc-min-version, 70100),y) >> IS_OLD_GCC = 1 > > And this is again not really something we should be doing. > Instead we need a generic way in Kconfig to enable FPU support > for an object file or set of, that the arch support can hook > into. I've included this in v2 as well. > Btw, I'm also really worried about folks using the FPU instructions > outside the kernel_fpu_begin/end windows in general (not directly > related to the RISC-V support). Can we have objecttool checks > for that similar to only allowing the unsafe uaccess in the > uaccess begin/end pairs? ARM partially enforces this at compile time: it disallows calling kernel_neon_begin() inside a translation unit that has NEON enabled. That doesn't prevent the programmer from calling a FPU-enabled function from outside a begin/end section, but it does prevent the compiler from generating unexpected FPU usage behind your back. I implemented this same functionality for RISC-V. Actually tracking all possibly-FPU-tainted functions and their call sites is probably possible, but a much larger task. Regards, Samuel