* Re: [PATCH v1 17/55] KVM: PPC: Book3S HV P9: Implement PMU save/restore in C
From: Athira Rajeev @ 2021-08-09 3:03 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20210726035036.739609-18-npiggin@gmail.com>
> On 26-Jul-2021, at 9:19 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Implement the P9 path PMU save/restore code in C, and remove the
> POWER9/10 code from the P7/8 path assembly.
>
> -449 cycles (8533) POWER9 virt-mode NULL hcall
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/asm-prototypes.h | 5 -
> arch/powerpc/kvm/book3s_hv.c | 205 ++++++++++++++++++++--
> arch/powerpc/kvm/book3s_hv_interrupts.S | 13 +-
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 43 +----
> 4 files changed, 200 insertions(+), 66 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
> index 222823861a67..41b8a1e1144a 100644
> --- a/arch/powerpc/include/asm/asm-prototypes.h
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -141,11 +141,6 @@ static inline void kvmppc_restore_tm_hv(struct kvm_vcpu *vcpu, u64 msr,
> bool preserve_nv) { }
> #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
>
> -void kvmhv_save_host_pmu(void);
> -void kvmhv_load_host_pmu(void);
> -void kvmhv_save_guest_pmu(struct kvm_vcpu *vcpu, bool pmu_in_use);
> -void kvmhv_load_guest_pmu(struct kvm_vcpu *vcpu);
> -
> void kvmppc_p9_enter_guest(struct kvm_vcpu *vcpu);
>
> long kvmppc_h_set_dabr(struct kvm_vcpu *vcpu, unsigned long dabr);
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 2eef708c4354..d20b579ddcdf 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -3735,6 +3735,188 @@ static noinline void kvmppc_run_core(struct kvmppc_vcore *vc)
> trace_kvmppc_run_core(vc, 1);
> }
>
> +/*
> + * Privileged (non-hypervisor) host registers to save.
> + */
> +struct p9_host_os_sprs {
> + unsigned long dscr;
> + unsigned long tidr;
> + unsigned long iamr;
> + unsigned long amr;
> + unsigned long fscr;
> +
> + unsigned int pmc1;
> + unsigned int pmc2;
> + unsigned int pmc3;
> + unsigned int pmc4;
> + unsigned int pmc5;
> + unsigned int pmc6;
> + unsigned long mmcr0;
> + unsigned long mmcr1;
> + unsigned long mmcr2;
> + unsigned long mmcr3;
> + unsigned long mmcra;
> + unsigned long siar;
> + unsigned long sier1;
> + unsigned long sier2;
> + unsigned long sier3;
> + unsigned long sdar;
> +};
> +
> +static void freeze_pmu(unsigned long mmcr0, unsigned long mmcra)
> +{
> + if (!(mmcr0 & MMCR0_FC))
> + goto do_freeze;
> + if (mmcra & MMCRA_SAMPLE_ENABLE)
> + goto do_freeze;
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + if (!(mmcr0 & MMCR0_PMCCEXT))
> + goto do_freeze;
> + if (!(mmcra & MMCRA_BHRB_DISABLE))
> + goto do_freeze;
> + }
> + return;
> +
> +do_freeze:
> + mmcr0 = MMCR0_FC;
> + mmcra = 0;
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + mmcr0 |= MMCR0_PMCCEXT;
> + mmcra = MMCRA_BHRB_DISABLE;
> + }
> +
> + mtspr(SPRN_MMCR0, mmcr0);
> + mtspr(SPRN_MMCRA, mmcra);
> + isync();
> +}
> +
Hi Nick,
After feezing pmu, do we need to clear “pmcregs_in_use” as well?
Also can’t we unconditionally do the MMCR0/MMCRA/ freeze settings in here ? do we need the if conditions for FC/PMCCEXT/BHRB ?
Thanks
Athira
> +static void save_p9_host_pmu(struct p9_host_os_sprs *host_os_sprs)
> +{
> + if (ppc_get_pmu_inuse()) {
> + /*
> + * It might be better to put PMU handling (at least for the
> + * host) in the perf subsystem because it knows more about what
> + * is being used.
> + */
> +
> + /* POWER9, POWER10 do not implement HPMC or SPMC */
> +
> + host_os_sprs->mmcr0 = mfspr(SPRN_MMCR0);
> + host_os_sprs->mmcra = mfspr(SPRN_MMCRA);
> +
> + freeze_pmu(host_os_sprs->mmcr0, host_os_sprs->mmcra);
> +
> + host_os_sprs->pmc1 = mfspr(SPRN_PMC1);
> + host_os_sprs->pmc2 = mfspr(SPRN_PMC2);
> + host_os_sprs->pmc3 = mfspr(SPRN_PMC3);
> + host_os_sprs->pmc4 = mfspr(SPRN_PMC4);
> + host_os_sprs->pmc5 = mfspr(SPRN_PMC5);
> + host_os_sprs->pmc6 = mfspr(SPRN_PMC6);
> + host_os_sprs->mmcr1 = mfspr(SPRN_MMCR1);
> + host_os_sprs->mmcr2 = mfspr(SPRN_MMCR2);
> + host_os_sprs->sdar = mfspr(SPRN_SDAR);
> + host_os_sprs->siar = mfspr(SPRN_SIAR);
> + host_os_sprs->sier1 = mfspr(SPRN_SIER);
> +
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + host_os_sprs->mmcr3 = mfspr(SPRN_MMCR3);
> + host_os_sprs->sier2 = mfspr(SPRN_SIER2);
> + host_os_sprs->sier3 = mfspr(SPRN_SIER3);
> + }
> + }
> +}
> +
> +static void load_p9_guest_pmu(struct kvm_vcpu *vcpu)
> +{
> + mtspr(SPRN_PMC1, vcpu->arch.pmc[0]);
> + mtspr(SPRN_PMC2, vcpu->arch.pmc[1]);
> + mtspr(SPRN_PMC3, vcpu->arch.pmc[2]);
> + mtspr(SPRN_PMC4, vcpu->arch.pmc[3]);
> + mtspr(SPRN_PMC5, vcpu->arch.pmc[4]);
> + mtspr(SPRN_PMC6, vcpu->arch.pmc[5]);
> + mtspr(SPRN_MMCR1, vcpu->arch.mmcr[1]);
> + mtspr(SPRN_MMCR2, vcpu->arch.mmcr[2]);
> + mtspr(SPRN_SDAR, vcpu->arch.sdar);
> + mtspr(SPRN_SIAR, vcpu->arch.siar);
> + mtspr(SPRN_SIER, vcpu->arch.sier[0]);
> +
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + mtspr(SPRN_MMCR3, vcpu->arch.mmcr[3]);
> + mtspr(SPRN_SIER2, vcpu->arch.sier[1]);
> + mtspr(SPRN_SIER3, vcpu->arch.sier[2]);
> + }
> +
> + /* Set MMCRA then MMCR0 last */
> + mtspr(SPRN_MMCRA, vcpu->arch.mmcra);
> + mtspr(SPRN_MMCR0, vcpu->arch.mmcr[0]);
> + /* No isync necessary because we're starting counters */
> +}
> +
> +static void save_p9_guest_pmu(struct kvm_vcpu *vcpu)
> +{
> + struct lppaca *lp;
> + int save_pmu = 1;
> +
> + lp = vcpu->arch.vpa.pinned_addr;
> + if (lp)
> + save_pmu = lp->pmcregs_in_use;
> +
> + if (save_pmu) {
> + vcpu->arch.mmcr[0] = mfspr(SPRN_MMCR0);
> + vcpu->arch.mmcra = mfspr(SPRN_MMCRA);
> +
> + freeze_pmu(vcpu->arch.mmcr[0], vcpu->arch.mmcra);
> +
> + vcpu->arch.pmc[0] = mfspr(SPRN_PMC1);
> + vcpu->arch.pmc[1] = mfspr(SPRN_PMC2);
> + vcpu->arch.pmc[2] = mfspr(SPRN_PMC3);
> + vcpu->arch.pmc[3] = mfspr(SPRN_PMC4);
> + vcpu->arch.pmc[4] = mfspr(SPRN_PMC5);
> + vcpu->arch.pmc[5] = mfspr(SPRN_PMC6);
> + vcpu->arch.mmcr[1] = mfspr(SPRN_MMCR1);
> + vcpu->arch.mmcr[2] = mfspr(SPRN_MMCR2);
> + vcpu->arch.sdar = mfspr(SPRN_SDAR);
> + vcpu->arch.siar = mfspr(SPRN_SIAR);
> + vcpu->arch.sier[0] = mfspr(SPRN_SIER);
> +
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + vcpu->arch.mmcr[3] = mfspr(SPRN_MMCR3);
> + vcpu->arch.sier[1] = mfspr(SPRN_SIER2);
> + vcpu->arch.sier[2] = mfspr(SPRN_SIER3);
> + }
> + } else {
> + freeze_pmu(mfspr(SPRN_MMCR0), mfspr(SPRN_MMCRA));
> + }
> +}
> +
> +static void load_p9_host_pmu(struct p9_host_os_sprs *host_os_sprs)
> +{
> + if (ppc_get_pmu_inuse()) {
> + mtspr(SPRN_PMC1, host_os_sprs->pmc1);
> + mtspr(SPRN_PMC2, host_os_sprs->pmc2);
> + mtspr(SPRN_PMC3, host_os_sprs->pmc3);
> + mtspr(SPRN_PMC4, host_os_sprs->pmc4);
> + mtspr(SPRN_PMC5, host_os_sprs->pmc5);
> + mtspr(SPRN_PMC6, host_os_sprs->pmc6);
> + mtspr(SPRN_MMCR1, host_os_sprs->mmcr1);
> + mtspr(SPRN_MMCR2, host_os_sprs->mmcr2);
> + mtspr(SPRN_SDAR, host_os_sprs->sdar);
> + mtspr(SPRN_SIAR, host_os_sprs->siar);
> + mtspr(SPRN_SIER, host_os_sprs->sier1);
> +
> + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> + mtspr(SPRN_MMCR3, host_os_sprs->mmcr3);
> + mtspr(SPRN_SIER2, host_os_sprs->sier2);
> + mtspr(SPRN_SIER3, host_os_sprs->sier3);
> + }
> +
> + /* Set MMCRA then MMCR0 last */
> + mtspr(SPRN_MMCRA, host_os_sprs->mmcra);
> + mtspr(SPRN_MMCR0, host_os_sprs->mmcr0);
> + isync();
> + }
> +}
> +
> static void load_spr_state(struct kvm_vcpu *vcpu)
> {
> mtspr(SPRN_DSCR, vcpu->arch.dscr);
> @@ -3777,17 +3959,6 @@ static void store_spr_state(struct kvm_vcpu *vcpu)
> vcpu->arch.dscr = mfspr(SPRN_DSCR);
> }
>
> -/*
> - * Privileged (non-hypervisor) host registers to save.
> - */
> -struct p9_host_os_sprs {
> - unsigned long dscr;
> - unsigned long tidr;
> - unsigned long iamr;
> - unsigned long amr;
> - unsigned long fscr;
> -};
> -
> static void save_p9_host_os_sprs(struct p9_host_os_sprs *host_os_sprs)
> {
> host_os_sprs->dscr = mfspr(SPRN_DSCR);
> @@ -3835,7 +4006,7 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
> struct p9_host_os_sprs host_os_sprs;
> s64 dec;
> u64 tb, next_timer;
> - int trap, save_pmu;
> + int trap;
>
> WARN_ON_ONCE(vcpu->arch.ceded);
>
> @@ -3848,7 +4019,7 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
>
> save_p9_host_os_sprs(&host_os_sprs);
>
> - kvmhv_save_host_pmu(); /* saves it to PACA kvm_hstate */
> + save_p9_host_pmu(&host_os_sprs);
>
> kvmppc_subcore_enter_guest();
>
> @@ -3878,7 +4049,7 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
> barrier();
> }
> #endif
> - kvmhv_load_guest_pmu(vcpu);
> + load_p9_guest_pmu(vcpu);
>
> msr_check_and_set(MSR_FP | MSR_VEC | MSR_VSX);
> load_fp_state(&vcpu->arch.fp);
> @@ -4000,16 +4171,14 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
> cpu_has_feature(CPU_FTR_P9_TM_HV_ASSIST))
> kvmppc_save_tm_hv(vcpu, vcpu->arch.shregs.msr, true);
>
> - save_pmu = 1;
> if (vcpu->arch.vpa.pinned_addr) {
> struct lppaca *lp = vcpu->arch.vpa.pinned_addr;
> u32 yield_count = be32_to_cpu(lp->yield_count) + 1;
> lp->yield_count = cpu_to_be32(yield_count);
> vcpu->arch.vpa.dirty = 1;
> - save_pmu = lp->pmcregs_in_use;
> }
>
> - kvmhv_save_guest_pmu(vcpu, save_pmu);
> + save_p9_guest_pmu(vcpu);
> #ifdef CONFIG_PPC_PSERIES
> if (kvmhv_on_pseries()) {
> barrier();
> @@ -4025,7 +4194,7 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
>
> mtspr(SPRN_SPRG_VDSO_WRITE, local_paca->sprg_vdso);
>
> - kvmhv_load_host_pmu();
> + load_p9_host_pmu(&host_os_sprs);
>
> kvmppc_subcore_exit_guest();
>
> diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S
> index 4444f83cb133..59d89e4b154a 100644
> --- a/arch/powerpc/kvm/book3s_hv_interrupts.S
> +++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
> @@ -104,7 +104,10 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
> mtlr r0
> blr
>
> -_GLOBAL(kvmhv_save_host_pmu)
> +/*
> + * void kvmhv_save_host_pmu(void)
> + */
> +kvmhv_save_host_pmu:
> BEGIN_FTR_SECTION
> /* Work around P8 PMAE bug */
> li r3, -1
> @@ -138,14 +141,6 @@ BEGIN_FTR_SECTION
> std r8, HSTATE_MMCR2(r13)
> std r9, HSTATE_SIER(r13)
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> -BEGIN_FTR_SECTION
> - mfspr r5, SPRN_MMCR3
> - mfspr r6, SPRN_SIER2
> - mfspr r7, SPRN_SIER3
> - std r5, HSTATE_MMCR3(r13)
> - std r6, HSTATE_SIER2(r13)
> - std r7, HSTATE_SIER3(r13)
> -END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
> mfspr r3, SPRN_PMC1
> mfspr r5, SPRN_PMC2
> mfspr r6, SPRN_PMC3
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 9021052f1579..551ce223b40c 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -2738,10 +2738,11 @@ kvmppc_msr_interrupt:
> blr
>
> /*
> + * void kvmhv_load_guest_pmu(struct kvm_vcpu *vcpu)
> + *
> * Load up guest PMU state. R3 points to the vcpu struct.
> */
> -_GLOBAL(kvmhv_load_guest_pmu)
> -EXPORT_SYMBOL_GPL(kvmhv_load_guest_pmu)
> +kvmhv_load_guest_pmu:
> mr r4, r3
> mflr r0
> li r3, 1
> @@ -2775,27 +2776,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_PMAO_BUG)
> mtspr SPRN_MMCRA, r6
> mtspr SPRN_SIAR, r7
> mtspr SPRN_SDAR, r8
> -BEGIN_FTR_SECTION
> - ld r5, VCPU_MMCR + 24(r4)
> - ld r6, VCPU_SIER + 8(r4)
> - ld r7, VCPU_SIER + 16(r4)
> - mtspr SPRN_MMCR3, r5
> - mtspr SPRN_SIER2, r6
> - mtspr SPRN_SIER3, r7
> -END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
> BEGIN_FTR_SECTION
> ld r5, VCPU_MMCR + 16(r4)
> ld r6, VCPU_SIER(r4)
> mtspr SPRN_MMCR2, r5
> mtspr SPRN_SIER, r6
> -BEGIN_FTR_SECTION_NESTED(96)
> lwz r7, VCPU_PMC + 24(r4)
> lwz r8, VCPU_PMC + 28(r4)
> ld r9, VCPU_MMCRS(r4)
> mtspr SPRN_SPMC1, r7
> mtspr SPRN_SPMC2, r8
> mtspr SPRN_MMCRS, r9
> -END_FTR_SECTION_NESTED(CPU_FTR_ARCH_300, 0, 96)
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> mtspr SPRN_MMCR0, r3
> isync
> @@ -2803,10 +2794,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> blr
>
> /*
> + * void kvmhv_load_host_pmu(void)
> + *
> * Reload host PMU state saved in the PACA by kvmhv_save_host_pmu.
> */
> -_GLOBAL(kvmhv_load_host_pmu)
> -EXPORT_SYMBOL_GPL(kvmhv_load_host_pmu)
> +kvmhv_load_host_pmu:
> mflr r0
> lbz r4, PACA_PMCINUSE(r13) /* is the host using the PMU? */
> cmpwi r4, 0
> @@ -2844,25 +2836,18 @@ BEGIN_FTR_SECTION
> mtspr SPRN_MMCR2, r8
> mtspr SPRN_SIER, r9
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> -BEGIN_FTR_SECTION
> - ld r5, HSTATE_MMCR3(r13)
> - ld r6, HSTATE_SIER2(r13)
> - ld r7, HSTATE_SIER3(r13)
> - mtspr SPRN_MMCR3, r5
> - mtspr SPRN_SIER2, r6
> - mtspr SPRN_SIER3, r7
> -END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
> mtspr SPRN_MMCR0, r3
> isync
> mtlr r0
> 23: blr
>
> /*
> + * void kvmhv_save_guest_pmu(struct kvm_vcpu *vcpu, bool pmu_in_use)
> + *
> * Save guest PMU state into the vcpu struct.
> * r3 = vcpu, r4 = full save flag (PMU in use flag set in VPA)
> */
> -_GLOBAL(kvmhv_save_guest_pmu)
> -EXPORT_SYMBOL_GPL(kvmhv_save_guest_pmu)
> +kvmhv_save_guest_pmu:
> mr r9, r3
> mr r8, r4
> BEGIN_FTR_SECTION
> @@ -2911,14 +2896,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> BEGIN_FTR_SECTION
> std r10, VCPU_MMCR + 16(r9)
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> -BEGIN_FTR_SECTION
> - mfspr r5, SPRN_MMCR3
> - mfspr r6, SPRN_SIER2
> - mfspr r7, SPRN_SIER3
> - std r5, VCPU_MMCR + 24(r9)
> - std r6, VCPU_SIER + 8(r9)
> - std r7, VCPU_SIER + 16(r9)
> -END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
> std r7, VCPU_SIAR(r9)
> std r8, VCPU_SDAR(r9)
> mfspr r3, SPRN_PMC1
> @@ -2936,7 +2913,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
> BEGIN_FTR_SECTION
> mfspr r5, SPRN_SIER
> std r5, VCPU_SIER(r9)
> -BEGIN_FTR_SECTION_NESTED(96)
> mfspr r6, SPRN_SPMC1
> mfspr r7, SPRN_SPMC2
> mfspr r8, SPRN_MMCRS
> @@ -2945,7 +2921,6 @@ BEGIN_FTR_SECTION_NESTED(96)
> std r8, VCPU_MMCRS(r9)
> lis r4, 0x8000
> mtspr SPRN_MMCRS, r4
> -END_FTR_SECTION_NESTED(CPU_FTR_ARCH_300, 0, 96)
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> 22: blr
>
> --
> 2.23.0
>
^ permalink raw reply
* [PATCH v2] powerpc/kprobes: Fix kprobe Oops happens in booke
From: Pu Lehui @ 2021-08-09 2:36 UTC (permalink / raw)
To: mpe, benh, paulus, naveen.n.rao, mhiramat, peterz,
christophe.leroy, npiggin, ruscur
Cc: zhangjinhao2, linuxppc-dev, linux-kernel, pulehui
When using kprobe on powerpc booke series processor, Oops happens
as show bellow:
/ # echo "p:myprobe do_nanosleep" > /sys/kernel/debug/tracing/kprobe_events
/ # echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
/ # sleep 1
[ 50.076730] Oops: Exception in kernel mode, sig: 5 [#1]
[ 50.077017] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
[ 50.077221] Modules linked in:
[ 50.077462] CPU: 0 PID: 77 Comm: sleep Not tainted 5.14.0-rc4-00022-g251a1524293d #21
[ 50.077887] NIP: c0b9c4e0 LR: c00ebecc CTR: 00000000
[ 50.078067] REGS: c3883de0 TRAP: 0700 Not tainted (5.14.0-rc4-00022-g251a1524293d)
[ 50.078349] MSR: 00029000 <CE,EE,ME> CR: 24000228 XER: 20000000
[ 50.078675]
[ 50.078675] GPR00: c00ebdf0 c3883e90 c313e300 c3883ea0 00000001 00000000 c3883ecc 00000001
[ 50.078675] GPR08: c100598c c00ea250 00000004 00000000 24000222 102490c2 bff4180c 101e60d4
[ 50.078675] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f8 10240000 00500000
[ 50.078675] GPR24: 00000002 00000000 c3883ea0 00000001 00000000 0000c350 3b9b8d50 00000000
[ 50.080151] NIP [c0b9c4e0] do_nanosleep+0x0/0x190
[ 50.080352] LR [c00ebecc] hrtimer_nanosleep+0x14c/0x1e0
[ 50.080638] Call Trace:
[ 50.080801] [c3883e90] [c00ebdf0] hrtimer_nanosleep+0x70/0x1e0 (unreliable)
[ 50.081110] [c3883f00] [c00ec004] sys_nanosleep_time32+0xa4/0x110
[ 50.081336] [c3883f40] [c001509c] ret_from_syscall+0x0/0x28
[ 50.081541] --- interrupt: c00 at 0x100a4d08
[ 50.081749] NIP: 100a4d08 LR: 101b5234 CTR: 00000003
[ 50.081931] REGS: c3883f50 TRAP: 0c00 Not tainted (5.14.0-rc4-00022-g251a1524293d)
[ 50.082183] MSR: 0002f902 <CE,EE,PR,FP,ME> CR: 24000222 XER: 00000000
[ 50.082457]
[ 50.082457] GPR00: 000000a2 bf980040 1024b4d0 bf980084 bf980084 64000000 00555345 fefefeff
[ 50.082457] GPR08: 7f7f7f7f 101e0000 00000069 00000003 28000422 102490c2 bff4180c 101e60d4
[ 50.082457] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f8 10240000 00500000
[ 50.082457] GPR24: 00000002 bf9803f4 10240000 00000000 00000000 100039e0 00000000 102444e8
[ 50.083789] NIP [100a4d08] 0x100a4d08
[ 50.083917] LR [101b5234] 0x101b5234
[ 50.084042] --- interrupt: c00
[ 50.084238] Instruction dump:
[ 50.084483] 4bfffc40 60000000 60000000 60000000 9421fff0 39400402 914200c0 38210010
[ 50.084841] 4bfffc20 00000000 00000000 00000000 <7fe00008> 7c0802a6 7c892378 93c10048
[ 50.085487] ---[ end trace f6fffe98e2fa8f3e ]---
[ 50.085678]
Trace/breakpoint trap
There is no real mode for booke arch and the MMU translation is
always on. The corresponding MSR_IS/MSR_DS bit in booke is used
to switch the address space, but not for real mode judgment.
Fixes: 21f8b2fa3ca5 ("powerpc/kprobes: Ignore traps that happened in real mode")
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v1->v2:
- use IS_ENABLED(CONFIG_BOOKE) as suggested by Michael Ellerman and
Christophe Leroy
- update Oops log to make problem clear
arch/powerpc/kernel/kprobes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index cbc28d1a2e1b..7a7cd6bda53e 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -292,7 +292,8 @@ int kprobe_handler(struct pt_regs *regs)
if (user_mode(regs))
return 0;
- if (!(regs->msr & MSR_IR) || !(regs->msr & MSR_DR))
+ if (!IS_ENABLED(CONFIG_BOOKE) &&
+ (!(regs->msr & MSR_IR) || !(regs->msr & MSR_DR)))
return 0;
/*
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 00/11] Implement generic prot_guest_has() helper function
From: Kuppuswamy, Sathyanarayanan @ 2021-08-09 1:41 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel, x86, linuxppc-dev, linux-s390, iommu,
kvm, linux-efi, platform-driver-x86, linux-graphics-maintainer,
amd-gfx, dri-devel, kexec, linux-fsdevel
Cc: Brijesh Singh, David Airlie, Dave Hansen, Paul Mackerras,
Will Deacon, Ard Biesheuvel, Andi Kleen, Baoquan He, Joerg Roedel,
Christian Borntraeger, Ingo Molnar, Dave Young, Tianyu Lan,
Thomas Zimmermann, Vasily Gorbik, Heiko Carstens,
Maarten Lankhorst, Maxime Ripard, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, Peter Zijlstra, Daniel Vetter
In-Reply-To: <cover.1627424773.git.thomas.lendacky@amd.com>
Hi Tom,
On 7/27/21 3:26 PM, Tom Lendacky wrote:
> This patch series provides a generic helper function, prot_guest_has(),
> to replace the sme_active(), sev_active(), sev_es_active() and
> mem_encrypt_active() functions.
>
> It is expected that as new protected virtualization technologies are
> added to the kernel, they can all be covered by a single function call
> instead of a collection of specific function calls all called from the
> same locations.
>
> The powerpc and s390 patches have been compile tested only. Can the
> folks copied on this series verify that nothing breaks for them.
With this patch set, select ARCH_HAS_PROTECTED_GUEST and set
CONFIG_AMD_MEM_ENCRYPT=n, creates following error.
ld: arch/x86/mm/ioremap.o: in function `early_memremap_is_setup_data':
arch/x86/mm/ioremap.c:672: undefined reference to `early_memremap_decrypted'
It looks like early_memremap_is_setup_data() is not protected with
appropriate config.
>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Will Deacon <will@kernel.org>
>
> ---
>
> Patches based on:
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
> commit 79e920060fa7 ("Merge branch 'WIP/fixes'")
>
> Tom Lendacky (11):
> mm: Introduce a function to check for virtualization protection
> features
> x86/sev: Add an x86 version of prot_guest_has()
> powerpc/pseries/svm: Add a powerpc version of prot_guest_has()
> x86/sme: Replace occurrences of sme_active() with prot_guest_has()
> x86/sev: Replace occurrences of sev_active() with prot_guest_has()
> x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()
> treewide: Replace the use of mem_encrypt_active() with
> prot_guest_has()
> mm: Remove the now unused mem_encrypt_active() function
> x86/sev: Remove the now unused mem_encrypt_active() function
> powerpc/pseries/svm: Remove the now unused mem_encrypt_active()
> function
> s390/mm: Remove the now unused mem_encrypt_active() function
>
> arch/Kconfig | 3 ++
> arch/powerpc/include/asm/mem_encrypt.h | 5 --
> arch/powerpc/include/asm/protected_guest.h | 30 +++++++++++
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> arch/s390/include/asm/mem_encrypt.h | 2 -
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/kexec.h | 2 +-
> arch/x86/include/asm/mem_encrypt.h | 13 +----
> arch/x86/include/asm/protected_guest.h | 27 ++++++++++
> arch/x86/kernel/crash_dump_64.c | 4 +-
> arch/x86/kernel/head64.c | 4 +-
> arch/x86/kernel/kvm.c | 3 +-
> arch/x86/kernel/kvmclock.c | 4 +-
> arch/x86/kernel/machine_kexec_64.c | 19 +++----
> arch/x86/kernel/pci-swiotlb.c | 9 ++--
> arch/x86/kernel/relocate_kernel_64.S | 2 +-
> arch/x86/kernel/sev.c | 6 +--
> arch/x86/kvm/svm/svm.c | 3 +-
> arch/x86/mm/ioremap.c | 16 +++---
> arch/x86/mm/mem_encrypt.c | 60 +++++++++++++++-------
> arch/x86/mm/mem_encrypt_identity.c | 3 +-
> arch/x86/mm/pat/set_memory.c | 3 +-
> arch/x86/platform/efi/efi_64.c | 9 ++--
> arch/x86/realmode/init.c | 8 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
> drivers/gpu/drm/drm_cache.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +--
> drivers/iommu/amd/init.c | 7 +--
> drivers/iommu/amd/iommu.c | 3 +-
> drivers/iommu/amd/iommu_v2.c | 3 +-
> drivers/iommu/iommu.c | 3 +-
> fs/proc/vmcore.c | 6 +--
> include/linux/mem_encrypt.h | 4 --
> include/linux/protected_guest.h | 37 +++++++++++++
> kernel/dma/swiotlb.c | 4 +-
> 36 files changed, 218 insertions(+), 104 deletions(-)
> create mode 100644 arch/powerpc/include/asm/protected_guest.h
> create mode 100644 arch/x86/include/asm/protected_guest.h
> create mode 100644 include/linux/protected_guest.h
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
^ permalink raw reply
* Re: [PATCH v2 1/2] sched/topology: Skip updating masks for non-online nodes
From: Valentin Schneider @ 2021-08-08 15:56 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Vincent Guittot, Rik van Riel,
Peter Zijlstra, linuxppc-dev, Geetika Moolchandani, LKML,
Dietmar Eggemann, Thomas Gleixner, Laurent Dufour, Mel Gorman,
Ingo Molnar
In-Reply-To: <20210723143914.GI3836887@linux.vnet.ibm.com>
A bit late, but technically the week isn't over yet! :D
On 23/07/21 20:09, Srikar Dronamraju wrote:
> * Valentin Schneider <valentin.schneider@arm.com> [2021-07-13 17:32:14]:
>> Now, let's take examples from your cover letter:
>>
>> node distances:
>> node 0 1 2 3 4 5 6 7
>> 0: 10 20 40 40 40 40 40 40
>> 1: 20 10 40 40 40 40 40 40
>> 2: 40 40 10 20 40 40 40 40
>> 3: 40 40 20 10 40 40 40 40
>> 4: 40 40 40 40 10 20 40 40
>> 5: 40 40 40 40 20 10 40 40
>> 6: 40 40 40 40 40 40 10 20
>> 7: 40 40 40 40 40 40 20 10
>>
>> But the system boots with just nodes 0 and 1, thus only this distance
>> matrix is valid:
>>
>> node 0 1
>> 0: 10 20
>> 1: 20 10
>>
>> topology_span_sane() is going to use tl->mask(cpu), and as you reported the
>> NODE topology level should cause issues. Let's assume all offline nodes say
>> they're 10 distance away from everyone else, and that we have one CPU per
>> node. This would give us:
>>
>
> No,
> All offline nodes would be at a distance of 10 from node 0 only.
> So here node distance of all offline nodes from node 1 would be 20.
>
>> NODE->mask(0) == 0,2-7
>> NODE->mask(1) == 1-7
>
> so
>
> NODE->mask(0) == 0,2-7
> NODE->mask(1) should be 1
> and NODE->mask(2-7) == 0,2-7
>
Ok, so that shouldn't trigger the warning.
>>
>> The intersection is 2-7, we'll trigger the WARN_ON().
>> Now, with the above snippet, we'll check if that intersection covers any
>> online CPU. For sched_init_domains(), cpu_map is cpu_active_mask, so we'd
>> end up with an empty intersection and we shouldn't warn - that's the theory
>> at least.
>
> Now lets say we onlined CPU 3 and node 3 which was at a actual distance
> of 20 from node 0.
>
> (If we only consider online CPUs, and since scheduler masks like
> sched_domains_numa_masks arent updated with offline CPUs,)
> then
>
> NODE->mask(0) == 0
> NODE->mask(1) == 1
> NODE->mask(3) == 0,3
>
Wait, doesn't the distance matrix (without any offline node) say
distance(0, 3) == 40
? We should have at the very least:
node 0 1 2 3
0: 10 20 ?? 40
1: 20 20 ?? 40
2: ?? ?? ?? ??
3: 40 40 ?? 10
Regardless, NODE->mask(x) is sched_domains_numa_masks[0][x], if
distance(0,3) > LOCAL_DISTANCE
then
node0 ∉ NODE->mask(3)
> cpumask_and(intersect, tl->mask(cpu), tl->mask(i));
> if (!cpumask_equal(tl->mask(cpu), tl->mask(i)) && cpumask_intersects(intersect, cpu_map))
>
> cpu_map is 0,1,3
> intersect is 0
>
> From above NODE->mask(0) is !equal to NODE->mask(1) and
> cpumask_intersects(intersect, cpu_map) is also true.
>
> I picked Node 3 since if Node 1 is online, we would have faked distance
> for Node 2 to be at distance of 40.
>
> Any node from 3 to 7, we would have faced the same problem.
>
>>
>> Looking at sd_numa_mask(), I think there's a bug with topology_span_sane():
>> it doesn't run in the right place wrt where sched_domains_curr_level is
>> updated. Could you try the below on top of the previous snippet?
>>
>> If that doesn't help, could you share the node distances / topology masks
>> that lead to the WARN_ON()? Thanks.
>>
>> ---
>> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
>> index b77ad49dc14f..cda69dfa4065 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -1516,13 +1516,6 @@ sd_init(struct sched_domain_topology_level *tl,
>> int sd_id, sd_weight, sd_flags = 0;
>> struct cpumask *sd_span;
>>
>> -#ifdef CONFIG_NUMA
>> - /*
>> - * Ugly hack to pass state to sd_numa_mask()...
>> - */
>> - sched_domains_curr_level = tl->numa_level;
>> -#endif
>> -
>> sd_weight = cpumask_weight(tl->mask(cpu));
>>
>> if (tl->sd_flags)
>> @@ -2131,7 +2124,12 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
>>
>> sd = NULL;
>> for_each_sd_topology(tl) {
>> -
>> +#ifdef CONFIG_NUMA
>> + /*
>> + * Ugly hack to pass state to sd_numa_mask()...
>> + */
>> + sched_domains_curr_level = tl->numa_level;
>> +#endif
>> if (WARN_ON(!topology_span_sane(tl, cpu_map, i)))
>> goto error;
>>
>>
>
> I tested with the above patch too. However it still not helping.
>
> Here is the log from my testing.
>
> At Boot.
>
> (Do remember to arrive at sched_max_numa_levels we faked the
> numa_distance of node 1 to be at 20 from node 0. All other offline
> nodes are at a distance of 10 from node 0.)
>
[...]
> ( First addition of a CPU to a non-online node esp node whose node
> distance was not faked.)
>
> numactl -H
> available: 3 nodes (0,5,7)
> node 0 cpus: 0 1 2 3 4 5 6 7
> node 0 size: 0 MB
> node 0 free: 0 MB
> node 5 cpus: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 32 33 34 35 40 41 42 43 48 49 50 51 56 57 58 59 64 65 66 67 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
> node 5 size: 32038 MB
> node 5 free: 29024 MB
> node 7 cpus: 88 89 90 91 92 93 94 95
> node 7 size: 0 MB
> node 7 free: 0 MB
> node distances:
> node 0 5 7
> 0: 10 40 40
> 5: 40 10 20
> 7: 40 20 10
> ------------------------------------------------------------------
> grep -r . /sys/kernel/debug/sched/domains/cpu0/domain{0,1,2,3,4}/{name,flags}
> ------------------------------------------------------------------
> awk '/domain/{print $1, $2}' /proc/schedstat | sort -u | sed -e 's/00000000,//g'
> ==================================================================
>
> I had added a debug patch to dump some variables that may help to
> understand the problem
> ------------------->8--------------------------------------------8<----------
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 5e1abd9a8cc5..146f59381bcc 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -2096,7 +2096,8 @@ static bool topology_span_sane(struct sched_domain_topology_level *tl,
> cpumask_and(intersect, tl->mask(cpu), tl->mask(i));
> if (!cpumask_equal(tl->mask(cpu), tl->mask(i)) &&
> cpumask_intersects(intersect, cpu_map)) {
> - pr_err("name=%s mask(%d/%d)=%*pbl mask(%d/%d)=%*pbl", tl->name, cpu, cpu_to_node(cpu), cpumask_pr_args(tl->mask(cpu)), i, cpu_to_node(i), cpumask_pr_args(tl->mask(i)));
> + pr_err("name=%s mask(%d/%d)=%*pbl mask(%d/%d)=%*pbl numa-level=%d curr_level=%d", tl->name, cpu, cpu_to_node(cpu), cpumask_pr_args(tl->mask(cpu)), i, cpu_to_node(i), cpumask_pr_args(tl->mask(i)), tl->numa_level, sched_domains_curr_level);
> + pr_err("intersect=%*pbl cpu_map=%*pbl", cpumask_pr_args(intersect), cpumask_pr_args(cpu_map));
> return false;
> }
> }
> ------------------->8--------------------------------------------8<----------
>
> From dmesg:
>
> [ 167.626915] name=NODE mask(0/0)=0-7 mask(88/7)=0-7,88 numa-level=0 curr_level=0 <-- hunk above
> [ 167.626925] intersect=0-7 cpu_map=0-19,24-27,32-35,40-43,48-51,56-59,64-67,72-88
> [ 168.026621] name=NODE mask(0/0)=0-7 mask(88/7)=0-7,88-89 numa-level=0 curr_level=0
> [ 168.026626] intersect=0-7 cpu_map=0-19,24-27,32-35,40-43,48-51,56-59,64-67,72-89
>
Ok so to condense the info, we have:
node 0 5 7
0: 10 40 40
5: 40 10 20
7: 40 20 10
node0: 0-7
node5: 8-29, 32-35, 40-43, 48-51, 56-59, 64-67, 72-87
node7: 88-95
With the above distance map, we should have
NODE->mask(CPU0) == 0-7
NODE->mask(CPU8) == 8-29, 32-35, 40-43, 48-51, 56-59, 64-67, 72-87
NODE->mask(CPU88) == 88-95
(this is sched_domains_numa_masks[0][CPUx], and
sched_domains_numa_distance[0] == LOCAL_DISTANCE, thus the mask of CPUs
LOCAL_DISTANCE away from CPUx).
For some reason you end up with node0 being part of node7's NODE
mask. Neither nodes are offline, and per the above distance table that
shouldn't happen.
> Now this keeps repeating.
>
> I know I have mentioned this before. (So sorry for repeating)
It can't hurt to reformulate ;)
> Generally on Power node distance is not populated for offline nodes.
> However to arrive at sched_max_numa_levels, we thought of faking few
> node distances. In the above case, we faked distance of node 1 as 20
> (from node 0) node 5 was already at distance of 40 from node 0.
>
Right, again that gives us the right set of unique distances (10, 20, 40).
> So when sched_domains_numa_masks_set is called to update sd_numa_mask or
> sched_domains_numa_masks, all CPUs under node 0 get updated for node 2
> too. (since node 2 is shown as at a local distance from node 0). Do
> look at the node mask of CPU 88 in the dmesg. It should have been 88,
> however its 0-7,88 where 0-7 are coming from node 0.
>
> Even if we skip updation of sched_domains_numa_masks for offline nodes,
> on online of a node (i.e when we get the correct node distance), we have
> to update the sched_domains_numa_masks to ensure CPUs that were already
> present within a certain distance and skipped are added back. And this
> was what I tried to do in my patch.
>
Ok, so it looks like we really can't do without that part - even if we get
"sensible" distance values for the online nodes, we can't divine values for
the offline ones.
> --
> Thanks and Regards
> Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v1 26/55] KVM: PPC: Book3S HV: Change dec_expires to be relative to guest timebase
From: Michael Ellerman @ 2021-08-07 23:17 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210726035036.739609-27-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> Change dec_expires to be relative to the guest timebase, and allow
> it to be moved into low level P9 guest entry functions, to improve
> SPR access scheduling.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 6 +++
> arch/powerpc/include/asm/kvm_host.h | 2 +-
> arch/powerpc/kvm/book3s_hv.c | 58 +++++++++++++------------
> arch/powerpc/kvm/book3s_hv_nested.c | 3 ++
> arch/powerpc/kvm/book3s_hv_p9_entry.c | 10 ++++-
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 14 ------
> 6 files changed, 49 insertions(+), 44 deletions(-)
My p8 is hitting an oops running guests, and bisect points to this. Not
obvious how the change relates to the oops, but maybe you can see it.
cheers
[ 716.042962][T16989] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
[ 716.043020][T16989] BUG: Kernel NULL pointer dereference on read at 0x00000000
[ 716.043028][T16989] Faulting instruction address: 0xc00000000001e1a8
[ 716.043037][T16989] Oops: Kernel access of bad area, sig: 11 [#1]
[ 716.043043][T16989] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[ 716.043052][T16989] Modules linked in: xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink ip6table_filter ip6_tables iptable_filter tun bridge stp llc fuse kvm_hv kvm binfmt_misc squashfs mlx4_ib ib_uverbs dm_multipath scsi_dh_rdac ib_core scsi_dh_alua mlx4_en sr_mod cdrom lpfc sg mlx4_core bnx2x crc_t10dif crct10dif_generic scsi_transport_fc mdio vmx_crypto gf128mul crct10dif_vpmsum crct10dif_common leds_powernv powernv_rng led_class crc32c_vpmsum rng_core powernv_op_panel sunrpc ip_tables x_tables autofs4
[ 716.043128][T16989] CPU: 56 PID: 16989 Comm: qemu-system-ppc Not tainted 5.14.0-rc4-02329-g9bdd37071243 #1
[ 716.043137][T16989] NIP: c00000000001e1a8 LR: c00000000001e154 CTR: c00000000016ebb0
[ 716.043144][T16989] REGS: c0000009f1a93480 TRAP: 0300 Not tainted (5.14.0-rc4-02329-g9bdd37071243)
[ 716.043150][T16989] MSR: 9000000002803033 <SF,HV,VEC,VSX,FP,ME,IR,DR,RI,LE> CR: 42442444 XER: 20000000
[ 716.043167][T16989] CFAR: c00000000000cd0c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 3
[ 716.043167][T16989] GPR00: c00000000001eab8 c0000009f1a93720 c000000002459f00 c0000009c0730270
[ 716.043167][T16989] GPR04: 00000000000001f0 0000000000000000 0000000022442448 c0000009c072ec80
[ 716.043167][T16989] GPR08: 00000000000000c2 0000000044000000 9000000002803033 0000000000000001
[ 716.043167][T16989] GPR12: 0000000000002200 c000000ffffec600 00007fff955f4410 0000000000000000
[ 716.043167][T16989] GPR16: 00007fff96280000 00007fff955f0320 00007fff8ee8ebe0 00007fff8e660028
[ 716.043167][T16989] GPR20: c000000803807400 c000000858b243bc 000000000000000a c000000002496eb8
[ 716.043167][T16989] GPR24: c000000801123650 c0000009c0730250 c0000009c072ec80 0000000002802000
[ 716.043167][T16989] GPR28: 0000000000800000 0000000002802000 0000000000800000 c0000009f1a93e80
[ 716.043236][T16989] NIP [c00000000001e1a8] restore_math+0x208/0x310
[ 716.043247][T16989] LR [c00000000001e154] restore_math+0x1b4/0x310
[ 716.043254][T16989] Call Trace:
[ 716.043257][T16989] [c0000009f1a93720] [0000000022442448] 0x22442448 (unreliable)
[ 716.043267][T16989] [c0000009f1a93780] [c00000000001eab8] __switch_to+0x228/0x2f0
[ 716.043274][T16989] [c0000009f1a937e0] [c000000000f7949c] __schedule+0x40c/0xf10
[ 716.043283][T16989] [c0000009f1a938b0] [c000000000f7a034] schedule+0x94/0x170
[ 716.043291][T16989] [c0000009f1a938e0] [c00800000b8e4474] kvmppc_wait_for_exec+0xdc/0xf8 [kvm_hv]
[ 716.043307][T16989] [c0000009f1a93960] [c00800000b8eeb18] kvmppc_vcpu_run_hv+0x900/0x10f0 [kvm_hv]
[ 716.043319][T16989] [c0000009f1a93a10] [c00800000b76355c] kvmppc_vcpu_run+0x34/0x48 [kvm]
[ 716.043340][T16989] [c0000009f1a93a30] [c00800000b75f188] kvm_arch_vcpu_ioctl_run+0x340/0x450 [kvm]
[ 716.043359][T16989] [c0000009f1a93ac0] [c00800000b74d470] kvm_vcpu_ioctl+0x328/0x8f8 [kvm]
[ 716.043378][T16989] [c0000009f1a93ca0] [c0000000004fe9d4] sys_ioctl+0x6b4/0x13b0
[ 716.043386][T16989] [c0000009f1a93db0] [c00000000002f918] system_call_exception+0x168/0x290
[ 716.043394][T16989] [c0000009f1a93e10] [c00000000000c864] system_call_common+0xf4/0x258
[ 716.043402][T16989] --- interrupt: c00 at 0x7fff954af010
[ 716.043407][T16989] NIP: 00007fff954af010 LR: 0000000116243430 CTR: 0000000000000000
[ 716.043413][T16989] REGS: c0000009f1a93e80 TRAP: 0c00 Not tainted (5.14.0-rc4-02329-g9bdd37071243)
[ 716.043419][T16989] MSR: 900000000000d033 <SF,HV,EE,PR,ME,IR,DR,RI,LE> CR: 22444442 XER: 00000000
[ 716.043434][T16989] IRQMASK: 0
[ 716.043434][T16989] GPR00: 0000000000000036 00007fff8ee8dc30 00007fff955a7100 000000000000000f
[ 716.043434][T16989] GPR04: 000000002000ae80 0000000000000000 00000000000004fb 0000000000000000
[ 716.043434][T16989] GPR08: 000000000000000f 0000000000000000 0000000000000000 0000000000000000
[ 716.043434][T16989] GPR12: 0000000000000000 00007fff8ee96290 00007fff955f4410 0000000000000000
[ 716.043434][T16989] GPR16: 00007fff96280000 00007fff955f0320 00007fff8ee8ebe0 00007fff8e660028
[ 716.043434][T16989] GPR20: 0000000000000000 0000000000000000 000000011689b0d0 000000002000ae80
[ 716.043434][T16989] GPR24: 00007fff8ffa00ae 0000000000000000 00007fff8ee8f290 00007fff8ffb0010
[ 716.043434][T16989] GPR28: 0000000116e010e0 00007fff8ffb0010 0000000000000000 000000002000ae80
[ 716.043498][T16989] NIP [00007fff954af010] 0x7fff954af010
[ 716.043503][T16989] LR [0000000116243430] 0x116243430
[ 716.043507][T16989] --- interrupt: c00
[ 716.043511][T16989] Instruction dump:
[ 716.043517][T16989] fb610038 67db0200 9907185a 4182005c 7c0802a6 7f63db78 f8010070 4bffeeed
[ 716.043529][T16989] 2c3e0000 408200d4 547ddb78 0082812b <eb000000> 387a1860 7fdcf378 7f7edb78
[ 716.043543][T16989] ---[ end trace b02ece1d913ff866 ]---
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Christophe Leroy @ 2021-08-07 17:08 UTC (permalink / raw)
To: Stan Johnson, Finn Thain; +Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <47e3180a-be1a-aec1-b5d9-b7d25547b1dc@yahoo.com>
Le 07/08/2021 à 18:26, Stan Johnson a écrit :
> On 8/7/21 8:35 AM, Christophe Leroy wrote:
>>
>>
>> Le 07/08/2021 à 15:09, Stan Johnson a écrit :
>>> On 8/6/21 10:08 PM, Finn Thain wrote:
>>>>
>>>> On Fri, 6 Aug 2021, Stan Johnson wrote:
>>>>
>>>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>>>> CONFIG_PPC_KUAP=y
>>>>> CONFIG_PPC_KUAP_DEBUG=y
>>>>> CONFIG_VMAP_STACK=y
>>>>> $ strings vmlinux | fgrep "Linux version"
>>>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>>>
>>>>> 1) PB 3400c
>>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>>> Boots, no errors logging in at (text) fb console. Logging in via ssh
>>>>> and
>>>>> running "ls -Rail /usr/include" generated errors (and a hung ssh
>>>>> session). Once errors started, they repeated for almost every command.
>>>>> See pb3400c-63e3756d1bdf-1.txt.
>>>>>
>>>>> 2) Wallstreet
>>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>>> X login failed, there were errors ("Oops: Kernel access of bad area",
>>>>> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
>>>>> additional errors after running "ls -Rail /usr/include" -- the errors
>>>>> did not escalate as they did on the PB 3400.
>>>>> See Wallstreet-63e3756d1bdf-1.txt.
>>>>>
>>>> ...
>>>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>>>> CONFIG_PPC_KUAP=y
>>>>> CONFIG_PPC_KUAP_DEBUG=y
>>>>> # CONFIG_VMAP_STACK is not set
>>>>> $ strings vmlinux | fgrep "Linux version"
>>>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>>>
>>>>> 3) PB 3400c
>>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>>> Filesystem was corrupt from the previous test (probably from all the
>>>>> errors during shutdown). After fixing the filesystem:
>>>>> Boots, no errors logging in at (text) fb console. Logging in via ssh
>>>>> and
>>>>> running "ls -Rail /usr/include" generated a few errors. There didn't
>>>>> seem to be as many errors as in the previous test, there were a few
>>>>> errors during shutdown but the shutdown was otherwise normal.
>>>>> See pb3400c-63e3756d1bdf-2.txt.
>>>>>
>>>>> 4) Wallstreet
>>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>>> X login worked, and there were no errors. There were no errors during
>>>>> ssh access.
>>>>> See Wallstreet-63e3756d1bdf-2.txt.
>>>>>
>>>>
>>>> Thanks for collecting these results, Stan. Do you think that the
>>>> successful result from test 4) could have been just chance?
>>>
>>> No. I repeated Test 4 above two more times on the Wallstreet. After
>>> stomping on it as hard as I could, I didn't see any errors. I ran the
>>> following tests simultaneously, with no errors:
>>>
>>> a) Ping flood the Wallstreet
>>> 862132 packets transmitted, 862117 packets received, 0.0% packet loss
>>> round-trip min/avg/max/stddev = 0.316/0.418/12.163/0.143 ms
>>>
>>> b) "ls -Rail /usr" in an ssh window.
>>>
>>> c) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh
>>> window.
>>>
>>> d) With a, b and c running, I logged in at the X console (slow but it
>>> worked). Load average was 7.0 as reported by uptime.
>>>
>>> So the success seems to be repeatable (or at least the errors are so
>>> unlikely to happen that I'm not seeing anything).
>>>
>>>>
>>>> It appears that the bug affecting the Powerbook 3400 is unaffected by
>>>> CONFIG_VMAP_STACK.
>>>>
>>>> Whereas the bug affecting the Powerbook G3 disappears when
>>>> CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
>>>>
>>>> Either way, these results reiterate that "Oops: Kernel access of bad
>>>> area,
>>>> sig: 11" was not entirely resolved by "powerpc/32s: Fix napping
>>>> restore in
>>>> data storage interrupt (DSI)".
>>>>
>>>
>>> That sounds right. Thanks for investigating this.
>>>
>>
>>
>> Thanks a lot for your patience and for the tests.
>>
>> I'm still having hard time understanding what the problem is.
>>
>> Could you try the new change I pushed into the git repo ? It shouldn't
>> have any effect, but I prefer to eliminate all possibilities. The
>> documentation says that SRR1 upper bit are 0 on DSI and the code relies
>> on that. But if the doc is wrong then that can explain the problem. So
>> now I'm forcing it to 0 regardless.
>>
>> To get the change, you just have to do 'git pull -r' inside the
>> directory where you checked out the sources and build.
>>
>> Thanks again
>> Christophe
>>
>
> Thanks, Christophe.
>
> In the same directory as previous builds:
>
> $ git checkout chleroy-linux/bugtest
> HEAD is now at 63e3756d1bdf powerpc/interrupts: Also perform KUAP/KUEP
> lock and usertime accounting on NMI
> $ git pull -r
> You are not currently on a branch.
> Please specify which branch you want to rebase against.
> ...
> $ git pull -r chleroy-linux
> remote: Enumerating objects: 6, done.
> remote: Counting objects: 100% (6/6), done.
> remote: Compressing objects: 100% (6/6), done.
> remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
> Unpacking objects: 100% (6/6), done.
> From https://github.com/chleroy/linux
> 63e3756d1bdf..9023760b1361 bugtest -> chleroy-linux/bugtest
> Updating 63e3756d1bdf..9023760b1361
> Fast-forward
> arch/powerpc/kernel/head_book3s_32.S | 1 +
> 1 file changed, 1 insertion(+)
> HEAD is up to date.
>
> Hopefully I did that right and ended up at the right spot.
>
> For tests 5 and 6:
>
> $ cp ../dot-config-powermac-5.13 .config
> $ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -e
> CONFIG_VMAP_STACK
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean
> olddefconfig vmlinux
> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
> CONFIG_PPC_KUAP=y
> CONFIG_PPC_KUAP_DEBUG=y
> CONFIG_VMAP_STACK=y
> $ strings vmlinux | grep "Linux version"
> Linux version 5.13.0-pmac-00005-g9023760b136 (johnson@ThinkPad)
> (powerpc-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
> Debian) 2.31.1) #3 SMP Sat Aug 7 09:29:11 MDT 2021
> $ cp vmlinux ../vmlinux-5.13.0-pmac-00005-g9023760b136-1
>
>
> 5) PB 3400c
> vmlinux-5.13.0-pmac-00005-g9023760b136-1
> Boots, no errors logging in at (text) fb console. Logging in via ssh and
> running "ls -Rail /usr/include" generated errors. As before, once errors
> started, they seemed to escalate, including errors during "shutdown -r now".
> See pb3400c-g9023760b136-1.txt.
>
> 6) Wallstreet
> vmlinux-5.13.0-pmac-00005-g9023760b136-1
> X login failed, and there were errors. Logging in via SSH, there were no
> additional errors after running "ls -Rail /usr/include" -- as before,
> the errors did not escalate as they did on the PB 3400.
> See Wallstreet-g9023760b136-1.txt.
>
> For tests 7 and 8:
>
> $ cp ../dot-config-powermac-5.13 .config
> $ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -d
> CONFIG_VMAP_STACK
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean
> olddefconfig vmlinux
> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
> CONFIG_PPC_KUAP=y
> CONFIG_PPC_KUAP_DEBUG=y
> # CONFIG_VMAP_STACK is not set
> $ strings vmlinux | grep "Linux version"
> Linux version 5.13.0-pmac-00005-g9023760b136 (johnson@ThinkPad)
> (powerpc-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
> Debian) 2.31.1) #4 SMP Sat Aug 7 09:49:03 MDT 2021
> $ cp vmlinux ../vmlinux-5.13.0-pmac-00005-g9023760b136-2
>
>
> 7) PB 3400c
> vmlinux-5.13.0-pmac-00005-g9023760b136-2
> As before, the filesystem was corrupt from the previous test. After
> fixing that, this kernel boots, and there were no errors from logging in
> at the (text) fb console. Logging in via ssh and running "ls -Rail
> /usr/include" generated errors. There were a few errors logging in at
> the serial console and during shutdown, but the shutdown was otherwise
> normal.
> See pb3400c-g9023760b136-2.txt.
>
> 8) Wallstreet
> vmlinux-5.13.0-pmac-00005-g9023760b136-2
> X login worked, and there were no errors. There were also no errors
> during ssh access.
> Simultaneous stress test, also no errors:
> a) Login at X console.
> b) Ping flood the Wallstreet
> 359695 packets transmitted, 359688 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.322/0.428/16.857/0.165 ms
> c) "ls -Rail /usr" in an ssh window.
> d) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh window.
> See Wallstreet-g9023760b136-2.txt.
>
> As far as I could tell, there were no significant changes from the
> previous four tests.
>
Ok, that was expected, but I wanted to be 100% sure to avoid looking into the wrong direction.
To be honnest, I'm running out of ideas.
We have two remaining independant problems as far as I understand:
PB3400C (603ev core = No hash table)
- A KUAP fault, regardless of CONFIG_VMAP_STACK, due to a clobber of r11 registers apparently.
Wallstreet (Hash table)
- Random faults, only with CONFIG_VMAP_STACK
One thing I am wondering, could there be a link with SMP ?
Would you mind trying with a kernel built without CONFIG_SMP ?
Thanks
Christophe
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Stan Johnson @ 2021-08-07 16:26 UTC (permalink / raw)
To: Christophe Leroy, Finn Thain
Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <8373276b-ba7a-440b-b353-fdb1be558628@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 8103 bytes --]
On 8/7/21 8:35 AM, Christophe Leroy wrote:
>
>
> Le 07/08/2021 à 15:09, Stan Johnson a écrit :
>> On 8/6/21 10:08 PM, Finn Thain wrote:
>>>
>>> On Fri, 6 Aug 2021, Stan Johnson wrote:
>>>
>>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>>> CONFIG_PPC_KUAP=y
>>>> CONFIG_PPC_KUAP_DEBUG=y
>>>> CONFIG_VMAP_STACK=y
>>>> $ strings vmlinux | fgrep "Linux version"
>>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>>
>>>> 1) PB 3400c
>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>> Boots, no errors logging in at (text) fb console. Logging in via ssh
>>>> and
>>>> running "ls -Rail /usr/include" generated errors (and a hung ssh
>>>> session). Once errors started, they repeated for almost every command.
>>>> See pb3400c-63e3756d1bdf-1.txt.
>>>>
>>>> 2) Wallstreet
>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>> X login failed, there were errors ("Oops: Kernel access of bad area",
>>>> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
>>>> additional errors after running "ls -Rail /usr/include" -- the errors
>>>> did not escalate as they did on the PB 3400.
>>>> See Wallstreet-63e3756d1bdf-1.txt.
>>>>
>>> ...
>>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>>> CONFIG_PPC_KUAP=y
>>>> CONFIG_PPC_KUAP_DEBUG=y
>>>> # CONFIG_VMAP_STACK is not set
>>>> $ strings vmlinux | fgrep "Linux version"
>>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>>
>>>> 3) PB 3400c
>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>> Filesystem was corrupt from the previous test (probably from all the
>>>> errors during shutdown). After fixing the filesystem:
>>>> Boots, no errors logging in at (text) fb console. Logging in via ssh
>>>> and
>>>> running "ls -Rail /usr/include" generated a few errors. There didn't
>>>> seem to be as many errors as in the previous test, there were a few
>>>> errors during shutdown but the shutdown was otherwise normal.
>>>> See pb3400c-63e3756d1bdf-2.txt.
>>>>
>>>> 4) Wallstreet
>>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>> X login worked, and there were no errors. There were no errors during
>>>> ssh access.
>>>> See Wallstreet-63e3756d1bdf-2.txt.
>>>>
>>>
>>> Thanks for collecting these results, Stan. Do you think that the
>>> successful result from test 4) could have been just chance?
>>
>> No. I repeated Test 4 above two more times on the Wallstreet. After
>> stomping on it as hard as I could, I didn't see any errors. I ran the
>> following tests simultaneously, with no errors:
>>
>> a) Ping flood the Wallstreet
>> 862132 packets transmitted, 862117 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 0.316/0.418/12.163/0.143 ms
>>
>> b) "ls -Rail /usr" in an ssh window.
>>
>> c) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh
>> window.
>>
>> d) With a, b and c running, I logged in at the X console (slow but it
>> worked). Load average was 7.0 as reported by uptime.
>>
>> So the success seems to be repeatable (or at least the errors are so
>> unlikely to happen that I'm not seeing anything).
>>
>>>
>>> It appears that the bug affecting the Powerbook 3400 is unaffected by
>>> CONFIG_VMAP_STACK.
>>>
>>> Whereas the bug affecting the Powerbook G3 disappears when
>>> CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
>>>
>>> Either way, these results reiterate that "Oops: Kernel access of bad
>>> area,
>>> sig: 11" was not entirely resolved by "powerpc/32s: Fix napping
>>> restore in
>>> data storage interrupt (DSI)".
>>>
>>
>> That sounds right. Thanks for investigating this.
>>
>
>
> Thanks a lot for your patience and for the tests.
>
> I'm still having hard time understanding what the problem is.
>
> Could you try the new change I pushed into the git repo ? It shouldn't
> have any effect, but I prefer to eliminate all possibilities. The
> documentation says that SRR1 upper bit are 0 on DSI and the code relies
> on that. But if the doc is wrong then that can explain the problem. So
> now I'm forcing it to 0 regardless.
>
> To get the change, you just have to do 'git pull -r' inside the
> directory where you checked out the sources and build.
>
> Thanks again
> Christophe
>
Thanks, Christophe.
In the same directory as previous builds:
$ git checkout chleroy-linux/bugtest
HEAD is now at 63e3756d1bdf powerpc/interrupts: Also perform KUAP/KUEP
lock and usertime accounting on NMI
$ git pull -r
You are not currently on a branch.
Please specify which branch you want to rebase against.
...
$ git pull -r chleroy-linux
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/chleroy/linux
63e3756d1bdf..9023760b1361 bugtest -> chleroy-linux/bugtest
Updating 63e3756d1bdf..9023760b1361
Fast-forward
arch/powerpc/kernel/head_book3s_32.S | 1 +
1 file changed, 1 insertion(+)
HEAD is up to date.
Hopefully I did that right and ended up at the right spot.
For tests 5 and 6:
$ cp ../dot-config-powermac-5.13 .config
$ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -e
CONFIG_VMAP_STACK
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean
olddefconfig vmlinux
$ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
CONFIG_PPC_KUAP=y
CONFIG_PPC_KUAP_DEBUG=y
CONFIG_VMAP_STACK=y
$ strings vmlinux | grep "Linux version"
Linux version 5.13.0-pmac-00005-g9023760b136 (johnson@ThinkPad)
(powerpc-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
Debian) 2.31.1) #3 SMP Sat Aug 7 09:29:11 MDT 2021
$ cp vmlinux ../vmlinux-5.13.0-pmac-00005-g9023760b136-1
5) PB 3400c
vmlinux-5.13.0-pmac-00005-g9023760b136-1
Boots, no errors logging in at (text) fb console. Logging in via ssh and
running "ls -Rail /usr/include" generated errors. As before, once errors
started, they seemed to escalate, including errors during "shutdown -r now".
See pb3400c-g9023760b136-1.txt.
6) Wallstreet
vmlinux-5.13.0-pmac-00005-g9023760b136-1
X login failed, and there were errors. Logging in via SSH, there were no
additional errors after running "ls -Rail /usr/include" -- as before,
the errors did not escalate as they did on the PB 3400.
See Wallstreet-g9023760b136-1.txt.
For tests 7 and 8:
$ cp ../dot-config-powermac-5.13 .config
$ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -d
CONFIG_VMAP_STACK
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean
olddefconfig vmlinux
$ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
CONFIG_PPC_KUAP=y
CONFIG_PPC_KUAP_DEBUG=y
# CONFIG_VMAP_STACK is not set
$ strings vmlinux | grep "Linux version"
Linux version 5.13.0-pmac-00005-g9023760b136 (johnson@ThinkPad)
(powerpc-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
Debian) 2.31.1) #4 SMP Sat Aug 7 09:49:03 MDT 2021
$ cp vmlinux ../vmlinux-5.13.0-pmac-00005-g9023760b136-2
7) PB 3400c
vmlinux-5.13.0-pmac-00005-g9023760b136-2
As before, the filesystem was corrupt from the previous test. After
fixing that, this kernel boots, and there were no errors from logging in
at the (text) fb console. Logging in via ssh and running "ls -Rail
/usr/include" generated errors. There were a few errors logging in at
the serial console and during shutdown, but the shutdown was otherwise
normal.
See pb3400c-g9023760b136-2.txt.
8) Wallstreet
vmlinux-5.13.0-pmac-00005-g9023760b136-2
X login worked, and there were no errors. There were also no errors
during ssh access.
Simultaneous stress test, also no errors:
a) Login at X console.
b) Ping flood the Wallstreet
359695 packets transmitted, 359688 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.322/0.428/16.857/0.165 ms
c) "ls -Rail /usr" in an ssh window.
d) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh window.
See Wallstreet-g9023760b136-2.txt.
As far as I could tell, there were no significant changes from the
previous four tests.
-Stan
[-- Attachment #2: pb3400c-g9023760b136-1.txt.xz --]
[-- Type: application/octet-stream, Size: 10208 bytes --]
[-- Attachment #3: Wallstreet-g9023760b136-1.txt.xz --]
[-- Type: application/octet-stream, Size: 8644 bytes --]
[-- Attachment #4: pb3400c-g9023760b136-2.txt.xz --]
[-- Type: application/octet-stream, Size: 6940 bytes --]
[-- Attachment #5: Wallstreet-g9023760b136-2.txt.xz --]
[-- Type: application/octet-stream, Size: 4716 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] tty: hvc: pass DMA capable memory to put_chars()
From: Xianting Tian @ 2021-08-07 15:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jiri Slaby, Amit Shah, gregkh, Linux Kernel Mailing List,
open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE, Guo Ren,
linuxppc-dev, Omar Sandoval
In-Reply-To: <CAK8P3a2=BmVv0tvUKaca+LYxuAussAJtAJW9O3fRN2CbV2-9aw@mail.gmail.com>
在 2021/8/6 下午10:51, Arnd Bergmann 写道:
> On Fri, Aug 6, 2021 at 5:01 AM Xianting Tian
> <xianting.tian@linux.alibaba.com> wrote:
>> @@ -163,6 +155,13 @@ static void hvc_console_print(struct console *co, const char *b,
>> if (vtermnos[index] == -1)
>> return;
>>
>> + list_for_each_entry(hp, &hvc_structs, next)
>> + if (hp->vtermno == vtermnos[index])
>> + break;
>> +
>> + c = hp->c;
>> +
>> + spin_lock_irqsave(&hp->c_lock, flags);
> The loop looks like it might race against changes to the list. It seems strange
> that the print function has to actually search for the structure here.
>
> It may be better to have yet another array for the buffer pointers next to
> the cons_ops[] and vtermnos[] arrays.
I will make the change in v5, thanks.
>
>> +/*
>> + * These sizes are most efficient for vio, because they are the
>> + * native transfer size. We could make them selectable in the
>> + * future to better deal with backends that want other buffer sizes.
>> + */
>> +#define N_OUTBUF 16
>> +#define N_INBUF 16
>> +
>> +#define __ALIGNED__ __attribute__((__aligned__(sizeof(long))))
> I think you need a higher alignment for DMA buffers, instead of sizeof(long),
> I would suggest ARCH_DMA_MINALIGN.
thanks, I will fix it in v5:
#define __ALIGNED__ __attribute__((__aligned__(ARCH_DMA_MINALIGN)))
>
> Arnd
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Christophe Leroy @ 2021-08-07 14:35 UTC (permalink / raw)
To: Stan Johnson, Finn Thain; +Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <d8e4e491-acb3-4234-813f-e88d52c32bc6@yahoo.com>
Le 07/08/2021 à 15:09, Stan Johnson a écrit :
> On 8/6/21 10:08 PM, Finn Thain wrote:
>>
>> On Fri, 6 Aug 2021, Stan Johnson wrote:
>>
>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>> CONFIG_PPC_KUAP=y
>>> CONFIG_PPC_KUAP_DEBUG=y
>>> CONFIG_VMAP_STACK=y
>>> $ strings vmlinux | fgrep "Linux version"
>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>>
>>> 1) PB 3400c
>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>>> running "ls -Rail /usr/include" generated errors (and a hung ssh
>>> session). Once errors started, they repeated for almost every command.
>>> See pb3400c-63e3756d1bdf-1.txt.
>>>
>>> 2) Wallstreet
>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>> X login failed, there were errors ("Oops: Kernel access of bad area",
>>> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
>>> additional errors after running "ls -Rail /usr/include" -- the errors
>>> did not escalate as they did on the PB 3400.
>>> See Wallstreet-63e3756d1bdf-1.txt.
>>>
>> ...
>>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>>> CONFIG_PPC_KUAP=y
>>> CONFIG_PPC_KUAP_DEBUG=y
>>> # CONFIG_VMAP_STACK is not set
>>> $ strings vmlinux | fgrep "Linux version"
>>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>>
>>> 3) PB 3400c
>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>> Filesystem was corrupt from the previous test (probably from all the
>>> errors during shutdown). After fixing the filesystem:
>>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>>> running "ls -Rail /usr/include" generated a few errors. There didn't
>>> seem to be as many errors as in the previous test, there were a few
>>> errors during shutdown but the shutdown was otherwise normal.
>>> See pb3400c-63e3756d1bdf-2.txt.
>>>
>>> 4) Wallstreet
>>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>> X login worked, and there were no errors. There were no errors during
>>> ssh access.
>>> See Wallstreet-63e3756d1bdf-2.txt.
>>>
>>
>> Thanks for collecting these results, Stan. Do you think that the
>> successful result from test 4) could have been just chance?
>
> No. I repeated Test 4 above two more times on the Wallstreet. After
> stomping on it as hard as I could, I didn't see any errors. I ran the
> following tests simultaneously, with no errors:
>
> a) Ping flood the Wallstreet
> 862132 packets transmitted, 862117 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.316/0.418/12.163/0.143 ms
>
> b) "ls -Rail /usr" in an ssh window.
>
> c) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh window.
>
> d) With a, b and c running, I logged in at the X console (slow but it
> worked). Load average was 7.0 as reported by uptime.
>
> So the success seems to be repeatable (or at least the errors are so
> unlikely to happen that I'm not seeing anything).
>
>>
>> It appears that the bug affecting the Powerbook 3400 is unaffected by
>> CONFIG_VMAP_STACK.
>>
>> Whereas the bug affecting the Powerbook G3 disappears when
>> CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
>>
>> Either way, these results reiterate that "Oops: Kernel access of bad area,
>> sig: 11" was not entirely resolved by "powerpc/32s: Fix napping restore in
>> data storage interrupt (DSI)".
>>
>
> That sounds right. Thanks for investigating this.
>
Thanks a lot for your patience and for the tests.
I'm still having hard time understanding what the problem is.
Could you try the new change I pushed into the git repo ? It shouldn't have any effect, but I prefer
to eliminate all possibilities. The documentation says that SRR1 upper bit are 0 on DSI and the code
relies on that. But if the doc is wrong then that can explain the problem. So now I'm forcing it to
0 regardless.
To get the change, you just have to do 'git pull -r' inside the directory where you checked out the
sources and build.
Thanks again
Christophe
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Stan Johnson @ 2021-08-07 13:09 UTC (permalink / raw)
To: Finn Thain; +Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <f23ddb5b-90cb-2ba9-f043-66d475311b7@linux-m68k.org>
On 8/6/21 10:08 PM, Finn Thain wrote:
>
> On Fri, 6 Aug 2021, Stan Johnson wrote:
>
>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>> CONFIG_PPC_KUAP=y
>> CONFIG_PPC_KUAP_DEBUG=y
>> CONFIG_VMAP_STACK=y
>> $ strings vmlinux | fgrep "Linux version"
>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>
>> 1) PB 3400c
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>> running "ls -Rail /usr/include" generated errors (and a hung ssh
>> session). Once errors started, they repeated for almost every command.
>> See pb3400c-63e3756d1bdf-1.txt.
>>
>> 2) Wallstreet
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>> X login failed, there were errors ("Oops: Kernel access of bad area",
>> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
>> additional errors after running "ls -Rail /usr/include" -- the errors
>> did not escalate as they did on the PB 3400.
>> See Wallstreet-63e3756d1bdf-1.txt.
>>
> ...
>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>> CONFIG_PPC_KUAP=y
>> CONFIG_PPC_KUAP_DEBUG=y
>> # CONFIG_VMAP_STACK is not set
>> $ strings vmlinux | fgrep "Linux version"
>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>
>> 3) PB 3400c
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>> Filesystem was corrupt from the previous test (probably from all the
>> errors during shutdown). After fixing the filesystem:
>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>> running "ls -Rail /usr/include" generated a few errors. There didn't
>> seem to be as many errors as in the previous test, there were a few
>> errors during shutdown but the shutdown was otherwise normal.
>> See pb3400c-63e3756d1bdf-2.txt.
>>
>> 4) Wallstreet
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>> X login worked, and there were no errors. There were no errors during
>> ssh access.
>> See Wallstreet-63e3756d1bdf-2.txt.
>>
>
> Thanks for collecting these results, Stan. Do you think that the
> successful result from test 4) could have been just chance?
No. I repeated Test 4 above two more times on the Wallstreet. After
stomping on it as hard as I could, I didn't see any errors. I ran the
following tests simultaneously, with no errors:
a) Ping flood the Wallstreet
862132 packets transmitted, 862117 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.316/0.418/12.163/0.143 ms
b) "ls -Rail /usr" in an ssh window.
c) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh window.
d) With a, b and c running, I logged in at the X console (slow but it
worked). Load average was 7.0 as reported by uptime.
So the success seems to be repeatable (or at least the errors are so
unlikely to happen that I'm not seeing anything).
>
> It appears that the bug affecting the Powerbook 3400 is unaffected by
> CONFIG_VMAP_STACK.
>
> Whereas the bug affecting the Powerbook G3 disappears when
> CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
>
> Either way, these results reiterate that "Oops: Kernel access of bad area,
> sig: 11" was not entirely resolved by "powerpc/32s: Fix napping restore in
> data storage interrupt (DSI)".
>
That sounds right. Thanks for investigating this.
^ permalink raw reply
* Re: [PATCH v2 0/6] PCI: Drop duplicated tracking of a pci_dev's bound driver
From: Uwe Kleine-König @ 2021-08-07 9:26 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Mark Rutland, Giovanni Cabiddu, Rafał Miłecki,
Peter Zijlstra, linux-pci, Alexander Duyck, Sathya Prakash,
oss-drivers, Paul Mackerras, H. Peter Anvin, Jiri Olsa,
Boris Ostrovsky, linux-perf-users, Stefano Stabellini, Herbert Xu,
linux-scsi, Ido Schimmel, x86, qat-linux, Alexander Shishkin,
Ingo Molnar, Wojciech Ziemba, Jakub Kicinski, Yisen Zhuang,
Fiona Trahe, Andrew Donnellan, Mathias Nyman,
Konrad Rzeszutek Wilk, Suganath Prabu Subramani, Simon Horman,
Arnaldo Carvalho de Melo, Borislav Petkov, Michael Buesch,
Jiri Pirko, Bjorn Helgaas, Namhyung Kim, Thomas Gleixner,
Andy Shevchenko, Juergen Gross, Salil Mehta, Sreekanth Reddy,
xen-devel, Vadym Kochan, MPT-FusionLinux.pdl, netdev, linux-usb,
linux-wireless, linux-kernel, Taras Chornyi, Zhou Wang,
Arnd Bergmann, linux-crypto, kernel, Greg Kroah-Hartman,
Frederic Barrat, Oliver O'Halloran, linuxppc-dev,
David S. Miller
In-Reply-To: <20210806212452.GA1867870@bjorn-Precision-5520>
[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]
On Fri, Aug 06, 2021 at 04:24:52PM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> > On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
>
> > > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > > not the only offender here. At least the following also have a driver
> > > pointer in the device struct:
> > >
> > > parisc_device.driver
> > > acpi_device.driver
> > > dio_dev.driver
> > > hid_device.driver
> > > pci_dev.driver
> > > pnp_dev.driver
> > > rio_dev.driver
> > > zorro_dev.driver
> >
> > Right, when I converted zorro_dev it was pointed out that the code was
> > copied from pci and the latter has the same construct. :-)
> > See
> > https://lore.kernel.org/r/20210730191035.1455248-5-u.kleine-koenig@pengutronix.de
> > for the patch, I don't find where pci was pointed out, maybe it was on
> > irc only.
>
> Oh, thanks! I looked to see if you'd done something similar
> elsewhere, but I missed this one.
>
> > > Looking through the places that care about pci_dev.driver (the ones
> > > updated by patch 5/6), many of them are ... a little dubious to begin
> > > with. A few need the "struct pci_error_handlers *err_handler"
> > > pointer, so that's probably legitimate. But many just need a name,
> > > and should probably be using dev_driver_string() instead.
> >
> > Yeah, I considered adding a function to get the driver name from a
> > pci_dev and a function to get the error handlers. Maybe it's an idea to
> > introduce these two and then use to_pci_driver(pdev->dev.driver) for the
> > few remaining users? Maybe doing that on top of my current series makes
> > sense to have a clean switch from pdev->driver to pdev->dev.driver?!
>
> I'd propose using dev_driver_string() for these places:
>
> eeh_driver_name() (could change callers to use dev_driver_string())
> bcma_host_pci_probe()
> qm_alloc_uacce()
> hns3_get_drvinfo()
> prestera_pci_probe()
> mlxsw_pci_probe()
> nfp_get_drvinfo()
> ssb_pcihost_probe()
So the idea is:
PCI: Simplify pci_device_remove()
PCI: Drop useless check from pci_device_probe()
xen/pci: Drop some checks that are always true
are kept as is as preparation. (Do you want to take them from this v2,
or should I include them again in v3?)
Then convert the list of functions above to use dev_driver_string() in a
4th patch.
> The use in mpt_device_driver_register() looks unnecessary: it's only
> to get a struct pci_device_id *, which is passed to ->probe()
> functions that don't need it.
This is patch #5.
> The use in adf_enable_aer() looks wrong: it sets the err_handler
> pointer in one of the adf_driver structs. I think those structs
> should be basically immutable, and the drivers that call
> adf_enable_aer() from their .probe() methods should set
> ".err_handler = &adf_err_handler" in their static adf_driver
> definitions instead.
I don't understand that one without some research, probably this yields
at least one patch.
> I think that basically leaves these:
>
> uncore_pci_probe() # .id_table, custom driver "registration"
> match_id() # .id_table, arch/x86/kernel/probe_roms.c
> xhci_pci_quirks() # .id_table
> pci_error_handlers() # roll-your-own AER handling, drivers/misc/cxl/guest.c
>
> I think it would be fine to use to_pci_driver(pdev->dev.driver) for
> these few.
Converting these will be patch 7 then and patch 8 can then drop the
duplicated handling.
Sounds reasonable?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] powerpc: use strscpy to replace strlcpy
From: Jason Wang @ 2021-08-07 7:21 UTC (permalink / raw)
To: mpe; +Cc: wangkefeng.wang, linux-kernel, wangborong, paulus, linuxppc-dev
The strlcpy should not be used because it doesn't limit the source
length. As linus says, it's a completely useless function if you
can't implicitly trust the source string - but that is almost always
why people think they should use it! All in all the BSD function
will lead some potential bugs.
But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.
Thus, We prefer using strscpy instead of strlcpy.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
---
arch/powerpc/platforms/powermac/bootx_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index d20ef35e6d9d..741aa5b89e55 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -243,7 +243,7 @@ static void __init bootx_scan_dt_build_strings(unsigned long base,
DBG(" detected display ! adding properties names !\n");
bootx_dt_add_string("linux,boot-display", mem_end);
bootx_dt_add_string("linux,opened", mem_end);
- strlcpy(bootx_disp_path, namep, sizeof(bootx_disp_path));
+ strscpy(bootx_disp_path, namep, sizeof(bootx_disp_path));
}
/* get and store all property names */
--
2.32.0
^ permalink raw reply related
* [PATCH v2] powerpc/xive: Do not skip CPU-less nodes when creating the IPIs
From: Cédric Le Goater @ 2021-08-07 7:20 UTC (permalink / raw)
To: linuxppc-dev
Cc: Laurent Vivier, Srikar Dronamraju, Geetika Moolchandani, stable,
Cédric Le Goater
On PowerVM, CPU-less nodes can be populated with hot-plugged CPUs at
runtime. Today, the IPI is not created for such nodes, and hot-plugged
CPUs use a bogus IPI, which leads to soft lockups.
We can not directly allocate and request the IPI on demand because
bringup_up() is called under the IRQ sparse lock. The alternative is
to allocate the IPIs for all possible nodes at startup and to request
the mapping on demand when the first CPU of a node is brought up.
Fixes: 7dcc37b3eff9 ("powerpc/xive: Map one IPI interrupt per node")
Cc: stable@vger.kernel.org # v5.13
Reported-by: Geetika Moolchandani <Geetika.Moolchandani1@ibm.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210629131542.743888-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/sysdev/xive/common.c | 35 +++++++++++++++++++++----------
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index dbdbbc2f1dc5..943fd30095af 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -67,6 +67,7 @@ static struct irq_domain *xive_irq_domain;
static struct xive_ipi_desc {
unsigned int irq;
char name[16];
+ atomic_t started;
} *xive_ipis;
/*
@@ -1120,7 +1121,7 @@ static const struct irq_domain_ops xive_ipi_irq_domain_ops = {
.alloc = xive_ipi_irq_domain_alloc,
};
-static int __init xive_request_ipi(void)
+static int __init xive_init_ipis(void)
{
struct fwnode_handle *fwnode;
struct irq_domain *ipi_domain;
@@ -1144,10 +1145,6 @@ static int __init xive_request_ipi(void)
struct xive_ipi_desc *xid = &xive_ipis[node];
struct xive_ipi_alloc_info info = { node };
- /* Skip nodes without CPUs */
- if (cpumask_empty(cpumask_of_node(node)))
- continue;
-
/*
* Map one IPI interrupt per node for all cpus of that node.
* Since the HW interrupt number doesn't have any meaning,
@@ -1159,11 +1156,6 @@ static int __init xive_request_ipi(void)
xid->irq = ret;
snprintf(xid->name, sizeof(xid->name), "IPI-%d", node);
-
- ret = request_irq(xid->irq, xive_muxed_ipi_action,
- IRQF_PERCPU | IRQF_NO_THREAD, xid->name, NULL);
-
- WARN(ret < 0, "Failed to request IPI %d: %d\n", xid->irq, ret);
}
return ret;
@@ -1178,6 +1170,22 @@ static int __init xive_request_ipi(void)
return ret;
}
+static int __init xive_request_ipi(unsigned int cpu)
+{
+ struct xive_ipi_desc *xid = &xive_ipis[early_cpu_to_node(cpu)];
+ int ret;
+
+ if (atomic_inc_return(&xid->started) > 1)
+ return 0;
+
+ ret = request_irq(xid->irq, xive_muxed_ipi_action,
+ IRQF_PERCPU | IRQF_NO_THREAD,
+ xid->name, NULL);
+
+ WARN(ret < 0, "Failed to request IPI %d: %d\n", xid->irq, ret);
+ return ret;
+}
+
static int xive_setup_cpu_ipi(unsigned int cpu)
{
unsigned int xive_ipi_irq = xive_ipi_cpu_to_irq(cpu);
@@ -1192,6 +1200,9 @@ static int xive_setup_cpu_ipi(unsigned int cpu)
if (xc->hw_ipi != XIVE_BAD_IRQ)
return 0;
+ /* Register the IPI */
+ xive_request_ipi(cpu);
+
/* Grab an IPI from the backend, this will populate xc->hw_ipi */
if (xive_ops->get_ipi(cpu, xc))
return -EIO;
@@ -1231,6 +1242,8 @@ static void xive_cleanup_cpu_ipi(unsigned int cpu, struct xive_cpu *xc)
if (xc->hw_ipi == XIVE_BAD_IRQ)
return;
+ /* TODO: clear IPI mapping */
+
/* Mask the IPI */
xive_do_source_set_mask(&xc->ipi_data, true);
@@ -1253,7 +1266,7 @@ void __init xive_smp_probe(void)
smp_ops->cause_ipi = xive_cause_ipi;
/* Register the IPI */
- xive_request_ipi();
+ xive_init_ipis();
/* Allocate and setup IPI for the boot CPU */
xive_setup_cpu_ipi(smp_processor_id());
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v2 3/4] powerpc: Optimize register usage for dear register
From: Christophe Leroy @ 2021-08-07 6:57 UTC (permalink / raw)
To: sxwjean, linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, oleg, npiggin, linux-kernel,
efremov, paulus, aneesh.kumar
In-Reply-To: <20210807010239.416055-4-sxwjean@me.com>
Le 07/08/2021 à 03:02, sxwjean@me.com a écrit :
> From: Xiongwei Song <sxwjean@gmail.com>
>
> Create an anonymous union for dar and dear regsiters, we can reference
> dear to get the effective address when CONFIG_4xx=y or CONFIG_BOOKE=y.
> Otherwise, reference dar. This makes code more clear.
>
> Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
> ---
> arch/powerpc/include/asm/ptrace.h | 5 ++++-
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/ptrace/ptrace.c | 2 ++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index c252d04b1206..fa725e3238c2 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -43,7 +43,10 @@ struct pt_regs
> unsigned long mq;
> #endif
> unsigned long trap;
> - unsigned long dar;
> + union {
> + unsigned long dar;
> + unsigned long dear;
> + };
> union {
> unsigned long dsisr;
> unsigned long esr;
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index f74af8f9133c..50436b52c213 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1499,7 +1499,7 @@ static void __show_regs(struct pt_regs *regs)
> trap == INTERRUPT_DATA_STORAGE ||
> trap == INTERRUPT_ALIGNMENT) {
> if (IS_ENABLED(CONFIG_4xx) || IS_ENABLED(CONFIG_BOOKE))
> - pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->esr);
> + pr_cont("DEAR: "REG" ESR: "REG" ", regs->dear, regs->esr);
> else
> pr_cont("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
> }
> diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c
> index a222fd4d6334..7c7093c17c45 100644
> --- a/arch/powerpc/kernel/ptrace/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace.c
> @@ -373,6 +373,8 @@ void __init pt_regs_check(void)
> offsetof(struct user_pt_regs, trap));
> BUILD_BUG_ON(offsetof(struct pt_regs, dar) !=
> offsetof(struct user_pt_regs, dar));
> + BUILD_BUG_ON(offsetof(struct pt_regs, dear) !=
> + offsetof(struct user_pt_regs, dar));
dar and dear are the same, so checking the same thing a second time is pointless.
> BUILD_BUG_ON(offsetof(struct pt_regs, dsisr) !=
> offsetof(struct user_pt_regs, dsisr));
> BUILD_BUG_ON(offsetof(struct pt_regs, esr) !=
>
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc: Optimize register usage for esr register
From: Christophe Leroy @ 2021-08-07 6:56 UTC (permalink / raw)
To: sxwjean, linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, oleg, npiggin, linux-kernel,
efremov, paulus, aneesh.kumar
In-Reply-To: <20210807010239.416055-2-sxwjean@me.com>
Le 07/08/2021 à 03:02, sxwjean@me.com a écrit :
> From: Xiongwei Song <sxwjean@gmail.com>
>
> Create an anonymous union for dsisr and esr regsiters, we can reference
> esr to get the exception detail when CONFIG_4xx=y or CONFIG_BOOKE=y.
> Otherwise, reference dsisr. This makes code more clear.
>
> Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
> ---
> arch/powerpc/include/asm/ptrace.h | 5 ++++-
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/ptrace/ptrace.c | 2 ++
> arch/powerpc/kernel/traps.c | 2 +-
> arch/powerpc/platforms/44x/machine_check.c | 4 ++--
> arch/powerpc/platforms/4xx/machine_check.c | 2 +-
> 6 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 3e5d470a6155..c252d04b1206 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -44,7 +44,10 @@ struct pt_regs
> #endif
> unsigned long trap;
> unsigned long dar;
> - unsigned long dsisr;
> + union {
> + unsigned long dsisr;
> + unsigned long esr;
> + };
> unsigned long result;
> };
> };
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 185beb290580..f74af8f9133c 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1499,7 +1499,7 @@ static void __show_regs(struct pt_regs *regs)
> trap == INTERRUPT_DATA_STORAGE ||
> trap == INTERRUPT_ALIGNMENT) {
> if (IS_ENABLED(CONFIG_4xx) || IS_ENABLED(CONFIG_BOOKE))
> - pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->dsisr);
> + pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->esr);
> else
> pr_cont("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
> }
> diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c
> index 0a0a33eb0d28..a222fd4d6334 100644
> --- a/arch/powerpc/kernel/ptrace/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace.c
> @@ -375,6 +375,8 @@ void __init pt_regs_check(void)
> offsetof(struct user_pt_regs, dar));
> BUILD_BUG_ON(offsetof(struct pt_regs, dsisr) !=
> offsetof(struct user_pt_regs, dsisr));
> + BUILD_BUG_ON(offsetof(struct pt_regs, esr) !=
> + offsetof(struct user_pt_regs, dsisr));
esr and dsisr are the same, so checking the same thing a second time is pointless.
> BUILD_BUG_ON(offsetof(struct pt_regs, result) !=
> offsetof(struct user_pt_regs, result));
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index dfbce527c98e..2164f5705a0b 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -562,7 +562,7 @@ static inline int check_io_access(struct pt_regs *regs)
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> /* On 4xx, the reason for the machine check or program exception
> is in the ESR. */
> -#define get_reason(regs) ((regs)->dsisr)
> +#define get_reason(regs) ((regs)->esr)
> #define REASON_FP ESR_FP
> #define REASON_ILLEGAL (ESR_PIL | ESR_PUO)
> #define REASON_PRIVILEGED ESR_PPR
> diff --git a/arch/powerpc/platforms/44x/machine_check.c b/arch/powerpc/platforms/44x/machine_check.c
> index a5c898bb9bab..5d19daacd78a 100644
> --- a/arch/powerpc/platforms/44x/machine_check.c
> +++ b/arch/powerpc/platforms/44x/machine_check.c
> @@ -11,7 +11,7 @@
>
> int machine_check_440A(struct pt_regs *regs)
> {
> - unsigned long reason = regs->dsisr;
> + unsigned long reason = regs->esr;
>
> printk("Machine check in kernel mode.\n");
> if (reason & ESR_IMCP){
> @@ -48,7 +48,7 @@ int machine_check_440A(struct pt_regs *regs)
> #ifdef CONFIG_PPC_47x
> int machine_check_47x(struct pt_regs *regs)
> {
> - unsigned long reason = regs->dsisr;
> + unsigned long reason = regs->esr;
> u32 mcsr;
>
> printk(KERN_ERR "Machine check in kernel mode.\n");
> diff --git a/arch/powerpc/platforms/4xx/machine_check.c b/arch/powerpc/platforms/4xx/machine_check.c
> index a71c29892a91..a905da1d6f41 100644
> --- a/arch/powerpc/platforms/4xx/machine_check.c
> +++ b/arch/powerpc/platforms/4xx/machine_check.c
> @@ -10,7 +10,7 @@
>
> int machine_check_4xx(struct pt_regs *regs)
> {
> - unsigned long reason = regs->dsisr;
> + unsigned long reason = regs->esr;
>
> if (reason & ESR_IMCP) {
> printk("Instruction");
>
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Finn Thain @ 2021-08-07 4:08 UTC (permalink / raw)
To: Stan Johnson; +Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <06ddf5ab-b0c9-1c64-92ea-a9cfbfb9f3b0@yahoo.com>
On Fri, 6 Aug 2021, Stan Johnson wrote:
> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
> CONFIG_PPC_KUAP=y
> CONFIG_PPC_KUAP_DEBUG=y
> CONFIG_VMAP_STACK=y
> $ strings vmlinux | fgrep "Linux version"
> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>
> 1) PB 3400c
> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
> Boots, no errors logging in at (text) fb console. Logging in via ssh and
> running "ls -Rail /usr/include" generated errors (and a hung ssh
> session). Once errors started, they repeated for almost every command.
> See pb3400c-63e3756d1bdf-1.txt.
>
> 2) Wallstreet
> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
> X login failed, there were errors ("Oops: Kernel access of bad area",
> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
> additional errors after running "ls -Rail /usr/include" -- the errors
> did not escalate as they did on the PB 3400.
> See Wallstreet-63e3756d1bdf-1.txt.
>
...
> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
> CONFIG_PPC_KUAP=y
> CONFIG_PPC_KUAP_DEBUG=y
> # CONFIG_VMAP_STACK is not set
> $ strings vmlinux | fgrep "Linux version"
> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>
> 3) PB 3400c
> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
> Filesystem was corrupt from the previous test (probably from all the
> errors during shutdown). After fixing the filesystem:
> Boots, no errors logging in at (text) fb console. Logging in via ssh and
> running "ls -Rail /usr/include" generated a few errors. There didn't
> seem to be as many errors as in the previous test, there were a few
> errors during shutdown but the shutdown was otherwise normal.
> See pb3400c-63e3756d1bdf-2.txt.
>
> 4) Wallstreet
> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
> X login worked, and there were no errors. There were no errors during
> ssh access.
> See Wallstreet-63e3756d1bdf-2.txt.
>
Thanks for collecting these results, Stan. Do you think that the
successful result from test 4) could have been just chance?
It appears that the bug affecting the Powerbook 3400 is unaffected by
CONFIG_VMAP_STACK.
Whereas the bug affecting the Powerbook G3 disappears when
CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
Either way, these results reiterate that "Oops: Kernel access of bad area,
sig: 11" was not entirely resolved by "powerpc/32s: Fix napping restore in
data storage interrupt (DSI)".
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Finn Thain @ 2021-08-07 2:05 UTC (permalink / raw)
To: Stan Johnson; +Cc: debian-powerpc, linuxppc-dev, Nicholas Piggin
In-Reply-To: <ee724da4-4a5b-65c3-9c1c-d78954fdc7b4@csgroup.eu>
On Fri, 6 Aug 2021, Christophe Leroy wrote:
>
> I have cooked a tentative fix for that KUAP stuff.
> Could you try the branch 'bugtest' at https://github.com/chleroy/linux.git
>
Thanks, Christophe.
Stan, please test the following build.
$ git remote add chleroy-linux https://github.com/chleroy/linux.git -f -t bugtest
...
$ git checkout chleroy-linux/bugtest
HEAD is now at 63e3756d1bdf powerpc/interrupts: Also perform KUAP/KUEP lock and usertime accounting on NMI
$ cp ../dot-config-powermac-5.13 .config
$ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -e CONFIG_VMAP_STACK
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux
$ egrep "CONFIG_PPC_KUAP|CONFIG_VMAP_STACK" .config
$ strings vmlinux |grep "Linux version"
If that kernel produces errors, I'd try a second build as well:
$ scripts/config -e CONFIG_PPC_KUAP -e CONFIG_PPC_KUAP_DEBUG -d CONFIG_VMAP_STACK
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux
$ egrep "CONFIG_PPC_KUAP|CONFIG_VMAP_STACK" .config
$ strings vmlinux |grep "Linux version"
Please boot using the same kernel parameters as last time and capture the
serial console logs. In case we're still dealing with intermittent bugs it
might be necessary to repeat these tests so I suggest you retain the
vmlinux files.
^ permalink raw reply
* [PATCH v2 4/4] powerpc/64e: Get dear offset with _DEAR macro
From: sxwjean @ 2021-08-07 1:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, aneesh.kumar, oleg, npiggin,
linux-kernel, efremov, paulus
In-Reply-To: <20210807010239.416055-1-sxwjean@me.com>
From: Xiongwei Song <sxwjean@gmail.com>
Use _DEAR to get the offset of dear register in pr_regs for 64e cpus.
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
arch/powerpc/kernel/asm-offsets.c | 13 +++----------
arch/powerpc/kernel/exceptions-64e.S | 8 ++++----
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index f4ebc435fd78..8357d5fcd09e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -286,23 +286,16 @@ int main(void)
STACK_PT_REGS_OFFSET(_CCR, ccr);
STACK_PT_REGS_OFFSET(_XER, xer);
STACK_PT_REGS_OFFSET(_DAR, dar);
+ STACK_PT_REGS_OFFSET(_DEAR, dear);
STACK_PT_REGS_OFFSET(_DSISR, dsisr);
STACK_PT_REGS_OFFSET(_ESR, esr);
STACK_PT_REGS_OFFSET(ORIG_GPR3, orig_gpr3);
STACK_PT_REGS_OFFSET(RESULT, result);
STACK_PT_REGS_OFFSET(_TRAP, trap);
-#ifndef CONFIG_PPC64
- /*
- * The PowerPC 400-class & Book-E processors have neither the DAR
- * nor the DSISR SPRs. Hence, we overload them to hold the similar
- * DEAR and ESR SPRs for such processors. For critical interrupts
- * we use them to hold SRR0 and SRR1.
- */
- STACK_PT_REGS_OFFSET(_DEAR, dar);
-#else /* CONFIG_PPC64 */
+#ifdef CONFIG_PPC64
STACK_PT_REGS_OFFSET(SOFTE, softe);
STACK_PT_REGS_OFFSET(_PPR, ppr);
-#endif /* CONFIG_PPC64 */
+#endif
#ifdef CONFIG_PPC_PKEY
STACK_PT_REGS_OFFSET(STACK_REGS_AMR, amr);
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index bf8c4c2f98ea..221e085e8c8c 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -545,7 +545,7 @@ __end_interrupts:
PROLOG_ADDITION_2REGS)
mfspr r14,SPRN_DEAR
mfspr r15,SPRN_ESR
- std r14,_DAR(r1)
+ std r14,_DEAR(r1)
std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
@@ -558,7 +558,7 @@ __end_interrupts:
PROLOG_ADDITION_2REGS)
li r15,0
mr r14,r10
- std r14,_DAR(r1)
+ std r14,_DEAR(r1)
std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
@@ -575,7 +575,7 @@ __end_interrupts:
PROLOG_ADDITION_2REGS)
mfspr r14,SPRN_DEAR
mfspr r15,SPRN_ESR
- std r14,_DAR(r1)
+ std r14,_DEAR(r1)
std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
@@ -1057,7 +1057,7 @@ bad_stack_book3e:
std r11,_CCR(r1)
mfspr r10,SPRN_DEAR
mfspr r11,SPRN_ESR
- std r10,_DAR(r1)
+ std r10,_DEAR(r1)
std r11,_ESR(r1)
std r0,GPR0(r1); /* save r0 in stackframe */ \
std r2,GPR2(r1); /* save r2 in stackframe */ \
--
2.30.2
^ permalink raw reply related
* [PATCH v2 3/4] powerpc: Optimize register usage for dear register
From: sxwjean @ 2021-08-07 1:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, aneesh.kumar, oleg, npiggin,
linux-kernel, efremov, paulus
In-Reply-To: <20210807010239.416055-1-sxwjean@me.com>
From: Xiongwei Song <sxwjean@gmail.com>
Create an anonymous union for dar and dear regsiters, we can reference
dear to get the effective address when CONFIG_4xx=y or CONFIG_BOOKE=y.
Otherwise, reference dar. This makes code more clear.
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
arch/powerpc/include/asm/ptrace.h | 5 ++++-
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace.c | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index c252d04b1206..fa725e3238c2 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -43,7 +43,10 @@ struct pt_regs
unsigned long mq;
#endif
unsigned long trap;
- unsigned long dar;
+ union {
+ unsigned long dar;
+ unsigned long dear;
+ };
union {
unsigned long dsisr;
unsigned long esr;
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index f74af8f9133c..50436b52c213 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1499,7 +1499,7 @@ static void __show_regs(struct pt_regs *regs)
trap == INTERRUPT_DATA_STORAGE ||
trap == INTERRUPT_ALIGNMENT) {
if (IS_ENABLED(CONFIG_4xx) || IS_ENABLED(CONFIG_BOOKE))
- pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->esr);
+ pr_cont("DEAR: "REG" ESR: "REG" ", regs->dear, regs->esr);
else
pr_cont("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
}
diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c
index a222fd4d6334..7c7093c17c45 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -373,6 +373,8 @@ void __init pt_regs_check(void)
offsetof(struct user_pt_regs, trap));
BUILD_BUG_ON(offsetof(struct pt_regs, dar) !=
offsetof(struct user_pt_regs, dar));
+ BUILD_BUG_ON(offsetof(struct pt_regs, dear) !=
+ offsetof(struct user_pt_regs, dar));
BUILD_BUG_ON(offsetof(struct pt_regs, dsisr) !=
offsetof(struct user_pt_regs, dsisr));
BUILD_BUG_ON(offsetof(struct pt_regs, esr) !=
--
2.30.2
^ permalink raw reply related
* [PATCH v2 2/4] powerpc/64e: Get esr offset with _ESR macro
From: sxwjean @ 2021-08-07 1:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, aneesh.kumar, oleg, npiggin,
linux-kernel, efremov, paulus
In-Reply-To: <20210807010239.416055-1-sxwjean@me.com>
From: Xiongwei Song <sxwjean@gmail.com>
Use _ESR to get the offset of esr register in pr_regs for 64e cpus.
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/exceptions-64e.S | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index a47eefa09bcb..f4ebc435fd78 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -287,6 +287,7 @@ int main(void)
STACK_PT_REGS_OFFSET(_XER, xer);
STACK_PT_REGS_OFFSET(_DAR, dar);
STACK_PT_REGS_OFFSET(_DSISR, dsisr);
+ STACK_PT_REGS_OFFSET(_ESR, esr);
STACK_PT_REGS_OFFSET(ORIG_GPR3, orig_gpr3);
STACK_PT_REGS_OFFSET(RESULT, result);
STACK_PT_REGS_OFFSET(_TRAP, trap);
@@ -298,7 +299,6 @@ int main(void)
* we use them to hold SRR0 and SRR1.
*/
STACK_PT_REGS_OFFSET(_DEAR, dar);
- STACK_PT_REGS_OFFSET(_ESR, dsisr);
#else /* CONFIG_PPC64 */
STACK_PT_REGS_OFFSET(SOFTE, softe);
STACK_PT_REGS_OFFSET(_PPR, ppr);
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 1401787b0b93..bf8c4c2f98ea 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -546,7 +546,7 @@ __end_interrupts:
mfspr r14,SPRN_DEAR
mfspr r15,SPRN_ESR
std r14,_DAR(r1)
- std r15,_DSISR(r1)
+ std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x300)
@@ -559,7 +559,7 @@ __end_interrupts:
li r15,0
mr r14,r10
std r14,_DAR(r1)
- std r15,_DSISR(r1)
+ std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x400)
@@ -576,7 +576,7 @@ __end_interrupts:
mfspr r14,SPRN_DEAR
mfspr r15,SPRN_ESR
std r14,_DAR(r1)
- std r15,_DSISR(r1)
+ std r15,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
ld r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x600)
@@ -587,7 +587,7 @@ __end_interrupts:
NORMAL_EXCEPTION_PROLOG(0x700, BOOKE_INTERRUPT_PROGRAM,
PROLOG_ADDITION_1REG)
mfspr r14,SPRN_ESR
- std r14,_DSISR(r1)
+ std r14,_ESR(r1)
ld r14,PACA_EXGEN+EX_R14(r13)
EXCEPTION_COMMON(0x700)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -1058,7 +1058,7 @@ bad_stack_book3e:
mfspr r10,SPRN_DEAR
mfspr r11,SPRN_ESR
std r10,_DAR(r1)
- std r11,_DSISR(r1)
+ std r11,_ESR(r1)
std r0,GPR0(r1); /* save r0 in stackframe */ \
std r2,GPR2(r1); /* save r2 in stackframe */ \
SAVE_4GPRS(3, r1); /* save r3 - r6 in stackframe */ \
--
2.30.2
^ permalink raw reply related
* [PATCH v2 1/4] powerpc: Optimize register usage for esr register
From: sxwjean @ 2021-08-07 1:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, aneesh.kumar, oleg, npiggin,
linux-kernel, efremov, paulus
In-Reply-To: <20210807010239.416055-1-sxwjean@me.com>
From: Xiongwei Song <sxwjean@gmail.com>
Create an anonymous union for dsisr and esr regsiters, we can reference
esr to get the exception detail when CONFIG_4xx=y or CONFIG_BOOKE=y.
Otherwise, reference dsisr. This makes code more clear.
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
arch/powerpc/include/asm/ptrace.h | 5 ++++-
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace.c | 2 ++
arch/powerpc/kernel/traps.c | 2 +-
arch/powerpc/platforms/44x/machine_check.c | 4 ++--
arch/powerpc/platforms/4xx/machine_check.c | 2 +-
6 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 3e5d470a6155..c252d04b1206 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -44,7 +44,10 @@ struct pt_regs
#endif
unsigned long trap;
unsigned long dar;
- unsigned long dsisr;
+ union {
+ unsigned long dsisr;
+ unsigned long esr;
+ };
unsigned long result;
};
};
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 185beb290580..f74af8f9133c 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1499,7 +1499,7 @@ static void __show_regs(struct pt_regs *regs)
trap == INTERRUPT_DATA_STORAGE ||
trap == INTERRUPT_ALIGNMENT) {
if (IS_ENABLED(CONFIG_4xx) || IS_ENABLED(CONFIG_BOOKE))
- pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->dsisr);
+ pr_cont("DEAR: "REG" ESR: "REG" ", regs->dar, regs->esr);
else
pr_cont("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
}
diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c
index 0a0a33eb0d28..a222fd4d6334 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -375,6 +375,8 @@ void __init pt_regs_check(void)
offsetof(struct user_pt_regs, dar));
BUILD_BUG_ON(offsetof(struct pt_regs, dsisr) !=
offsetof(struct user_pt_regs, dsisr));
+ BUILD_BUG_ON(offsetof(struct pt_regs, esr) !=
+ offsetof(struct user_pt_regs, dsisr));
BUILD_BUG_ON(offsetof(struct pt_regs, result) !=
offsetof(struct user_pt_regs, result));
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index dfbce527c98e..2164f5705a0b 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -562,7 +562,7 @@ static inline int check_io_access(struct pt_regs *regs)
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/* On 4xx, the reason for the machine check or program exception
is in the ESR. */
-#define get_reason(regs) ((regs)->dsisr)
+#define get_reason(regs) ((regs)->esr)
#define REASON_FP ESR_FP
#define REASON_ILLEGAL (ESR_PIL | ESR_PUO)
#define REASON_PRIVILEGED ESR_PPR
diff --git a/arch/powerpc/platforms/44x/machine_check.c b/arch/powerpc/platforms/44x/machine_check.c
index a5c898bb9bab..5d19daacd78a 100644
--- a/arch/powerpc/platforms/44x/machine_check.c
+++ b/arch/powerpc/platforms/44x/machine_check.c
@@ -11,7 +11,7 @@
int machine_check_440A(struct pt_regs *regs)
{
- unsigned long reason = regs->dsisr;
+ unsigned long reason = regs->esr;
printk("Machine check in kernel mode.\n");
if (reason & ESR_IMCP){
@@ -48,7 +48,7 @@ int machine_check_440A(struct pt_regs *regs)
#ifdef CONFIG_PPC_47x
int machine_check_47x(struct pt_regs *regs)
{
- unsigned long reason = regs->dsisr;
+ unsigned long reason = regs->esr;
u32 mcsr;
printk(KERN_ERR "Machine check in kernel mode.\n");
diff --git a/arch/powerpc/platforms/4xx/machine_check.c b/arch/powerpc/platforms/4xx/machine_check.c
index a71c29892a91..a905da1d6f41 100644
--- a/arch/powerpc/platforms/4xx/machine_check.c
+++ b/arch/powerpc/platforms/4xx/machine_check.c
@@ -10,7 +10,7 @@
int machine_check_4xx(struct pt_regs *regs)
{
- unsigned long reason = regs->dsisr;
+ unsigned long reason = regs->esr;
if (reason & ESR_IMCP) {
printk("Instruction");
--
2.30.2
^ permalink raw reply related
* [PATCH v2 0/4] Some improvements on regs usage
From: sxwjean @ 2021-08-07 1:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: ravi.bangoria, Xiongwei Song, aneesh.kumar, oleg, npiggin,
linux-kernel, efremov, paulus
From: Xiongwei Song <sxwjean@gmail.com>
When CONFIG_4xx=y or CONFIG_BOOKE=y, currently in code we reference dsisr
to get interrupt reasons and reference dar to get excepiton address.
However, in reference manuals, esr is used for interrupt reasons and dear
is used for excepiton address, so the patchset changes dsisr -> esr,
dar -> dear for CONFIG_4xx=y or CONFIG_BOOKE=y.
Meanwhile, we use _ESR and _DEAR to get offsets of esr and dear on stack.
v2:
- Discard changes in arch/powerpc/mm/fault.c as Christophe and Michael
suggested.
- Discard changes in UAPI headers to avoid possible compile issue.
v1:
- https://lkml.org/lkml/2021/8/6/57
- https://lkml.org/lkml/2021/7/26/533
- https://lkml.org/lkml/2021/7/26/534
- https://lkml.org/lkml/2021/7/26/535
Xiongwei Song (4):
powerpc: Optimize register usage for esr register
powerpc/64e: Get esr offset with _ESR macro
powerpc: Optimize register usage for dear register
powerpc/64e: Get dear offset with _DEAR macro
arch/powerpc/include/asm/ptrace.h | 10 ++++++++--
arch/powerpc/kernel/asm-offsets.c | 15 ++++-----------
arch/powerpc/kernel/exceptions-64e.S | 18 +++++++++---------
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace.c | 4 ++++
arch/powerpc/kernel/traps.c | 2 +-
arch/powerpc/platforms/44x/machine_check.c | 4 ++--
arch/powerpc/platforms/4xx/machine_check.c | 2 +-
8 files changed, 30 insertions(+), 27 deletions(-)
--
2.30.2
^ permalink raw reply
* Re: [PATCH v2 0/6] PCI: Drop duplicated tracking of a pci_dev's bound driver
From: Bjorn Helgaas @ 2021-08-06 21:24 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, Giovanni Cabiddu, Rafał Miłecki,
Peter Zijlstra, linux-pci, Alexander Duyck, x86, oss-drivers,
netdev, Paul Mackerras, H. Peter Anvin, Jiri Olsa,
Thomas Gleixner, Taras Chornyi, Stefano Stabellini, Herbert Xu,
linux-scsi, Sathya Prakash, qat-linux, Alexander Shishkin,
Ingo Molnar, Jakub Kicinski, Yisen Zhuang,
Suganath Prabu Subramani, Fiona Trahe, Oliver O'Halloran,
Andrew Donnellan, Mathias Nyman, Konrad Rzeszutek Wilk,
Ido Schimmel, Arnaldo Carvalho de Melo, Frederic Barrat,
Borislav Petkov, Michael Buesch, Jiri Pirko, Bjorn Helgaas,
Namhyung Kim, Boris Ostrovsky, Andy Shevchenko, Juergen Gross,
Salil Mehta, Sreekanth Reddy, xen-devel, Vadym Kochan,
MPT-FusionLinux.pdl, linux-usb, linux-wireless, linux-kernel,
linux-perf-users, Zhou Wang, Arnd Bergmann, linux-crypto, kernel,
Greg Kroah-Hartman, Simon Horman, Wojciech Ziemba, linuxppc-dev,
David S. Miller
In-Reply-To: <20210806064623.3lxl4clzbjpmchef@pengutronix.de>
On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > not the only offender here. At least the following also have a driver
> > pointer in the device struct:
> >
> > parisc_device.driver
> > acpi_device.driver
> > dio_dev.driver
> > hid_device.driver
> > pci_dev.driver
> > pnp_dev.driver
> > rio_dev.driver
> > zorro_dev.driver
>
> Right, when I converted zorro_dev it was pointed out that the code was
> copied from pci and the latter has the same construct. :-)
> See
> https://lore.kernel.org/r/20210730191035.1455248-5-u.kleine-koenig@pengutronix.de
> for the patch, I don't find where pci was pointed out, maybe it was on
> irc only.
Oh, thanks! I looked to see if you'd done something similar
elsewhere, but I missed this one.
> > Looking through the places that care about pci_dev.driver (the ones
> > updated by patch 5/6), many of them are ... a little dubious to begin
> > with. A few need the "struct pci_error_handlers *err_handler"
> > pointer, so that's probably legitimate. But many just need a name,
> > and should probably be using dev_driver_string() instead.
>
> Yeah, I considered adding a function to get the driver name from a
> pci_dev and a function to get the error handlers. Maybe it's an idea to
> introduce these two and then use to_pci_driver(pdev->dev.driver) for the
> few remaining users? Maybe doing that on top of my current series makes
> sense to have a clean switch from pdev->driver to pdev->dev.driver?!
I'd propose using dev_driver_string() for these places:
eeh_driver_name() (could change callers to use dev_driver_string())
bcma_host_pci_probe()
qm_alloc_uacce()
hns3_get_drvinfo()
prestera_pci_probe()
mlxsw_pci_probe()
nfp_get_drvinfo()
ssb_pcihost_probe()
The use in mpt_device_driver_register() looks unnecessary: it's only
to get a struct pci_device_id *, which is passed to ->probe()
functions that don't need it.
The use in adf_enable_aer() looks wrong: it sets the err_handler
pointer in one of the adf_driver structs. I think those structs
should be basically immutable, and the drivers that call
adf_enable_aer() from their .probe() methods should set
".err_handler = &adf_err_handler" in their static adf_driver
definitions instead.
I think that basically leaves these:
uncore_pci_probe() # .id_table, custom driver "registration"
match_id() # .id_table, arch/x86/kernel/probe_roms.c
xhci_pci_quirks() # .id_table
pci_error_handlers() # roll-your-own AER handling, drivers/misc/cxl/guest.c
I think it would be fine to use to_pci_driver(pdev->dev.driver) for
these few.
Bjorn
^ permalink raw reply
* RE: [PATCH v4] soc: fsl: qe: convert QE interrupt controller to platform_device
From: Leo Li @ 2021-08-06 23:42 UTC (permalink / raw)
To: Maxim Kochetkov, linuxppc-dev@lists.ozlabs.org
Cc: kernel test robot, saravanak@google.com,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
Dan Carpenter, linux-arm-kernel@lists.infradead.org, Qiang Zhao
In-Reply-To: <20210803113538.560277-1-fido_max@inbox.ru>
> -----Original Message-----
> From: Maxim Kochetkov <fido_max@inbox.ru>
> Sent: Tuesday, August 3, 2021 6:36 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Qiang Zhao <qiang.zhao@nxp.com>; Leo Li <leoyang.li@nxp.com>;
> gregkh@linuxfoundation.org; saravanak@google.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Maxim Kochetkov
> <fido_max@inbox.ru>; kernel test robot <lkp@intel.com>; Dan Carpenter
> <dan.carpenter@oracle.com>
> Subject: [PATCH v4] soc: fsl: qe: convert QE interrupt controller to
> platform_device
>
> Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
>
> ucc@2000 {
> cell-index = <1>;
> reg = <0x2000 0x200>;
> interrupts = <32>;
> interrupt-parent = <&qeic>;
> };
>
> Now fw_devlink expects driver to create and probe a struct device for
> interrupt controller.
>
> So lets convert this driver to simple platform_device with probe().
> Also use platform_get_ and devm_ family function to get/allocate resources
> and drop unused .compatible = "qeic".
>
> [1] -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Flkml%2FCAGETcx9PiX%3D%3DmLxB9PO8Myyk6u2vhPVwTMsA
> 5NkD-
> ywH5xhusw%40mail.gmail.com&data=04%7C01%7Cleoyang.li%40nxp.co
> m%7C1833b32e26de4ed7ef7908d956728eae%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C0%7C637635872281355718%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C1000&sdata=HrivK73GYFAwygPz24JtO%2BTdkicCVYXOl3uywjOqS
> %2BA%3D&reserved=0
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by
> default""")
> Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied to fix. Thanks.
> ---
> drivers/soc/fsl/qe/qe_ic.c | 75 ++++++++++++++++++++++----------------
> 1 file changed, 44 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c index
> 3f711c1a0996..e710d554425d 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -23,6 +23,7 @@
> #include <linux/signal.h>
> #include <linux/device.h>
> #include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> #include <soc/fsl/qe/qe.h>
> @@ -404,41 +405,40 @@ static void qe_ic_cascade_muxed_mpic(struct
> irq_desc *desc)
> chip->irq_eoi(&desc->irq_data);
> }
>
> -static void __init qe_ic_init(struct device_node *node)
> +static int qe_ic_init(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> void (*low_handler)(struct irq_desc *desc);
> void (*high_handler)(struct irq_desc *desc);
> struct qe_ic *qe_ic;
> - struct resource res;
> - u32 ret;
> + struct resource *res;
> + struct device_node *node = pdev->dev.of_node;
>
> - ret = of_address_to_resource(node, 0, &res);
> - if (ret)
> - return;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + dev_err(dev, "no memory resource defined\n");
> + return -ENODEV;
> + }
>
> - qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
> + qe_ic = devm_kzalloc(dev, sizeof(*qe_ic), GFP_KERNEL);
> if (qe_ic == NULL)
> - return;
> + return -ENOMEM;
>
> - qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> - &qe_ic_host_ops, qe_ic);
> - if (qe_ic->irqhost == NULL) {
> - kfree(qe_ic);
> - return;
> + qe_ic->regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (qe_ic->regs == NULL) {
> + dev_err(dev, "failed to ioremap() registers\n");
> + return -ENODEV;
> }
>
> - qe_ic->regs = ioremap(res.start, resource_size(&res));
> -
> qe_ic->hc_irq = qe_ic_irq_chip;
>
> - qe_ic->virq_high = irq_of_parse_and_map(node, 0);
> - qe_ic->virq_low = irq_of_parse_and_map(node, 1);
> + qe_ic->virq_high = platform_get_irq(pdev, 0);
> + qe_ic->virq_low = platform_get_irq(pdev, 1);
>
> - if (!qe_ic->virq_low) {
> - printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
> - kfree(qe_ic);
> - return;
> + if (qe_ic->virq_low < 0) {
> + return -ENODEV;
> }
> +
> if (qe_ic->virq_high != qe_ic->virq_low) {
> low_handler = qe_ic_cascade_low;
> high_handler = qe_ic_cascade_high;
> @@ -447,6 +447,13 @@ static void __init qe_ic_init(struct device_node
> *node)
> high_handler = NULL;
> }
>
> + qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> + &qe_ic_host_ops, qe_ic);
> + if (qe_ic->irqhost == NULL) {
> + dev_err(dev, "failed to add irq domain\n");
> + return -ENODEV;
> + }
> +
> qe_ic_write(qe_ic->regs, QEIC_CICR, 0);
>
> irq_set_handler_data(qe_ic->virq_low, qe_ic); @@ -456,20 +463,26
> @@ static void __init qe_ic_init(struct device_node *node)
> irq_set_handler_data(qe_ic->virq_high, qe_ic);
> irq_set_chained_handler(qe_ic->virq_high, high_handler);
> }
> + return 0;
> }
> +static const struct of_device_id qe_ic_ids[] = {
> + { .compatible = "fsl,qe-ic"},
> + { .type = "qeic"},
> + {},
> +};
>
> -static int __init qe_ic_of_init(void)
> +static struct platform_driver qe_ic_driver =
> {
> - struct device_node *np;
> + .driver = {
> + .name = "qe-ic",
> + .of_match_table = qe_ic_ids,
> + },
> + .probe = qe_ic_init,
> +};
>
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (!np) {
> - np = of_find_node_by_type(NULL, "qeic");
> - if (!np)
> - return -ENODEV;
> - }
> - qe_ic_init(np);
> - of_node_put(np);
> +static int __init qe_ic_of_init(void)
> +{
> + platform_driver_register(&qe_ic_driver);
> return 0;
> }
> subsys_initcall(qe_ic_of_init);
> --
> 2.31.1
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
From: Rob Herring @ 2021-08-06 21:07 UTC (permalink / raw)
To: Emmanuel Gil Peyrot
Cc: devicetree, linux-kernel, Rob Herring, Paul Mackerras, Ash Logan,
Srinivas Kandagatla, linuxppc-dev, Jonathan Neuschäfer
In-Reply-To: <20210801073822.12452-3-linkmauve@linkmauve.fr>
On Sun, 01 Aug 2021 09:38:19 +0200, Emmanuel Gil Peyrot wrote:
> Both of these consoles use the exact same two registers, even at the
> same address, but the Wii U has eight banks of 128 bytes memory while
> the Wii only has one, hence the two compatible strings.
>
> Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> ---
> .../bindings/nvmem/nintendo-otp.yaml | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
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