* [PATCH v5 05/16] KVM: arm64: Stop save/restoring host tpidr_el1 on VHE
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206190142.9246-1-james.morse@arm.com>
Now that a VHE host uses tpidr_el2 for the cpu offset we no longer
need KVM to save/restore tpidr_el1. Move this from the 'common' code
into the non-vhe code. While we're at it, on VHE we don't need to
save the ELR or SPSR as kernel_entry in entry.S will have pushed these
onto the kernel stack, and will restore them from there. Move these
to the non-vhe code as we need them to get back to the host.
Finally remove the always-copy-tpidr we hid in the stage2 setup
code, cpufeature's enable callback will do this for VHE, we only
need KVM to do it for non-vhe. Add the copy into kvm-init instead.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
---
Changes since v1:
* Switched KVM<->arm64 in the subject.
arch/arm64/kvm/hyp-init.S | 4 ++++
arch/arm64/kvm/hyp/s2-setup.c | 3 ---
arch/arm64/kvm/hyp/sysreg-sr.c | 16 ++++++++--------
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3f9615582377..fbf259893f6a 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -122,6 +122,10 @@ CPU_BE( orr x4, x4, #SCTLR_ELx_EE)
kern_hyp_va x2
msr vbar_el2, x2
+ /* copy tpidr_el1 into tpidr_el2 for use by HYP */
+ mrs x1, tpidr_el1
+ msr tpidr_el2, x1
+
/* Hello, World! */
eret
ENDPROC(__kvm_hyp_init)
diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
index 7fb88274eba1..a81f5e10fc8c 100644
--- a/arch/arm64/kvm/hyp/s2-setup.c
+++ b/arch/arm64/kvm/hyp/s2-setup.c
@@ -84,8 +84,5 @@ u32 __hyp_text __init_stage2_translation(void)
write_sysreg(val, vtcr_el2);
- /* copy tpidr_el1 into tpidr_el2 for use by HYP */
- write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);
-
return parange;
}
diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 934137647837..c54cc2afb92b 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -27,8 +27,8 @@ static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { }
/*
* Non-VHE: Both host and guest must save everything.
*
- * VHE: Host must save tpidr*_el[01], actlr_el1, mdscr_el1, sp0, pc,
- * pstate, and guest must save everything.
+ * VHE: Host must save tpidr*_el0, actlr_el1, mdscr_el1, sp_el0,
+ * and guest must save everything.
*/
static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
@@ -36,11 +36,8 @@ static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
ctxt->sys_regs[ACTLR_EL1] = read_sysreg(actlr_el1);
ctxt->sys_regs[TPIDR_EL0] = read_sysreg(tpidr_el0);
ctxt->sys_regs[TPIDRRO_EL0] = read_sysreg(tpidrro_el0);
- ctxt->sys_regs[TPIDR_EL1] = read_sysreg(tpidr_el1);
ctxt->sys_regs[MDSCR_EL1] = read_sysreg(mdscr_el1);
ctxt->gp_regs.regs.sp = read_sysreg(sp_el0);
- ctxt->gp_regs.regs.pc = read_sysreg_el2(elr);
- ctxt->gp_regs.regs.pstate = read_sysreg_el2(spsr);
}
static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
@@ -62,10 +59,13 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
ctxt->sys_regs[AMAIR_EL1] = read_sysreg_el1(amair);
ctxt->sys_regs[CNTKCTL_EL1] = read_sysreg_el1(cntkctl);
ctxt->sys_regs[PAR_EL1] = read_sysreg(par_el1);
+ ctxt->sys_regs[TPIDR_EL1] = read_sysreg(tpidr_el1);
ctxt->gp_regs.sp_el1 = read_sysreg(sp_el1);
ctxt->gp_regs.elr_el1 = read_sysreg_el1(elr);
ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
+ ctxt->gp_regs.regs.pc = read_sysreg_el2(elr);
+ ctxt->gp_regs.regs.pstate = read_sysreg_el2(spsr);
}
static hyp_alternate_select(__sysreg_call_save_host_state,
@@ -89,11 +89,8 @@ static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctx
write_sysreg(ctxt->sys_regs[ACTLR_EL1], actlr_el1);
write_sysreg(ctxt->sys_regs[TPIDR_EL0], tpidr_el0);
write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
- write_sysreg(ctxt->sys_regs[TPIDR_EL1], tpidr_el1);
write_sysreg(ctxt->sys_regs[MDSCR_EL1], mdscr_el1);
write_sysreg(ctxt->gp_regs.regs.sp, sp_el0);
- write_sysreg_el2(ctxt->gp_regs.regs.pc, elr);
- write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
}
static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
@@ -115,10 +112,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
write_sysreg_el1(ctxt->sys_regs[AMAIR_EL1], amair);
write_sysreg_el1(ctxt->sys_regs[CNTKCTL_EL1], cntkctl);
write_sysreg(ctxt->sys_regs[PAR_EL1], par_el1);
+ write_sysreg(ctxt->sys_regs[TPIDR_EL1], tpidr_el1);
write_sysreg(ctxt->gp_regs.sp_el1, sp_el1);
write_sysreg_el1(ctxt->gp_regs.elr_el1, elr);
write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
+ write_sysreg_el2(ctxt->gp_regs.regs.pc, elr);
+ write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
}
static hyp_alternate_select(__sysreg_call_restore_host_state,
--
2.15.0
^ permalink raw reply related
* [PATCH v5 04/16] arm64: alternatives: use tpidr_el2 on VHE hosts
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206190142.9246-1-james.morse@arm.com>
Now that KVM uses tpidr_el2 in the same way as Linux's cpu_offset in
tpidr_el1, merge the two. This saves KVM from save/restoring tpidr_el1
on VHE hosts, and allows future code to blindly access per-cpu variables
without triggering world-switch.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changes since v3:
* Moved 'alternatives_applied' test all into C,
* Made enable method static and dragged up before first-use.
Changes since v1:
* cpu_copy_el2regs()'s 'have I been patched' test now always sets a register,
just in case the compiler optimises out part of the logic.
arch/arm64/include/asm/alternative.h | 2 ++
arch/arm64/include/asm/assembler.h | 8 ++++++++
arch/arm64/include/asm/percpu.h | 11 +++++++++--
arch/arm64/kernel/alternative.c | 9 +++++----
arch/arm64/kernel/cpufeature.c | 17 +++++++++++++++++
arch/arm64/mm/proc.S | 8 ++++++++
6 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 4a85c6952a22..669028172fd6 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -12,6 +12,8 @@
#include <linux/stddef.h>
#include <linux/stringify.h>
+extern int alternatives_applied;
+
struct alt_instr {
s32 orig_offset; /* offset to original instruction */
s32 alt_offset; /* offset to replacement instruction */
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index c45bc94f15d0..c070c263021e 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -254,7 +254,11 @@ lr .req x30 // link register
#else
adr_l \dst, \sym
#endif
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
mrs \tmp, tpidr_el1
+alternative_else
+ mrs \tmp, tpidr_el2
+alternative_endif
add \dst, \dst, \tmp
.endm
@@ -265,7 +269,11 @@ lr .req x30 // link register
*/
.macro ldr_this_cpu dst, sym, tmp
adr_l \dst, \sym
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
mrs \tmp, tpidr_el1
+alternative_else
+ mrs \tmp, tpidr_el2
+alternative_endif
ldr \dst, [\dst, \tmp]
.endm
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 3bd498e4de4c..43393208229e 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -16,11 +16,15 @@
#ifndef __ASM_PERCPU_H
#define __ASM_PERCPU_H
+#include <asm/alternative.h>
#include <asm/stack_pointer.h>
static inline void set_my_cpu_offset(unsigned long off)
{
- asm volatile("msr tpidr_el1, %0" :: "r" (off) : "memory");
+ asm volatile(ALTERNATIVE("msr tpidr_el1, %0",
+ "msr tpidr_el2, %0",
+ ARM64_HAS_VIRT_HOST_EXTN)
+ :: "r" (off) : "memory");
}
static inline unsigned long __my_cpu_offset(void)
@@ -31,7 +35,10 @@ static inline unsigned long __my_cpu_offset(void)
* We want to allow caching the value, so avoid using volatile and
* instead use a fake stack read to hazard against barrier().
*/
- asm("mrs %0, tpidr_el1" : "=r" (off) :
+ asm(ALTERNATIVE("mrs %0, tpidr_el1",
+ "mrs %0, tpidr_el2",
+ ARM64_HAS_VIRT_HOST_EXTN)
+ : "=r" (off) :
"Q" (*(const unsigned long *)current_stack_pointer));
return off;
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 6dd0a3a3e5c9..414288a558c8 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -32,6 +32,8 @@
#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+int alternatives_applied;
+
struct alt_region {
struct alt_instr *begin;
struct alt_instr *end;
@@ -143,7 +145,6 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
*/
static int __apply_alternatives_multi_stop(void *unused)
{
- static int patched = 0;
struct alt_region region = {
.begin = (struct alt_instr *)__alt_instructions,
.end = (struct alt_instr *)__alt_instructions_end,
@@ -151,14 +152,14 @@ static int __apply_alternatives_multi_stop(void *unused)
/* We always have a CPU 0 at this point (__init) */
if (smp_processor_id()) {
- while (!READ_ONCE(patched))
+ while (!READ_ONCE(alternatives_applied))
cpu_relax();
isb();
} else {
- BUG_ON(patched);
+ BUG_ON(alternatives_applied);
__apply_alternatives(®ion, true);
/* Barriers provided by the cache flushing */
- WRITE_ONCE(patched, 1);
+ WRITE_ONCE(alternatives_applied, 1);
}
return 0;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 98e6563015a4..cb9c4e5a72f8 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -879,6 +879,22 @@ static int __init parse_kpti(char *str)
__setup("kpti=", parse_kpti);
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
+static int cpu_copy_el2regs(void *__unused)
+{
+ /*
+ * Copy register values that aren't redirected by hardware.
+ *
+ * Before code patching, we only set tpidr_el1, all CPUs need to copy
+ * this value to tpidr_el2 before we patch the code. Once we've done
+ * 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);
+
+ return 0;
+}
+
static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
@@ -948,6 +964,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.capability = ARM64_HAS_VIRT_HOST_EXTN,
.def_scope = SCOPE_SYSTEM,
.matches = runs_at_el2,
+ .enable = cpu_copy_el2regs,
},
{
.desc = "32-bit EL0 Support",
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 3146dc96f05b..2f5051411783 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -70,7 +70,11 @@ ENTRY(cpu_do_suspend)
mrs x8, mdscr_el1
mrs x9, oslsr_el1
mrs x10, sctlr_el1
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
mrs x11, tpidr_el1
+alternative_else
+ mrs x11, tpidr_el2
+alternative_endif
mrs x12, sp_el0
stp x2, x3, [x0]
stp x4, xzr, [x0, #16]
@@ -116,7 +120,11 @@ ENTRY(cpu_do_resume)
msr mdscr_el1, x10
msr sctlr_el1, x12
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
msr tpidr_el1, x13
+alternative_else
+ msr tpidr_el2, x13
+alternative_endif
msr sp_el0, x14
/*
* Restore oslsr_el1 by writing oslar_el1
--
2.15.0
^ permalink raw reply related
* [PATCH v5 03/16] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206190142.9246-1-james.morse@arm.com>
Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the
host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and
on VHE they can be the same register.
KVM calls hyp_panic() when anything unexpected happens. This may occur
while a guest owns the EL1 registers. KVM stashes the vcpu pointer in
tpidr_el2, which it uses to find the host context in order to restore
the host EL1 registers before parachuting into the host's panic().
The host context is a struct kvm_cpu_context allocated in the per-cpu
area, and mapped to hyp. Given the per-cpu offset for this CPU, this is
easy to find. Change hyp_panic() to take a pointer to the
struct kvm_cpu_context. Wrap these calls with an asm function that
retrieves the struct kvm_cpu_context from the host's per-cpu area.
Copy the per-cpu offset from the hosts tpidr_el1 into tpidr_el2 during
kvm init. (Later patches will make this unnecessary for VHE hosts)
We print out the vcpu pointer as part of the panic message. Add a back
reference to the 'running vcpu' in the host cpu context to preserve this.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
---
Changes since v1:
* Added a comment explaining how =kvm_host_cpu_state gets from a host-va
to a hyp va.
* Added the first paragraph to the commit message.
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kvm/hyp/hyp-entry.S | 12 ++++++++++++
arch/arm64/kvm/hyp/s2-setup.c | 3 +++
arch/arm64/kvm/hyp/switch.c | 25 +++++++++++++------------
4 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 674912d7a571..d80e72e8f6f0 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -192,6 +192,8 @@ struct kvm_cpu_context {
u64 sys_regs[NR_SYS_REGS];
u32 copro[NR_COPRO_REGS];
};
+
+ struct kvm_vcpu *__hyp_running_vcpu;
};
typedef struct kvm_cpu_context kvm_cpu_context_t;
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index fce7cc507e0a..e4f37b9dd47c 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -163,6 +163,18 @@ ENTRY(__hyp_do_panic)
eret
ENDPROC(__hyp_do_panic)
+ENTRY(__hyp_panic)
+ /*
+ * '=kvm_host_cpu_state' is a host VA from the constant pool, it may
+ * not be accessible by this address from EL2, hyp_panic() converts
+ * it with kern_hyp_va() before use.
+ */
+ ldr x0, =kvm_host_cpu_state
+ mrs x1, tpidr_el2
+ add x0, x0, x1
+ b hyp_panic
+ENDPROC(__hyp_panic)
+
.macro invalid_vector label, target = __hyp_panic
.align 2
\label:
diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
index a81f5e10fc8c..7fb88274eba1 100644
--- a/arch/arm64/kvm/hyp/s2-setup.c
+++ b/arch/arm64/kvm/hyp/s2-setup.c
@@ -84,5 +84,8 @@ u32 __hyp_text __init_stage2_translation(void)
write_sysreg(val, vtcr_el2);
+ /* copy tpidr_el1 into tpidr_el2 for use by HYP */
+ write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);
+
return parange;
}
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 525c01f48867..41b3e74ca707 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -292,9 +292,9 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
u64 exit_code;
vcpu = kern_hyp_va(vcpu);
- write_sysreg(vcpu, tpidr_el2);
host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
+ host_ctxt->__hyp_running_vcpu = vcpu;
guest_ctxt = &vcpu->arch.ctxt;
__sysreg_save_host_state(host_ctxt);
@@ -399,7 +399,8 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
static const char __hyp_panic_string[] = "HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n";
-static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
+static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par,
+ struct kvm_vcpu *vcpu)
{
unsigned long str_va;
@@ -413,35 +414,35 @@ static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
__hyp_do_panic(str_va,
spsr, elr,
read_sysreg(esr_el2), read_sysreg_el2(far),
- read_sysreg(hpfar_el2), par,
- (void *)read_sysreg(tpidr_el2));
+ read_sysreg(hpfar_el2), par, vcpu);
}
-static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64 elr, u64 par)
+static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64 elr, u64 par,
+ struct kvm_vcpu *vcpu)
{
panic(__hyp_panic_string,
spsr, elr,
read_sysreg_el2(esr), read_sysreg_el2(far),
- read_sysreg(hpfar_el2), par,
- (void *)read_sysreg(tpidr_el2));
+ read_sysreg(hpfar_el2), par, vcpu);
}
static hyp_alternate_select(__hyp_call_panic,
__hyp_call_panic_nvhe, __hyp_call_panic_vhe,
ARM64_HAS_VIRT_HOST_EXTN);
-void __hyp_text __noreturn __hyp_panic(void)
+void __hyp_text __noreturn hyp_panic(struct kvm_cpu_context *__host_ctxt)
{
+ struct kvm_vcpu *vcpu = NULL;
+
u64 spsr = read_sysreg_el2(spsr);
u64 elr = read_sysreg_el2(elr);
u64 par = read_sysreg(par_el1);
if (read_sysreg(vttbr_el2)) {
- struct kvm_vcpu *vcpu;
struct kvm_cpu_context *host_ctxt;
- vcpu = (struct kvm_vcpu *)read_sysreg(tpidr_el2);
- host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
+ host_ctxt = kern_hyp_va(__host_ctxt);
+ vcpu = host_ctxt->__hyp_running_vcpu;
__timer_disable_traps(vcpu);
__deactivate_traps(vcpu);
__deactivate_vm(vcpu);
@@ -449,7 +450,7 @@ void __hyp_text __noreturn __hyp_panic(void)
}
/* Call panic for real */
- __hyp_call_panic()(spsr, elr, par);
+ __hyp_call_panic()(spsr, elr, par, vcpu);
unreachable();
}
--
2.15.0
^ permalink raw reply related
* [PATCH v5 02/16] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206190142.9246-1-james.morse@arm.com>
kvm_host_cpu_state is a per-cpu allocation made from kvm_arch_init()
used to store the host EL1 registers when KVM switches to a guest.
Make it easier for ASM to generate pointers into this per-cpu memory
by making it a static allocation.
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Christoffer Dall <cdall@linaro.org>
---
virt/kvm/arm/arm.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a67c106d73f5..732d0b68d80f 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -53,8 +53,8 @@
__asm__(".arch_extension virt");
#endif
+DEFINE_PER_CPU(kvm_cpu_context_t, kvm_host_cpu_state);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
-static kvm_cpu_context_t __percpu *kvm_host_cpu_state;
/* Per-CPU variable containing the currently running vcpu. */
static DEFINE_PER_CPU(struct kvm_vcpu *, kvm_arm_running_vcpu);
@@ -354,7 +354,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
}
vcpu->cpu = cpu;
- vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
+ vcpu->arch.host_cpu_context = this_cpu_ptr(&kvm_host_cpu_state);
kvm_arm_set_running_vcpu(vcpu);
kvm_vgic_load(vcpu);
@@ -1269,19 +1269,8 @@ static inline void hyp_cpu_pm_exit(void)
}
#endif
-static void teardown_common_resources(void)
-{
- free_percpu(kvm_host_cpu_state);
-}
-
static int init_common_resources(void)
{
- kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
- if (!kvm_host_cpu_state) {
- kvm_err("Cannot allocate host CPU state\n");
- return -ENOMEM;
- }
-
/* set size of VMID supported by CPU */
kvm_vmid_bits = kvm_get_vmid_bits();
kvm_info("%d-bit VMID\n", kvm_vmid_bits);
@@ -1417,7 +1406,7 @@ static int init_hyp_mode(void)
for_each_possible_cpu(cpu) {
kvm_cpu_context_t *cpu_ctxt;
- cpu_ctxt = per_cpu_ptr(kvm_host_cpu_state, cpu);
+ cpu_ctxt = per_cpu_ptr(&kvm_host_cpu_state, cpu);
err = create_hyp_mappings(cpu_ctxt, cpu_ctxt + 1, PAGE_HYP);
if (err) {
@@ -1541,7 +1530,6 @@ int kvm_arch_init(void *opaque)
if (!in_hyp_mode)
teardown_hyp_mode();
out_err:
- teardown_common_resources();
return err;
}
--
2.15.0
^ permalink raw reply related
* [PATCH v5 01/16] KVM: arm64: Store vcpu on the stack during __guest_enter()
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206190142.9246-1-james.morse@arm.com>
KVM uses tpidr_el2 as its private vcpu register, which makes sense for
non-vhe world switch as only KVM can access this register. This means
vhe Linux has to use tpidr_el1, which KVM has to save/restore as part
of the host context.
If the SDEI handler code runs behind KVMs back, it mustn't access any
per-cpu variables. To allow this on systems with vhe we need to make
the host use tpidr_el2, saving KVM from save/restoring it.
__guest_enter() stores the host_ctxt on the stack, do the same with
the vcpu.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
---
Changes since v2:
* Added middle paragraph of commit message.
arch/arm64/kvm/hyp/entry.S | 10 +++++++---
arch/arm64/kvm/hyp/hyp-entry.S | 6 +++---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 12ee62d6d410..9a8ab5dddd9e 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -62,8 +62,8 @@ ENTRY(__guest_enter)
// Store the host regs
save_callee_saved_regs x1
- // Store the host_ctxt for use at exit time
- str x1, [sp, #-16]!
+ // Store host_ctxt and vcpu for use at exit time
+ stp x1, x0, [sp, #-16]!
add x18, x0, #VCPU_CONTEXT
@@ -159,6 +159,10 @@ abort_guest_exit_end:
ENDPROC(__guest_exit)
ENTRY(__fpsimd_guest_restore)
+ // x0: esr
+ // x1: vcpu
+ // x2-x29,lr: vcpu regs
+ // vcpu x0-x1 on the stack
stp x2, x3, [sp, #-16]!
stp x4, lr, [sp, #-16]!
@@ -173,7 +177,7 @@ alternative_else
alternative_endif
isb
- mrs x3, tpidr_el2
+ mov x3, x1
ldr x0, [x3, #VCPU_HOST_CONTEXT]
kern_hyp_va x0
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 5170ce1021da..fce7cc507e0a 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -104,6 +104,7 @@ el1_trap:
/*
* x0: ESR_EC
*/
+ ldr x1, [sp, #16 + 8] // vcpu stored by __guest_enter
/*
* We trap the first access to the FP/SIMD to save the host context
@@ -116,19 +117,18 @@ alternative_if_not ARM64_HAS_NO_FPSIMD
b.eq __fpsimd_guest_restore
alternative_else_nop_endif
- mrs x1, tpidr_el2
mov x0, #ARM_EXCEPTION_TRAP
b __guest_exit
el1_irq:
stp x0, x1, [sp, #-16]!
- mrs x1, tpidr_el2
+ ldr x1, [sp, #16 + 8]
mov x0, #ARM_EXCEPTION_IRQ
b __guest_exit
el1_error:
stp x0, x1, [sp, #-16]!
- mrs x1, tpidr_el2
+ ldr x1, [sp, #16 + 8]
mov x0, #ARM_EXCEPTION_EL1_SERROR
b __guest_exit
--
2.15.0
^ permalink raw reply related
* [PATCH v5 00/16] arm64/firmware: Software Delegated Exception Interface
From: James Morse @ 2017-12-06 19:01 UTC (permalink / raw)
To: linux-arm-kernel
The Software Delegated Exception Interface (SDEI) is an ARM specification
for registering callbacks from the platform firmware into the OS.
This is intended to be used to implement firmware-first RAS notifications,
but also supports vendor-defined events and binding IRQs as events.
The document is here:
http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
I anticipate once reviewed this series will go via the arm64 tree as it has
an ever closer interaction with the arch code. Despite the bulk of the code
being under /drivers/firmware/.
The major change in v5 is the locking.
Lockdep found a three-way issue via the hotplug state machine. (I argue it
can't happen, but lockdep doesn't care.) Now the hotplug callbacks save
nothing, and restore the OS-view of registered/enabled. This makes
bound-interrupts harder to work with. I dropped Catalin's ack on all affected
patches.
SDEI interacts with Will's KTPI/kernel-unmapping series. These patches
are based on v4.15-rc2 + v3 of that series[0], including the use-rodata diff[1].
Patches 15 and 16 contain the extra tramponline stuff.
Christoffer was increasing the use of tpidr_el2 in EL2, which shares the
first five patches, so if this is merged at the same time as his optimisations
some co-ordination may be required.
The regular boiler plate:
This series (juggles some registers with KVM+VHE, then) adds a DT binding to
trigger probing of the interface and support for the SDEI API.
SDEI runs between adjacent exception levels, so events will always be delivered
to EL2 if firmware is at EL3. For VHE hosts we run the SDEI event handler
behind KVM's back with all exceptions masked. Once the handler has done its
work we return to the appropriate vbar+irq entry. This allows KVM to
world-switch and deliver any signals sent by the handler to Qemu/kvmtool. We
do the same thing if we interrupt host EL0. If we interrupted code with
interrupts masked, we use a different API call to return to the interrupted
context.
What about non-VHE KVM? If you don't have VHE support and boot at EL2, the
kernel drops to EL1. This driver will print an error message then give up. This
is because events would still be delivered to EL2 hitting either KVM, or the
hyp-stub. Supporting this is complicated, but because the main use-case is
RAS, and ARM v8.2's RAS extensions imply v8.1's Virtual Host Extensions, we
can assume all platforms with SDEI will support VHE too. (I have some ideas
on how to support non-VHE).
Running the event handler behind VHE-KVM's back has some side effects: The
event handler will blindly use any registers that are shared between the host
and guest. The two that I think matter are TPIDR_EL1, and the debug state. The
guest may have set MDSCR_EL1 so debug exceptions must remain masked. The
guest's TPIDR_EL1 will be used by the event handler if it accesses per-cpu
variables. This needs fixing. The first part of this series juggles KVMs use
of TPIDR_EL2 so that we share it with the host on VHE systems. An equivalent
change for 32bit is (still) on my todo list. (the alternative to this is to
have a parody world switch in the SDEI event handler, but this would mean
special casing interrupted guests, and be an ABI link to KVM.)
Is this another begins-with-S RAS mechanism for arm64? Yes.
Why? Any notification delivered as an exception will overwrite the exception
registers. This is fatal for the running thread if it happens during entry.S's
kernel_enter or kernel_exit. Instead of adding masking and routing controls,
events are delivered to a registered address at a fixed exception level and
don't change the exception registers when delivered.
This series can be retrieved from:
git://linux-arm.org/linux-jm.git -b sdei/v5/base
Questions and contradictions welcome!
Thanks,
James
[Changes since previous versions are noted on each patch]
[0] https://lkml.org/lkml/2017/12/6/306
[1] https://lkml.org/lkml/2017/12/6/340
James Morse (16):
KVM: arm64: Store vcpu on the stack during __guest_enter()
KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu
allocation
KVM: arm64: Change hyp_panic()s dependency on tpidr_el2
arm64: alternatives: use tpidr_el2 on VHE hosts
KVM: arm64: Stop save/restoring host tpidr_el1 on VHE
Docs: dt: add devicetree binding for describing arm64 SDEI firmware
firmware: arm_sdei: Add driver for Software Delegated Exceptions
arm64: Add vmap_stack header file
arm64: uaccess: Add PAN helper
arm64: kernel: Add arch-specific SDEI entry code and CPU masking
firmware: arm_sdei: Add support for CPU and system power states
firmware: arm_sdei: add support for CPU private events
arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI
firmware: arm_sdei: Discover SDEI support via ACPI
arm64: mmu: add the entry tramolines start/end section markers into
sections.h
arm64: sdei: Add trampoline code for remapping the kernel
.../devicetree/bindings/arm/firmware/sdei.txt | 42 +
MAINTAINERS | 9 +
arch/arm64/include/asm/alternative.h | 2 +
arch/arm64/include/asm/assembler.h | 8 +
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/include/asm/mmu.h | 3 +-
arch/arm64/include/asm/percpu.h | 11 +-
arch/arm64/include/asm/sdei.h | 57 +
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/include/asm/stacktrace.h | 3 +
arch/arm64/include/asm/uaccess.h | 12 +
arch/arm64/include/asm/vmap_stack.h | 26 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi.c | 2 +-
arch/arm64/kernel/alternative.c | 9 +-
arch/arm64/kernel/asm-offsets.c | 5 +
arch/arm64/kernel/cpufeature.c | 17 +
arch/arm64/kernel/entry.S | 177 ++++
arch/arm64/kernel/irq.c | 13 +-
arch/arm64/kernel/sdei.c | 235 +++++
arch/arm64/kernel/smp.c | 11 +-
arch/arm64/kernel/suspend.c | 4 +-
arch/arm64/kvm/hyp-init.S | 4 +
arch/arm64/kvm/hyp/entry.S | 10 +-
arch/arm64/kvm/hyp/hyp-entry.S | 18 +-
arch/arm64/kvm/hyp/switch.c | 25 +-
arch/arm64/kvm/hyp/sysreg-sr.c | 16 +-
arch/arm64/mm/mmu.c | 2 -
arch/arm64/mm/proc.S | 8 +
drivers/firmware/Kconfig | 8 +
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_sdei.c | 1091 ++++++++++++++++++++
include/linux/arm_sdei.h | 79 ++
include/linux/cpuhotplug.h | 1 +
include/linux/psci.h | 3 +-
include/uapi/linux/arm_sdei.h | 73 ++
virt/kvm/arm/arm.c | 18 +-
37 files changed, 1941 insertions(+), 66 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/firmware/sdei.txt
create mode 100644 arch/arm64/include/asm/sdei.h
create mode 100644 arch/arm64/include/asm/vmap_stack.h
create mode 100644 arch/arm64/kernel/sdei.c
create mode 100644 drivers/firmware/arm_sdei.c
create mode 100644 include/linux/arm_sdei.h
create mode 100644 include/uapi/linux/arm_sdei.h
--
2.15.0
^ permalink raw reply
* [PATCH 4/9] ASoC: sun8i-codec: Add support for A64 SoC
From: Maxime Ripard @ 2017-12-06 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206154810.eb2czpb4kusxv5kj@sirena.org.uk>
On Wed, Dec 06, 2017 at 03:48:10PM +0000, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 04:32:05PM +0100, Maxime Ripard wrote:
>
> > BCLK is sample rate * sample size * channels, and LRCK is running at
> > the sample rate. So the ratio is the sample size * channels.
>
> > Anything deviating from those standard i2s concepts should at least be
> > documented, with arguments to back them off.
>
> BCLK can be higher than the minimum there in most formats, though some
> hardware is more restrictive so we tend to go for the minimum clock rate.
How does that work in such a case? Is LRCK faster as well, and we're
keeping the same ratio, or will the codec buffer the current sample
until the next word?
Is it usually a property of the codec or the DAI?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/74219ba6/attachment-0001.sig>
^ permalink raw reply
* [PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC
From: Mark Brown @ 2017-12-06 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206072402.11694-1-o.rempel@pengutronix.de>
On Wed, Dec 06, 2017 at 08:23:56AM +0100, Oleksij Rempel wrote:
> 2017.12.06:
> Adding Linus. Probably there is no maintainer for this patch set.
> No changes are made, tested on v4.15-rc1.
Have any of the i.MX maintainers said anything about this? I was about
to reply to this asking if they were ever going to review it as it keeps
on getting resent but I'm not seeing any interest from any of them but
the main immediate audience is i.MX systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/20a642d4/attachment.sig>
^ permalink raw reply
* [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
From: Ingo Molnar @ 2017-12-06 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206032437.pifxxcewgozlghfs@GaryWorkstation>
* Gary Lin <glin@suse.com> wrote:
> On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> wrote:
> > > The series of patches introduce Security Version to EFI stub.
> > >
> > > Security Version is a monotonically increasing number and designed to
> > > prevent the user from loading an insecure kernel accidentally. The
> > > bootloader maintains a list of security versions corresponding to
> > > different distributions. After fixing a critical vulnerability, the
> > > distribution kernel maintainer bumps the "version", and the bootloader
> > > updates the list automatically. When the user tries to load a kernel
> > > with a lower security version, the bootloader shows a warning prompt
> > > to notify the user the potential risk.
> >
> > If a distribution releases a kernel with a higher security version and
> > that it automatically updated on boot, what happens if that kernel
> > contains a different bug that causes it to fail to boot or break
> > critical functionality? At that point, the user's machine would be in
> > a state where the higher security version is enforced but the only
> > kernel that provides that is broken. Wouldn't that make a bad
> > situation even worse by now requiring manual acceptance of the older
> > SV kernel boot physically at the machine?
> >
> > I feel like I'm missing a detail here or something.
> >
> If the new kernel fails to boot, then the user has to choose the kernel
> manually anyway, and there will be an option in the warning prompt to
> lower SV.
And what if the firmware does not support a lowering of the SV?
Thanks,
Ingo
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Will Deacon @ 2017-12-06 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206181801.igg5i6qepm4da56g@armageddon.cambridge.arm.com>
On Wed, Dec 06, 2017 at 06:18:01PM +0000, Catalin Marinas wrote:
> On Wed, Dec 06, 2017 at 06:07:07PM +0000, Will Deacon wrote:
> > On Wed, Dec 06, 2017 at 06:01:35PM +0000, Catalin Marinas wrote:
> > > On Wed, Dec 06, 2017 at 05:56:42PM +0000, Will Deacon wrote:
> > > > On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
> > > > > On 12/6/2017 4:46 PM, Will Deacon wrote:
> > > > > > After lots of collective head scratching in response to Vinayak's mail
> > > > > > here:
> > > > > >
> > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
> > > > > >
> > > > > > It turns out that we have a problem with SW PAN and kernel threads, where
> > > > > > the saved ttbr0 value for a kernel thread can be stale and subsequently
> > > > > > inherited by other kernel threads over a fork.
> > > > > >
> > > > > > These two patches attempt to fix that. We've not be able to reproduce
> > > > > > the exact failure reported above, but I added some assertions to the
> > > > > > uaccess routines to check for discrepancies between the active_mm pgd
> > > > > > and the saved ttbr0 value (ignoring the zero page) and these no longer
> > > > > > fire with these changes, but do fire without them if EFI runtime services
> > > > > > are enabled on my Seattle board.
> > > > >
> > > > > Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
> > > > > in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
> > > > > set to NULL by exit_mm I think). So do you think this could be a different problem ?
> > > > > I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
> > > > > (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
> > > > > points to a page which is "now" owned by slab.
> > > >
> > > > Having not been able to reproduce the failure you described, I can't give
> > > > you a good answer to this.
Looking at the code (again), if we context switch in do_exit after exit_mm,
then the thread behaves an awful lot like a kernel thread: current->mm is
NULL and we're in lazy TLB mode. Furthermore, that context switch will drop
the last reference to the old mm and the pgd will finally be freed.
So I think my patches will solve your case too because we'll call
enter_lazy_tlb again when getting scheduled back in. If you have any way
to test them, that would be great.
> > > While these fixes make sense for a stable backport, I could go back to
> > > per-cpu saved_ttbr0 as in the first version of this patchset:
> > >
> > > http://lkml.kernel.org/r/1471015666-23125-4-git-send-email-catalin.marinas at arm.com
> > >
> > > (changed in v2 for some marginally shorter asm code)
> >
> > To be honest, if we're going to consider changes as fundamental as that, I'd
> > much prefer for us to use the active_mm->pgd directly, setting the zero page
> > if it's either NULL or init_mm. This would need some hacking for EFI...
>
> The problem is the __pa(active_mm->pgd) and doing it in assembly may be
> pretty unreadable.
I don't think it would be *that* bad if you can get hold of memstart_addr.
> Yet another option is to move save_ttbr0 in mm_context_t.
Perhaps, but I don't dislike the current code as much as I did now that,
we understand it better ;)
Will
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Catalin Marinas @ 2017-12-06 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206180706.GB26554@arm.com>
On Wed, Dec 06, 2017 at 06:07:07PM +0000, Will Deacon wrote:
> On Wed, Dec 06, 2017 at 06:01:35PM +0000, Catalin Marinas wrote:
> > On Wed, Dec 06, 2017 at 05:56:42PM +0000, Will Deacon wrote:
> > > On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
> > > > On 12/6/2017 4:46 PM, Will Deacon wrote:
> > > > > After lots of collective head scratching in response to Vinayak's mail
> > > > > here:
> > > > >
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
> > > > >
> > > > > It turns out that we have a problem with SW PAN and kernel threads, where
> > > > > the saved ttbr0 value for a kernel thread can be stale and subsequently
> > > > > inherited by other kernel threads over a fork.
> > > > >
> > > > > These two patches attempt to fix that. We've not be able to reproduce
> > > > > the exact failure reported above, but I added some assertions to the
> > > > > uaccess routines to check for discrepancies between the active_mm pgd
> > > > > and the saved ttbr0 value (ignoring the zero page) and these no longer
> > > > > fire with these changes, but do fire without them if EFI runtime services
> > > > > are enabled on my Seattle board.
> > > >
> > > > Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
> > > > in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
> > > > set to NULL by exit_mm I think). So do you think this could be a different problem ?
> > > > I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
> > > > (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
> > > > points to a page which is "now" owned by slab.
> > >
> > > Having not been able to reproduce the failure you described, I can't give
> > > you a good answer to this.
> >
> > While these fixes make sense for a stable backport, I could go back to
> > per-cpu saved_ttbr0 as in the first version of this patchset:
> >
> > http://lkml.kernel.org/r/1471015666-23125-4-git-send-email-catalin.marinas at arm.com
> >
> > (changed in v2 for some marginally shorter asm code)
>
> To be honest, if we're going to consider changes as fundamental as that, I'd
> much prefer for us to use the active_mm->pgd directly, setting the zero page
> if it's either NULL or init_mm. This would need some hacking for EFI...
The problem is the __pa(active_mm->pgd) and doing it in assembly may be
pretty unreadable.
Yet another option is to move save_ttbr0 in mm_context_t.
--
Catalin
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Will Deacon @ 2017-12-06 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206180135.5zorlmaij45grg25@armageddon.cambridge.arm.com>
On Wed, Dec 06, 2017 at 06:01:35PM +0000, Catalin Marinas wrote:
> On Wed, Dec 06, 2017 at 05:56:42PM +0000, Will Deacon wrote:
> > On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
> > > On 12/6/2017 4:46 PM, Will Deacon wrote:
> > > > After lots of collective head scratching in response to Vinayak's mail
> > > > here:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
> > > >
> > > > It turns out that we have a problem with SW PAN and kernel threads, where
> > > > the saved ttbr0 value for a kernel thread can be stale and subsequently
> > > > inherited by other kernel threads over a fork.
> > > >
> > > > These two patches attempt to fix that. We've not be able to reproduce
> > > > the exact failure reported above, but I added some assertions to the
> > > > uaccess routines to check for discrepancies between the active_mm pgd
> > > > and the saved ttbr0 value (ignoring the zero page) and these no longer
> > > > fire with these changes, but do fire without them if EFI runtime services
> > > > are enabled on my Seattle board.
> > >
> > > Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
> > > in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
> > > set to NULL by exit_mm I think). So do you think this could be a different problem ?
> > > I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
> > > (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
> > > points to a page which is "now" owned by slab.
> >
> > Having not been able to reproduce the failure you described, I can't give
> > you a good answer to this.
>
> While these fixes make sense for a stable backport, I could go back to
> per-cpu saved_ttbr0 as in the first version of this patchset:
>
> http://lkml.kernel.org/r/1471015666-23125-4-git-send-email-catalin.marinas at arm.com
>
> (changed in v2 for some marginally shorter asm code)
To be honest, if we're going to consider changes as fundamental as that, I'd
much prefer for us to use the active_mm->pgd directly, setting the zero page
if it's either NULL or init_mm. This would need some hacking for EFI...
Will
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Catalin Marinas @ 2017-12-06 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206175641.GA26554@arm.com>
On Wed, Dec 06, 2017 at 05:56:42PM +0000, Will Deacon wrote:
> On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
> > On 12/6/2017 4:46 PM, Will Deacon wrote:
> > > After lots of collective head scratching in response to Vinayak's mail
> > > here:
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
> > >
> > > It turns out that we have a problem with SW PAN and kernel threads, where
> > > the saved ttbr0 value for a kernel thread can be stale and subsequently
> > > inherited by other kernel threads over a fork.
> > >
> > > These two patches attempt to fix that. We've not be able to reproduce
> > > the exact failure reported above, but I added some assertions to the
> > > uaccess routines to check for discrepancies between the active_mm pgd
> > > and the saved ttbr0 value (ignoring the zero page) and these no longer
> > > fire with these changes, but do fire without them if EFI runtime services
> > > are enabled on my Seattle board.
> >
> > Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
> > in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
> > set to NULL by exit_mm I think). So do you think this could be a different problem ?
> > I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
> > (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
> > points to a page which is "now" owned by slab.
>
> Having not been able to reproduce the failure you described, I can't give
> you a good answer to this.
While these fixes make sense for a stable backport, I could go back to
per-cpu saved_ttbr0 as in the first version of this patchset:
http://lkml.kernel.org/r/1471015666-23125-4-git-send-email-catalin.marinas at arm.com
(changed in v2 for some marginally shorter asm code)
--
Catalin
^ permalink raw reply
* [PATCH] spi: sun4i: disable clocks in the remove function
From: Takuo Koguchi @ 2017-12-06 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206152005.yfbyylu6tbe5gnnv@flea.lan>
mclk and hclk need to be disabled since pm_runtime_disable does
not disable the clocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Takuo Koguchi <takuo.koguchi.sw@hitachi.com>
---
V2: use pm_runtime_force_suspend to avoid unbalance disable
call.
Compile test only, no runtime test.
drivers/spi/spi-sun4i.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index c5cd635..ca733b2 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -525,6 +525,7 @@ static int sun4i_spi_probe(struct platform_device *pdev)
static int sun4i_spi_remove(struct platform_device *pdev)
{
+ pm_runtime_force_suspend(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Fixes for SW PAN
From: Will Deacon @ 2017-12-06 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ee0b1f1-c7fc-af92-2b34-4555e59d7a20@codeaurora.org>
On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
> On 12/6/2017 4:46 PM, Will Deacon wrote:
> > Hi all,
> >
> > After lots of collective head scratching in response to Vinayak's mail
> > here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
> >
> > It turns out that we have a problem with SW PAN and kernel threads, where
> > the saved ttbr0 value for a kernel thread can be stale and subsequently
> > inherited by other kernel threads over a fork.
> >
> > These two patches attempt to fix that. We've not be able to reproduce
> > the exact failure reported above, but I added some assertions to the
> > uaccess routines to check for discrepancies between the active_mm pgd
> > and the saved ttbr0 value (ignoring the zero page) and these no longer
> > fire with these changes, but do fire without them if EFI runtime services
> > are enabled on my Seattle board.
>
> Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
> in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
> set to NULL by exit_mm I think). So do you think this could be a different problem ?
> I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
> (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
> points to a page which is "now" owned by slab.
Having not been able to reproduce the failure you described, I can't give
you a good answer to this. How much information do you have about the task
that crashes?
Will
^ permalink raw reply
* [PATCH 0/2] 66AK2G: Add DT entry for UART1 and UART2
From: santosh.shilimkar at oracle.com @ 2017-12-06 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205064812.15758-1-vigneshr@ti.com>
On 12/4/17 10:48 PM, Vignesh R wrote:
> This series adds DT entry for the remaining two UART instances on 66AK2G
> SoC.
>
> Based on linux-next.
>
> Franklin S Cooper Jr (2):
> ARM: dts: keystone-k2g: Add UART 1 and 2 instances
> ARM: dts: keystone-k2g-evm: Enable UART 2
>
Applied !!
^ permalink raw reply
* [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-06 17:51 UTC (permalink / raw)
To: linux-arm-kernel
usb otg on bananapi-m64 has configured with USB-ID with PH9
and USB-DRVVBUS attached with dcdc1 regulatort.
Add support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 4a8d3f8..0c74d62 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -66,6 +66,10 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -136,6 +140,10 @@
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
@@ -259,6 +267,13 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
&usbphy {
+ usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ usb0_vbus-supply = <®_dcdc1>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: defconfig: enable MUSB HDRC along with Allwinner glue
From: Jagan Teki @ 2017-12-06 17:49 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner SoCs typically have a Mentor Graphics Inventra MUSB
dual role controller for USB OTG. This is need for verifying
gadget functions, so enable them by default.
Tested 'otg' mode with mass storage function.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6356c6d..78f669a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -429,6 +429,8 @@ CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_RENESAS_USBHS=m
CONFIG_USB_STORAGE=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_SUNXI=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/5] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Alexander Sverdlin @ 2017-12-06 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB15656E4944DE6CAC67D18B07D03D0@SN1PR0101MB1565.prod.exchangelabs.com>
Hello Hartley,
On 05/12/17 19:14, Hartley Sweeten wrote:
>> This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
>>
>> This patchset consists of following patches:
>>
>> - ts72xx.[c|h] cosmetic cleanup/improvement
>> - Rewrite ts72xx.c to be reusable by bk3
>> - The Liebherr's BK3 board has been added with re-using code of
>> ts72xx.c (detalied list of changes can be found in patch 6/6)
>>
>> This series applies on top of linux-next/master (next-20171130)
>>
>> Lukasz Majewski (5):
>> ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
>> ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
>> parameters
>> ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
>> ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
>> ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
>>
>> MAINTAINERS | 6 ++
>> arch/arm/mach-ep93xx/Kconfig | 7 ++
>> arch/arm/mach-ep93xx/ts72xx.c | 198 ++++++++++++++++++++++++++++++++++++++----
>> arch/arm/mach-ep93xx/ts72xx.h | 9 ++
>> arch/arm/tools/mach-types | 1 +
>> 5 files changed, 202 insertions(+), 19 deletions(-)
> Looks good.
>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
I can prepare pull request to Arnd, as we discussed previously, just
waited for your review.
Regards,
Alexander.
^ permalink raw reply
* [arm-platforms:kvm-arm64/haslr 10/20] arch/arm64/include/asm/kvm_mmu.h:104:27: error: macro "ALTERNATIVE_CB" requires 3 arguments, but only 1 given
From: kbuild test robot @ 2017-12-06 17:44 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/haslr
head: 983da603415991b6e7e7cd9b53cfa922bf052393
commit: e7f8236b93aede2dfe4c043ea6b8b149e17c30f8 [10/20] arm64: KVM: Dynamically patch the kernel/hyp VA mask
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e7f8236b93aede2dfe4c043ea6b8b149e17c30f8
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the arm-platforms/kvm-arm64/haslr HEAD 983da603415991b6e7e7cd9b53cfa922bf052393 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from arch/arm64/kvm/haslr.c:22:0:
arch/arm64/include/asm/kvm_mmu.h: In function '__kern_hyp_va':
>> arch/arm64/include/asm/kvm_mmu.h:104:27: error: macro "ALTERNATIVE_CB" requires 3 arguments, but only 1 given
kvm_update_va_mask)
^
>> arch/arm64/include/asm/kvm_mmu.h:103:15: error: expected string literal before 'ALTERNATIVE_CB'
asm volatile(ALTERNATIVE_CB("and %0, %0, #1\n"
^~~~~~~~~~~~~~
vim +/ALTERNATIVE_CB +104 arch/arm64/include/asm/kvm_mmu.h
100
101 static inline unsigned long __kern_hyp_va(unsigned long v)
102 {
> 103 asm volatile(ALTERNATIVE_CB("and %0, %0, #1\n"
> 104 kvm_update_va_mask)
105 : "+r" (v));
106 return v;
107 }
108
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37460 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171207/e5e2c2f1/attachment-0001.gz>
^ permalink raw reply
* [RFC PATCH 0/5] perf events patches for improved ARM64 support
From: John Garry @ 2017-12-06 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12034446-ccc9-9a88-6b2c-3318216f4817@redhat.com>
On 06/12/2017 16:42, William Cohen wrote:
> On 12/05/2017 11:13 AM, John Garry wrote:
>> This patchset adds support for some perf events features,
>> targeted at ARM64, implemented in a generic fashion.
>>
>> The two main features are as follows:
>> - support for arch/vendor/platform pmu events directory structure
>> - support for parsing architecture recommended pmu events
>>
>> On the back of these, the Cavium ThunderX2 and HiSilicon hip08
>> JSONs are relocated/added.
>>
>> TODO:
>> - Documentation needs to be updated for recommended
>> events format in the JSON
>> - tidy up patches a bit
>>
>> John Garry (5):
>> perf jevents: add support for pmu events vendor subdirectory
>> perf jevents: add support for arch recommended events
>> perf vendor events arm64: add armv8 recommended events JSON
>> perf vendor events arm64: relocate thunderx2 JSON
>> perf vendor events arm64: add HiSilicon hip08 JSON
>>
>> .../pmu-events/arch/arm64/armv8-recommended.json | 452 +++++++++++++++++++++
>> .../arch/arm64/cavium/thunderx2-imp-def.json | 62 ---
>> .../arch/arm64/cavium/thunderx2/core-imp-def.json | 32 ++
>> .../arch/arm64/hisilicon/hip08/core-imp-def.json | 122 ++++++
>> tools/perf/pmu-events/arch/arm64/mapfile.csv | 3 +-
>> tools/perf/pmu-events/jevents.c | 272 ++++++++++++-
>> 6 files changed, 859 insertions(+), 84 deletions(-)
>> create mode 100644 tools/perf/pmu-events/arch/arm64/armv8-recommended.json
>> delete mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json
>> create mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json
>> create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json
>>
>
>
> Hi,
>
> How is this code dealing with the possible different configurations within the aach64 architecture? For example the Cortex-A53 implementations may exclude the L2 cache and not have L2 cache events implemented? Is there some way that perf could make use of the PMCEID0 and PMCEID1 register information to accurately get the subset of events the processor supports? Using this information could eliminate a lot of busy work adding implementation specific descriptions due to slight implementation differences.
>
Hi Will,
Thanks for the input.
So today the PMCEID registers are used in the kernel to detect whether
common architectural/microarchitectual events are implemented.
Here, in this patchset (specifically 2/5 onwards), we are trying to deal
with the Recommended (IMPLEMENTATION DEFINED)
architectural/microarchitectual events.
Cheers,
John
> -Will Cohen
>
> .
>
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Vinayak Menon @ 2017-12-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512558968-28980-1-git-send-email-will.deacon@arm.com>
On 12/6/2017 4:46 PM, Will Deacon wrote:
> Hi all,
>
> After lots of collective head scratching in response to Vinayak's mail
> here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
>
> It turns out that we have a problem with SW PAN and kernel threads, where
> the saved ttbr0 value for a kernel thread can be stale and subsequently
> inherited by other kernel threads over a fork.
>
> These two patches attempt to fix that. We've not be able to reproduce
> the exact failure reported above, but I added some assertions to the
> uaccess routines to check for discrepancies between the active_mm pgd
> and the saved ttbr0 value (ignoring the zero page) and these no longer
> fire with these changes, but do fire without them if EFI runtime services
> are enabled on my Seattle board.
Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
set to NULL by exit_mm I think). So do you think this could be a different problem ?
I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
(from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
points to a page which is "now" owned by slab.
>
> Cheers,
>
> Will
>
> --->8
>
> Will Deacon (2):
> arm64: SW PAN: Point saved ttbr0 at the zero page when switching to
> init_mm
> arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb
>
> arch/arm64/include/asm/efi.h | 4 +---
> arch/arm64/include/asm/mmu_context.h | 46 ++++++++++++++++++------------------
> 2 files changed, 24 insertions(+), 26 deletions(-)
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Brian Norris @ 2017-12-06 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111008.3079-3-enric.balletbo@collabora.com>
+ Alex, Jeffy, Frank Wang
Hi,
On Wed, Dec 06, 2017 at 12:10:08PM +0100, Enric Balletbo i Serra wrote:
> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> index 470105d..03f1950 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> @@ -855,6 +855,20 @@ ap_i2c_audio: &i2c8 {
> compatible = "google,cros-ec-pwm";
> #pwm-cells = <1>;
> };
> +
> + usbc_extcon0: extcon at 0 {
> + compatible = "google,extcon-usbc-cros-ec";
> + google,usb-port-id = <0>;
> +
> + #extcon-cells = <0>;
> + };
> +
> + usbc_extcon1: extcon at 1 {
> + compatible = "google,extcon-usbc-cros-ec";
> + google,usb-port-id = <1>;
> +
> + #extcon-cells = <0>;
> + };
> };
> };
>
> @@ -865,6 +879,16 @@ ap_i2c_audio: &i2c8 {
> rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> };
>
> +&tcphy0 {
> + status = "okay";
> + extcon = <&usbc_extcon0>;
> +};
> +
> +&tcphy1 {
> + status = "okay";
> + extcon = <&usbc_extcon1>;
> +};
> +
> &u2phy0 {
> status = "okay";
> };
> @@ -911,6 +935,7 @@ ap_i2c_audio: &i2c8 {
>
> &usbdrd3_0 {
> status = "okay";
> + extcon = <&usbc_extcon0>;
> };
>
> &usbdrd_dwc3_0 {
> @@ -920,6 +945,7 @@ ap_i2c_audio: &i2c8 {
>
> &usbdrd3_1 {
> status = "okay";
> + extcon = <&usbc_extcon1>;
> };
>
> &usbdrd_dwc3_1 {
Seems OK.
Also, IIUC, I think if we ever want to support dual-role/OTG, we need an
extcon reference in the USB2/OTG PHY that serves these ports too. i.e.,
u2phy0 and u2phy1? Notably, the PHY driver supports the extcon
properties, but it's not documented in
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt yet (we
should probably get that fixed).
So, anyway, maybe the above isn't a blocker for this patch. Just noticed
it while reading. Assuming the driver stuff falls into place:
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* [PATCH] arm64: kvm: Prevent restoring stale PMSCR_EL1 for vcpu
From: Will Deacon @ 2017-12-06 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512580189-5921-1-git-send-email-julien.thierry@arm.com>
On Wed, Dec 06, 2017 at 05:09:49PM +0000, Julien Thierry wrote:
> When VHE is not present, KVM needs to save and restores PMSCR_EL1 when
> possible. If SPE is used by the host, value of PMSCR_EL1 cannot be saved
> for the guest.
> If the host starts using SPE between two save+restore on the same vcpu,
> restore will write the value of PMSCR_EL1 read during the first save.
>
> Make sure __debug_save_spe_nvhe clears the value of the saved PMSCR_EL1
> when the guest cannot use SPE.
Ok, so the problem is that we have a stale (non-zero) saved pmscr_el1,
and therefore the restore code unconditionally restores that even though
SPE is no longer in use by the host. Well spotted!
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: <stable@vger.kernel.org>
> ---
> arch/arm64/kvm/hyp/debug-sr.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] net: ethernet: arc: fix error handling in emac_rockchip_probe
From: Branislav Radocaj @ 2017-12-06 17:24 UTC (permalink / raw)
To: linux-arm-kernel
If clk_set_rate() fails, we should disable clk
before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index e278e3d96ee0..c6163874e4e7 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -220,9 +220,11 @@ static int emac_rockchip_probe(struct platform_device *pdev)
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 25000000);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+ goto out_clk_disable_macclk;
+ }
}
err = arc_emac_probe(ndev, interface);
@@ -232,7 +234,8 @@ static int emac_rockchip_probe(struct platform_device *pdev)
}
return 0;
-
+out_clk_disable_macclk:
+ clk_disable_unprepare(priv->macclk);
out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox