[PATCH v5 02/27] arm64: cpufeature: Use alternatives for VHE cpu_enable
From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
Date: 2018-09-12 12:37:40
Also in:
lkml
On 12/09/18 11:28, James Morse wrote:
Hi Julien, On 28/08/18 16:51, Julien Thierry wrote:quoted
The cpu_enable callback for VHE feature requires all alternatives to have been applied. This prevents applying VHE alternative separately from the rest. Use an alternative depending on VHE feature to know whether VHE alternatives have already been applied.quoted
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 1e433ac..3bc1c8b 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c@@ -1022,8 +1024,15 @@ static void cpu_copy_el2regs(const struct arm64_cpu_capabilities *__unused) * that, freshly-onlined CPUs will set tpidr_el2, so we don't need to * do anything here. */ - if (!alternatives_applied) - write_sysreg(read_sysreg(tpidr_el1), tpidr_el2); + asm volatile(ALTERNATIVE( + "mrs %0, tpidr_el1\n" + "msr tpidr_el2, %0", + "nop\n" + "nop", + ARM64_HAS_VIRT_HOST_EXTN) + : "+r" (tmp) + : + : "memory"); } #endifCatalin's preference was to keep this all in C: https://patchwork.kernel.org/patch/10007977/ , for which we need to know if 'the' alternative has been applied. I suspect there may be more registers in this list if we have to switch to another EL2 register using alternatives. (but I don't have an example). Could we make 'alternatives_applied' a macro that takes the cap as an argument?
Another crude way of doing this would be, take the action in the matches() of a boot capability, when scope contains SCOPE_BOOT_CPU (to make sure that we don't do this always for other "matches()" call backs via "this_cpu_has_cap()") and get rid of this "enable()". But that looks more hackish. Suzuki