On Mon, Jun 08, 2020 at 09:57:31AM +0100, Marc Zyngier wrote:
> Sparse complains that __hyp_this_cpu_ptr() returns something
> that is flagged noderef and not in the correct address space
> (both being the result of the __percpu annotation).
>
> Pretend that __hyp_this_cpu_ptr() knows what it is doing by
> forcefully casting the pointer with __kernel __force.
>
> Signed-off-by: Marc Zyngier <m...@kernel.org>
> ---
> arch/arm64/include/asm/kvm_asm.h | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h
> b/arch/arm64/include/asm/kvm_asm.h
> index 0c9b5fc4ba0a..82691406d493 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -81,12 +81,17 @@ extern u32 __kvm_get_mdcr_el2(void);
>
> extern char __smccc_workaround_1_smc[__SMCCC_WORKAROUND_1_SMC_SZ];
>
> -/* Home-grown __this_cpu_{ptr,read} variants that always work at HYP */
> +/*
> + * Home-grown __this_cpu_{ptr,read} variants that always work at HYP,
> + * provided that sym is really a *symbol* and not a pointer obtained from
Look at `this_cpu_ptr` one thing that stood out was `__verify_pcpu_ptr`
that is documented to be suitable for used in custom per CPU macros. I
didn't get how it worked (a type check?) but maybe it would work here
to validate the argment was indeed a per CPU symbol?
> + * a data structure. As for SHIFT_PERCPU_PTR(), the creative casting keeps
> + * sparse quiet.
> + */
> #define __hyp_this_cpu_ptr(sym)
> \
> ({ \
> void *__ptr = hyp_symbol_addr(sym); \
> __ptr += read_sysreg(tpidr_el2); \
> - (typeof(&sym))__ptr; \
> + (typeof(sym) __kernel __force *)__ptr; \
> })
>
> #define __hyp_this_cpu_read(sym) \
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
