lkml.org 
[lkml]   [2020]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 13/27] KVM: arm64: Enable access to sanitized CPU features at EL2
> +int copy_ftr_reg(u32 id, struct arm64_ftr_reg *dst)
> +{
> + struct arm64_ftr_reg *regp = get_arm64_ftr_reg(id);
> +
> + if (!regp)
> + return -EINVAL;
> +
> + memcpy(dst, regp, sizeof(*regp));
> +
> + return 0;
> +}
> +
> #define read_sysreg_case(r) \
> case r: return read_sysreg_s(r)
>
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index dd8ccc9efb6a..c35d768672eb 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -116,6 +116,8 @@ __kvm_nvhe___memcpy = __kvm_nvhe___pi_memcpy;
> __kvm_nvhe___memset = __kvm_nvhe___pi_memset;
> #endif
>
> +_kvm_nvhe___flush_dcache_area = __kvm_nvhe___pi___flush_dcache_area;
> +

Could you help my understand why we need this?
* Why do we need PI routines in the first place? Would my series that fixes
relocations in hyp code remove the need?
* You added these aliases for the string routines because you were worried
somebody would change the implementation in arch/arm64/lib, right? But this
cache flush function is defined in hyp/nvhe. So why do we need to point to
the PI alias if we control the implementation?

\
 
 \ /
  Last update: 2020-11-23 14:41    [W:0.555 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site