* [PATCH 2/2] powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race
From: Paul Mackerras @ 2019-08-12 5:07 UTC (permalink / raw)
To: linuxppc-dev, kvm; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20190812050623.ltla46gh5futsqv4@oak.ozlabs.ibm.com>
Testing has revealed the existence of a race condition where a XIVE
interrupt being shut down can be in one of the XIVE interrupt queues
(of which there are up to 8 per CPU, one for each priority) at the
point where free_irq() is called. If this happens, can return an
interrupt number which has been shut down. This can lead to various
symptoms:
- irq_to_desc(irq) can be NULL. In this case, no end-of-interrupt
function gets called, resulting in the CPU's elevated interrupt
priority (numerically lowered CPPR) never gets reset. That then
means that the CPU stops processing interrupts, causing device
timeouts and other errors in various device drivers.
- The irq descriptor or related data structures can be in the process
of being freed as the interrupt code is using them. This typically
leads to crashes due to bad pointer dereferences.
This race is basically what commit 62e0468650c3 ("genirq: Add optional
hardware synchronization for shutdown", 2019-06-28) is intended to
fix, given a get_irqchip_state() method for the interrupt controller
being used. It works by polling the interrupt controller when an
interrupt is being freed until the controller says it is not pending.
With XIVE, the PQ bits of the interrupt source indicate the state of
the interrupt source, and in particular the P bit goes from 0 to 1 at
the point where the hardware writes an entry into the interrupt queue
that this interrupt is directed towards. Normally, the code will then
process the interrupt and do an end-of-interrupt (EOI) operation which
will reset PQ to 00 (assuming another interrupt hasn't been generated
in the meantime). However, there are situations where the code resets
P even though a queue entry exists (for example, by setting PQ to 01,
which disables the interrupt source), and also situations where the
code leaves P at 1 after removing the queue entry (for example, this
is done for escalation interrupts so they cannot fire again until
they are explicitly re-enabled).
The code already has a 'saved_p' flag for the interrupt source which
indicates that a queue entry exists, although it isn't maintained
consistently. This patch adds a 'stale_p' flag to indicate that
P has been left at 1 after processing a queue entry, and adds code
to set and clear saved_p and stale_p as necessary to maintain a
consistent indication of whether a queue entry may or may not exist.
With this, we can implement xive_get_irqchip_state() by looking at
stale_p, saved_p and the ESB PQ bits for the interrupt.
There is some additional code to handle escalation interrupts properly;
because they are enabled and disabled in KVM assembly code, which does
not have access to the xive_irq_data struct for the escalation
interrupt. Hence, stale_p may be incorrect when the escalation
interrupt is freed in kvmppc_xive_cleanup_vcpu(). Fortunately, we
can fix it up by looking at vcpu->arch.xive_esc_on, with some
careful attention to barriers in order to ensure the correct result
if xive_esc_irq() races with kvmppc_xive_cleanup_vcpu().
Finally, this adds code to make noise on the console (pr_crit and
WARN_ON(1)) if we find an interrupt queue entry for an interrupt
which does not have a descriptor. While this won't catch the race
reliably, if it does get triggered it will be an indication that
the race is occurring and needs to be debugged.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/include/asm/xive.h | 8 ++++
arch/powerpc/kvm/book3s_xive.c | 31 ++++++++++++++
arch/powerpc/sysdev/xive/common.c | 87 ++++++++++++++++++++++++++++-----------
3 files changed, 103 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index e4016985764e..efb0e597b272 100644
--- a/arch/powerpc/include/asm/xive.h
+++ b/arch/powerpc/include/asm/xive.h
@@ -46,7 +46,15 @@ struct xive_irq_data {
/* Setup/used by frontend */
int target;
+ /*
+ * saved_p means that there is a queue entry for this interrupt
+ * in some CPU's queue (not including guest vcpu queues), even
+ * if P is not set in the source ESB.
+ * stale_p means that there is no queue entry for this interrupt
+ * in some CPU's queue, even if P is set in the source ESB.
+ */
bool saved_p;
+ bool stale_p;
};
#define XIVE_IRQ_FLAG_STORE_EOI 0x01
#define XIVE_IRQ_FLAG_LSI 0x02
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index 09f838aa3138..74eea009c095 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -160,6 +160,9 @@ static irqreturn_t xive_esc_irq(int irq, void *data)
*/
vcpu->arch.xive_esc_on = false;
+ /* This orders xive_esc_on = false vs. subsequent stale_p = true */
+ smp_wmb(); /* goes with smp_mb() in cleanup_single_escalation */
+
return IRQ_HANDLED;
}
@@ -1113,6 +1116,31 @@ void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu)
vcpu->arch.xive_esc_raddr = 0;
}
+/*
+ * In single escalation mode, the escalation interrupt is marked so
+ * that EOI doesn't re-enable it, but just sets the stale_p flag to
+ * indicate that the P bit has already been dealt with. However, the
+ * assembly code that enters the guest sets PQ to 00 without clearing
+ * stale_p (because it has no easy way to address it). Hence we have
+ * to adjust stale_p before shutting down the interrupt.
+ */
+static void cleanup_single_escalation(struct kvm_vcpu *vcpu,
+ struct kvmppc_xive_vcpu *xc, int irq)
+{
+ struct irq_data *d = irq_get_irq_data(irq);
+ struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
+
+ /*
+ * This slightly odd sequence gives the right result
+ * (i.e. stale_p set if xive_esc_on is false) even if
+ * we race with xive_esc_irq() and xive_irq_eoi().
+ */
+ xd->stale_p = false;
+ smp_mb(); /* paired with smb_wmb in xive_esc_irq */
+ if (!vcpu->arch.xive_esc_on)
+ xd->stale_p = true;
+}
+
void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
{
struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
@@ -1137,6 +1165,9 @@ void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
/* Free escalations */
for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) {
if (xc->esc_virq[i]) {
+ if (xc->xive->single_escalation)
+ cleanup_single_escalation(vcpu, xc,
+ xc->esc_virq[i]);
free_irq(xc->esc_virq[i], vcpu);
irq_dispose_mapping(xc->esc_virq[i]);
kfree(xc->esc_virq_names[i]);
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index 1cdb39575eae..be86fce1a84e 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -135,7 +135,7 @@ static u32 xive_read_eq(struct xive_q *q, bool just_peek)
static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
{
u32 irq = 0;
- u8 prio;
+ u8 prio = 0;
/* Find highest pending priority */
while (xc->pending_prio != 0) {
@@ -148,8 +148,19 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
irq = xive_read_eq(&xc->queue[prio], just_peek);
/* Found something ? That's it */
- if (irq)
- break;
+ if (irq) {
+ if (just_peek || irq_to_desc(irq))
+ break;
+ /*
+ * We should never get here; if we do then we must
+ * have failed to synchronize the interrupt properly
+ * when shutting it down.
+ */
+ pr_crit("xive: got interrupt %d without descriptor, dropping\n",
+ irq);
+ WARN_ON(1);
+ continue;
+ }
/* Clear pending bits */
xc->pending_prio &= ~(1 << prio);
@@ -307,6 +318,7 @@ static void xive_do_queue_eoi(struct xive_cpu *xc)
*/
static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
{
+ xd->stale_p = false;
/* If the XIVE supports the new "store EOI facility, use it */
if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
xive_esb_write(xd, XIVE_ESB_STORE_EOI, 0);
@@ -350,7 +362,7 @@ static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
}
}
-/* irq_chip eoi callback */
+/* irq_chip eoi callback, called with irq descriptor lock held */
static void xive_irq_eoi(struct irq_data *d)
{
struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
@@ -366,6 +378,8 @@ static void xive_irq_eoi(struct irq_data *d)
if (!irqd_irq_disabled(d) && !irqd_is_forwarded_to_vcpu(d) &&
!(xd->flags & XIVE_IRQ_NO_EOI))
xive_do_source_eoi(irqd_to_hwirq(d), xd);
+ else
+ xd->stale_p = true;
/*
* Clear saved_p to indicate that it's no longer occupying
@@ -397,11 +411,16 @@ static void xive_do_source_set_mask(struct xive_irq_data *xd,
*/
if (mask) {
val = xive_esb_read(xd, XIVE_ESB_SET_PQ_01);
- xd->saved_p = !!(val & XIVE_ESB_VAL_P);
- } else if (xd->saved_p)
+ if (!xd->stale_p && !!(val & XIVE_ESB_VAL_P))
+ xd->saved_p = true;
+ xd->stale_p = false;
+ } else if (xd->saved_p) {
xive_esb_read(xd, XIVE_ESB_SET_PQ_10);
- else
+ xd->saved_p = false;
+ } else {
xive_esb_read(xd, XIVE_ESB_SET_PQ_00);
+ xd->stale_p = false;
+ }
}
/*
@@ -541,6 +560,8 @@ static unsigned int xive_irq_startup(struct irq_data *d)
unsigned int hw_irq = (unsigned int)irqd_to_hwirq(d);
int target, rc;
+ xd->saved_p = false;
+ xd->stale_p = false;
pr_devel("xive_irq_startup: irq %d [0x%x] data @%p\n",
d->irq, hw_irq, d);
@@ -587,6 +608,7 @@ static unsigned int xive_irq_startup(struct irq_data *d)
return 0;
}
+/* called with irq descriptor lock held */
static void xive_irq_shutdown(struct irq_data *d)
{
struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
@@ -602,16 +624,6 @@ static void xive_irq_shutdown(struct irq_data *d)
xive_do_source_set_mask(xd, true);
/*
- * The above may have set saved_p. We clear it otherwise it
- * will prevent re-enabling later on. It is ok to forget the
- * fact that the interrupt might be in a queue because we are
- * accounting that already in xive_dec_target_count() and will
- * be re-routing it to a new queue with proper accounting when
- * it's started up again
- */
- xd->saved_p = false;
-
- /*
* Mask the interrupt in HW in the IVT/EAS and set the number
* to be the "bad" IRQ number
*/
@@ -797,6 +809,10 @@ static int xive_irq_retrigger(struct irq_data *d)
return 1;
}
+/*
+ * Caller holds the irq descriptor lock, so this won't be called
+ * concurrently with xive_get_irqchip_state on the same interrupt.
+ */
static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
{
struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
@@ -820,6 +836,10 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
/* Set it to PQ=10 state to prevent further sends */
pq = xive_esb_read(xd, XIVE_ESB_SET_PQ_10);
+ if (!xd->stale_p) {
+ xd->saved_p = !!(pq & XIVE_ESB_VAL_P);
+ xd->stale_p = !xd->saved_p;
+ }
/* No target ? nothing to do */
if (xd->target == XIVE_INVALID_TARGET) {
@@ -827,7 +847,7 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
* An untargetted interrupt should have been
* also masked at the source
*/
- WARN_ON(pq & 2);
+ WARN_ON(xd->saved_p);
return 0;
}
@@ -847,9 +867,8 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
* This saved_p is cleared by the host EOI, when we know
* for sure the queue slot is no longer in use.
*/
- if (pq & 2) {
- pq = xive_esb_read(xd, XIVE_ESB_SET_PQ_11);
- xd->saved_p = true;
+ if (xd->saved_p) {
+ xive_esb_read(xd, XIVE_ESB_SET_PQ_11);
/*
* Sync the XIVE source HW to ensure the interrupt
@@ -862,8 +881,7 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
*/
if (xive_ops->sync_source)
xive_ops->sync_source(hw_irq);
- } else
- xd->saved_p = false;
+ }
} else {
irqd_clr_forwarded_to_vcpu(d);
@@ -914,6 +932,23 @@ static int xive_irq_set_vcpu_affinity(struct irq_data *d, void *state)
return 0;
}
+/* Called with irq descriptor lock held. */
+static int xive_get_irqchip_state(struct irq_data *data,
+ enum irqchip_irq_state which, bool *state)
+{
+ struct xive_irq_data *xd = irq_data_get_irq_handler_data(data);
+
+ switch (which) {
+ case IRQCHIP_STATE_ACTIVE:
+ *state = !xd->stale_p &&
+ (xd->saved_p ||
+ !!(xive_esb_read(xd, XIVE_ESB_GET) & XIVE_ESB_VAL_P));
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
static struct irq_chip xive_irq_chip = {
.name = "XIVE-IRQ",
.irq_startup = xive_irq_startup,
@@ -925,6 +960,7 @@ static struct irq_chip xive_irq_chip = {
.irq_set_type = xive_irq_set_type,
.irq_retrigger = xive_irq_retrigger,
.irq_set_vcpu_affinity = xive_irq_set_vcpu_affinity,
+ .irq_get_irqchip_state = xive_get_irqchip_state,
};
bool is_xive_irq(struct irq_chip *chip)
@@ -1338,6 +1374,11 @@ static void xive_flush_cpu_queue(unsigned int cpu, struct xive_cpu *xc)
xd = irq_desc_get_handler_data(desc);
/*
+ * Clear saved_p to indicate that it's no longer pending
+ */
+ xd->saved_p = false;
+
+ /*
* For LSIs, we EOI, this will cause a resend if it's
* still asserted. Otherwise do an MSI retrigger.
*/
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] powerpc/xive: Fix race condition leading to host crashes and hangs
From: Paul Mackerras @ 2019-08-12 5:06 UTC (permalink / raw)
To: linuxppc-dev, kvm; +Cc: kvm-ppc, David Gibson
This series fixes a race condition that has been observed in testing
on POWER9 machines running KVM guests. An interrupt being freed by
free_irq() can have an instance present in a XIVE interrupt queue,
which can then be presented to the generic interrupt code after the
data structures for it have been freed, leading to a variety of
crashes and hangs.
This series is based on current upstream kernel source plus Cédric Le
Goater's patch "KVM: PPC: Book3S HV: XIVE: Free escalation interrupts
before disabling the VP", which is a pre-requisite for this series.
As it touches both KVM and generic PPC code, this series will probably
go in via Michael Ellerman's powerpc tree.
Paul.
arch/powerpc/include/asm/xive.h | 8 +++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 23 ++++++---
arch/powerpc/kvm/book3s_xive.c | 31 ++++++++++++
arch/powerpc/sysdev/xive/common.c | 87 ++++++++++++++++++++++++---------
4 files changed, 119 insertions(+), 30 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp
From: Christophe Leroy @ 2019-08-12 5:37 UTC (permalink / raw)
To: Nathan Chancellor, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Nick Desaulniers
Cc: clang-built-linux, linuxppc-dev, linux-kernel, stable
In-Reply-To: <20190812023214.107817-1-natechancellor@gmail.com>
Le 12/08/2019 à 04:32, Nathan Chancellor a écrit :
> Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
> setjmp is used") disabled -Wbuiltin-requires-header because of a warning
> about the setjmp and longjmp declarations.
>
> r367387 in clang added another diagnostic around this, complaining that
> there is no jmp_buf declaration.
>
[...]
>
> Cc: stable@vger.kernel.org # 4.19+
> Link: https://github.com/ClangBuiltLinux/linux/issues/625
> Link: https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
[...]
>
> arch/powerpc/kernel/Makefile | 5 +++--
> arch/powerpc/xmon/Makefile | 5 +++--
What about scripts/recordmcount.c and scripts/sortextable.c which
contains calls to setjmp() and longjmp() ?
And arch/um/ ?
Christophe
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ea0c69236789..44e340ed4722 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -5,8 +5,9 @@
>
> CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
>
> -# Disable clang warning for using setjmp without setjmp.h header
> -CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header)
> +# Avoid clang warnings about longjmp and setjmp built-ins (inclusion of setjmp.h and declaration of jmp_buf type)
> +CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header) \
> + $(call cc-disable-warning, incomplete-setjmp-declaration)
>
> ifdef CONFIG_PPC64
> CFLAGS_prom_init.o += $(NO_MINIMAL_TOC)
> diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
> index f142570ad860..53f341391210 100644
> --- a/arch/powerpc/xmon/Makefile
> +++ b/arch/powerpc/xmon/Makefile
> @@ -1,8 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for xmon
>
> -# Disable clang warning for using setjmp without setjmp.h header
> -subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)
> +# Avoid clang warnings about longjmp and setjmp built-ins (inclusion of setjmp.h and declaration of jmp_buf type)
> +subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header) \
> + $(call cc-disable-warning, incomplete-setjmp-declaration)
>
> GCOV_PROFILE := n
> KCOV_INSTRUMENT := n
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Allow flush_icache_range to work across ranges >4GB
From: Christophe Leroy @ 2019-08-12 5:41 UTC (permalink / raw)
To: Alastair D'Silva
Cc: linux-kernel, stable, Paul Mackerras, Greg Kroah-Hartman,
Thomas Gleixner, linuxppc-dev
In-Reply-To: <72a3fca157a508a9f1bc6ea20801b9227d788f1d.camel@au1.ibm.com>
Le 12/08/2019 à 03:19, Alastair D'Silva a écrit :
> On Fri, 2019-08-09 at 10:59 +0200, Christophe Leroy wrote:
>>
>> Le 09/08/2019 à 02:45, Alastair D'Silva a écrit :
>>> From: Alastair D'Silva <alastair@d-silva.org>
>>>
>>> When calling flush_icache_range with a size >4GB, we were masking
>>> off the upper 32 bits, so we would incorrectly flush a range
>>> smaller
>>> than intended.
>>>
>>> This patch replaces the 32 bit shifts with 64 bit ones, so that
>>> the full size is accounted for.
>>>
>>> Heads-up for backporters: the old version of flush_dcache_range is
>>> subject to a similar bug (this has since been replaced with a C
>>> implementation).
>>
>> Can you submit a patch to stable, explaining this ?
>>
>
> This patch was sent to stable too - or did you mean send another patch
> for the stable asm version of flush_dcache_range?
>
Yes I meant a patch for your 'heads-up', in extenso a patch for fixing
flush_dcache_range().
And for this patch, you put stable is copy of the mail, but for it to be
taken into account it needs to also explicitely include a Cc:
stable@vger.kernel.org in the commit message. I guess Michael will add
it for this time.
Christophe
^ permalink raw reply
* Re: [PATCH v4 03/25] powerpc/fadump: Improve fadump documentation
From: Mahesh Jagannath Salgaonkar @ 2019-08-12 6:55 UTC (permalink / raw)
To: Hari Bathini, linuxppc-dev
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Vasant Hegde,
Oliver, Nicholas Piggin, Stewart Smith, Daniel Axtens
In-Reply-To: <156327673568.27462.12962666023309715458.stgit@hbathini.in.ibm.com>
On 7/16/19 5:02 PM, Hari Bathini wrote:
> The figures depicting FADump's (Firmware-Assisted Dump) memory layout
> are missing some finer details like different memory regions and what
> they represent. Improve the documentation by updating those details.
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> Documentation/powerpc/firmware-assisted-dump.txt | 65 ++++++++++++----------
> 1 file changed, 35 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt
> index 0c41d6d..e9b4e3c 100644
> --- a/Documentation/powerpc/firmware-assisted-dump.txt
> +++ b/Documentation/powerpc/firmware-assisted-dump.txt
This will have to be rebased now on firmware-assisted-dump.rst. However
Changes looks good to me.
Thanks,
-Mahesh.
> @@ -74,8 +74,9 @@ as follows:
> there is crash data available from a previous boot. During
> the early boot OS will reserve rest of the memory above
> boot memory size effectively booting with restricted memory
> - size. This will make sure that the second kernel will not
> - touch any of the dump memory area.
> + size. This will make sure that this kernel (also, referred
> + to as second kernel or capture kernel) will not touch any
> + of the dump memory area.
>
> -- User-space tools will read /proc/vmcore to obtain the contents
> of memory, which holds the previous crashed kernel dump in ELF
> @@ -125,48 +126,52 @@ space memory except the user pages that were present in CMA region.
>
> o Memory Reservation during first kernel
>
> - Low memory Top of memory
> - 0 boot memory size |
> - | | |<--Reserved dump area -->| |
> - V V | Permanent Reservation | V
> - +-----------+----------/ /---+---+----+-----------+----+------+
> - | | |CPU|HPTE| DUMP |ELF | |
> - +-----------+----------/ /---+---+----+-----------+----+------+
> - | ^
> - | |
> - \ /
> - -------------------------------------------
> - Boot memory content gets transferred to
> - reserved area by firmware at the time of
> - crash
> + Low memory Top of memory
> + 0 boot memory size |<--Reserved dump area --->| |
> + | | | Permanent Reservation | |
> + V V | (Preserve area) | V
> + +-----------+----------/ /---+---+----+--------+---+----+------+
> + | | |CPU|HPTE| DUMP |HDR|ELF | |
> + +-----------+----------/ /---+---+----+--------+---+----+------+
> + | ^ ^
> + | | |
> + \ / |
> + ----------------------------------- FADump Header
> + Boot memory content gets transferred (meta area)
> + to reserved area by firmware at the
> + time of crash
> +
> Fig. 1
>
> +
> o Memory Reservation during second kernel after crash
>
> - Low memory Top of memory
> - 0 boot memory size |
> - | |<------------- Reserved dump area ----------- -->|
> - V V V
> - +-----------+----------/ /---+---+----+-----------+----+------+
> - | | |CPU|HPTE| DUMP |ELF | |
> - +-----------+----------/ /---+---+----+-----------+----+------+
> + Low memory Top of memory
> + 0 boot memory size |
> + | |<------------- Reserved dump area --------------->|
> + V V |<---- Preserve area ----->| V
> + +-----------+----------/ /---+---+----+--------+---+----+------+
> + | | |CPU|HPTE| DUMP |HDR|ELF | |
> + +-----------+----------/ /---+---+----+--------+---+----+------+
> | |
> V V
> Used by second /proc/vmcore
> kernel to boot
> Fig. 2
>
> -Currently the dump will be copied from /proc/vmcore to a
> -a new file upon user intervention. The dump data available through
> -/proc/vmcore will be in ELF format. Hence the existing kdump
> -infrastructure (kdump scripts) to save the dump works fine with
> -minor modifications.
> +Currently the dump will be copied from /proc/vmcore to a new file upon
> +user intervention. The dump data available through /proc/vmcore will be
> +in ELF format. Hence the existing kdump infrastructure (kdump scripts)
> +to save the dump works fine with minor modifications. KDump scripts on
> +major Distro releases have already been modified to work seemlessly (no
> +user intervention in saving the dump) when FADump is used, instead of
> +KDump, as dump mechanism.
>
> The tools to examine the dump will be same as the ones
> used for kdump.
>
> How to enable firmware-assisted dump (fadump):
> --------------------------------------
> +---------------------------------------------
>
> 1. Set config option CONFIG_FA_DUMP=y and build kernel.
> 2. Boot into linux kernel with 'fadump=on' kernel cmdline option.
> @@ -189,7 +194,7 @@ NOTE: 1. 'fadump_reserve_mem=' parameter has been deprecated. Instead
> old behaviour.
>
> Sysfs/debugfs files:
> -------------
> +-------------------
>
> Firmware-assisted dump feature uses sysfs file system to hold
> the control files and debugfs file to display memory reserved region.
>
^ permalink raw reply
* [PATCH v9 0/7] powerpc: implement machine check safe memcpy
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
During a memcpy from a pmem device, if a machine check exception is
generated we end up in a panic. In case of fsdax read, this should
only result in a -EIO. Avoid MCE by implementing memcpy_mcsafe.
Before this patch series:
```
bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/
[ 7621.714094] Disabling lock debugging due to kernel taint
[ 7621.714099] MCE: CPU0: machine check (Severe) Host UE Load/Store [Not recovered]
[ 7621.714104] MCE: CPU0: NIP: [c000000000088978] memcpy_power7+0x418/0x7e0
[ 7621.714107] MCE: CPU0: Hardware error
[ 7621.714112] opal: Hardware platform error: Unrecoverable Machine Check exception
[ 7621.714118] CPU: 0 PID: 1368 Comm: mount Tainted: G M 5.2.0-rc5-00239-g241e39004581
#50
[ 7621.714123] NIP: c000000000088978 LR: c0000000008e16f8 CTR: 00000000000001de
[ 7621.714129] REGS: c0000000fffbfd70 TRAP: 0200 Tainted: G M
(5.2.0-rc5-00239-g241e39004581)
[ 7621.714131] MSR: 9000000002209033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 24428840 XER: 00040000
[ 7621.714160] CFAR: c0000000000889a8 DAR: deadbeefdeadbeef DSISR: 00008000 IRQMASK: 0
[ 7621.714171] GPR00: 000000000e000000 c0000000f0b8b1e0 c0000000012cf100 c0000000ed8e1100
[ 7621.714186] GPR04: c000020000001100 0000000000010000 0000000000000200 03fffffff1272000
[ 7621.714201] GPR08: 0000000080000000 0000000000000010 0000000000000020 0000000000000030
[ 7621.714216] GPR12: 0000000000000040 00007fffb8c6d390 0000000000000050 0000000000000060
[ 7621.714232] GPR16: 0000000000000070 0000000000000000 0000000000000001 c0000000f0b8b960
[ 7621.714247] GPR20: 0000000000000001 c0000000f0b8b940 0000000000000001 0000000000010000
[ 7621.714262] GPR24: c000000001382560 c00c0000003b6380 c00c0000003b6380 0000000000010000
[ 7621.714277] GPR28: 0000000000000000 0000000000010000 c000020000000000 0000000000010000
[ 7621.714294] NIP [c000000000088978] memcpy_power7+0x418/0x7e0
[ 7621.714298] LR [c0000000008e16f8] pmem_do_bvec+0xf8/0x430
... <snip> ...
```
After this patch series:
```
bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/
[25302.883978] Buffer I/O error on dev pmem0, logical block 0, async page read
[25303.020816] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[25303.021236] EXT4-fs (pmem0): Can't read superblock on 2nd try
[25303.152515] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[25303.284031] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[25304.084100] UDF-fs: bad mount option "dax" or missing value
mount: /mnt/pmem: wrong fs type, bad option, bad superblock on /dev/pmem0, missing codepage or helper
program, or other error.
```
MCE is injected on a pmem address using mambo. The last patch which adds a
nop is only for testing on mambo, where r13 is not restored upon hitting
vector 200.
The memcpy code can be optimised by adding VMX optimizations and GAS macros
can be used to enable code reusablity, which I will send as another series.
---
Change-log:
v9:
* Add a new IRQ work for UE events [mahesh]
* Reorder patches, and copy stable
v8:
* While ignoring UE events, return was used instead of continue.
* Checkpatch fixups for commit log
v7:
* Move schedule_work to be called from irq_work.
v6:
* Don't return pfn, all callees are expecting physical address anyway [nick]
* Patch re-ordering: move exception table patch before memcpy_mcsafe patch [nick]
* Reword commit log for search_exception_tables patch [nick]
v5:
* Don't use search_exception_tables since it searches for module exception tables
also [Nicholas]
* Fix commit message for patch 2 [Nicholas]
v4:
* Squash return remaining bytes patch to memcpy_mcsafe implemtation patch [christophe]
* Access ok should be checked for copy_to_user_mcsafe() [christophe]
v3:
* Drop patch which enables DR/IR for external modules
* Drop notifier call chain, we don't want to do that in real mode
* Return remaining bytes from memcpy_mcsafe correctly
* We no longer restore r13 for simulator tests, rather use a nop at
vector 0x200 [workaround for simulator; not to be merged]
v2:
* Don't set RI bit explicitly [mahesh]
* Re-ordered series to get r13 workaround as the last patch
--
Balbir Singh (2):
powerpc/mce: Fix MCE handling for huge pages
powerpc/memcpy: Add memcpy_mcsafe for pmem
Reza Arbab (1):
powerpc/mce: Make machine_check_ue_event() static
Santosh Sivaraj (4):
powerpc/mce: Schedule work from irq_work
extable: Add function to search only kernel exception table
powerpc/mce: Handle UE event for memcpy_mcsafe
powerpc: add machine check safe copy_to_user
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/mce.h | 6 +-
arch/powerpc/include/asm/string.h | 2 +
arch/powerpc/include/asm/uaccess.h | 14 ++
arch/powerpc/kernel/mce.c | 31 +++-
arch/powerpc/kernel/mce_power.c | 70 ++++----
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/memcpy_mcsafe_64.S | 242 +++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/ras.c | 9 +-
include/linux/extable.h | 2 +
kernel/extable.c | 11 +-
11 files changed, 347 insertions(+), 43 deletions(-)
create mode 100644 arch/powerpc/lib/memcpy_mcsafe_64.S
--
2.21.0
^ permalink raw reply
* [PATCH v9 1/7] powerpc/mce: Schedule work from irq_work
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Mahesh Salgaonkar, Chandan Rajendra, stable, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
schedule_work() cannot be called from MCE exception context as MCE can
interrupt even in interrupt disabled context.
fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
Suggested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Cc: stable@vger.kernel.org # v4.15+
---
arch/powerpc/kernel/mce.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index b18df633eae9..cff31d4a501f 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -33,6 +33,7 @@ static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
mce_ue_event_queue);
static void machine_check_process_queued_event(struct irq_work *work);
+static void machine_check_ue_irq_work(struct irq_work *work);
void machine_check_ue_event(struct machine_check_event *evt);
static void machine_process_ue_event(struct work_struct *work);
@@ -40,6 +41,10 @@ static struct irq_work mce_event_process_work = {
.func = machine_check_process_queued_event,
};
+static struct irq_work mce_ue_event_irq_work = {
+ .func = machine_check_ue_irq_work,
+};
+
DECLARE_WORK(mce_ue_event_work, machine_process_ue_event);
static void mce_set_error_info(struct machine_check_event *mce,
@@ -199,6 +204,10 @@ void release_mce_event(void)
get_mce_event(NULL, true);
}
+static void machine_check_ue_irq_work(struct irq_work *work)
+{
+ schedule_work(&mce_ue_event_work);
+}
/*
* Queue up the MCE event which then can be handled later.
@@ -216,7 +225,7 @@ void machine_check_ue_event(struct machine_check_event *evt)
memcpy(this_cpu_ptr(&mce_ue_event_queue[index]), evt, sizeof(*evt));
/* Queue work to process this event later. */
- schedule_work(&mce_ue_event_work);
+ irq_work_queue(&mce_ue_event_irq_work);
}
/*
--
2.21.0
^ permalink raw reply related
* [PATCH v9 2/7] powerpc/mce: Fix MCE handling for huge pages
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Mahesh Salgaonkar, Chandan Rajendra, stable, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
From: Balbir Singh <bsingharora@gmail.com>
The current code would fail on huge pages addresses, since the shift would
be incorrect. Use the correct page shift value returned by
__find_linux_pte() to get the correct physical address. The code is more
generic and can handle both regular and compound pages.
Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
[arbab@linux.ibm.com: Fixup pseries_do_memory_failure()]
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Co-developed-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # v4.15+
---
arch/powerpc/include/asm/mce.h | 2 +-
arch/powerpc/kernel/mce_power.c | 55 ++++++++++++++--------------
arch/powerpc/platforms/pseries/ras.c | 9 ++---
3 files changed, 32 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index a4c6a74ad2fb..f3a6036b6bc0 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -209,7 +209,7 @@ extern void release_mce_event(void);
extern void machine_check_queue_event(void);
extern void machine_check_print_event_info(struct machine_check_event *evt,
bool user_mode, bool in_guest);
-unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
+unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr);
#ifdef CONFIG_PPC_BOOK3S_64
void flush_and_reload_slb(void);
#endif /* CONFIG_PPC_BOOK3S_64 */
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index a814d2dfb5b0..e74816f045f8 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -20,13 +20,14 @@
#include <asm/exception-64s.h>
/*
- * Convert an address related to an mm to a PFN. NOTE: we are in real
- * mode, we could potentially race with page table updates.
+ * Convert an address related to an mm to a physical address.
+ * NOTE: we are in real mode, we could potentially race with page table updates.
*/
-unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
+unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr)
{
- pte_t *ptep;
- unsigned long flags;
+ pte_t *ptep, pte;
+ unsigned int shift;
+ unsigned long flags, phys_addr;
struct mm_struct *mm;
if (user_mode(regs))
@@ -35,14 +36,21 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
mm = &init_mm;
local_irq_save(flags);
- if (mm == current->mm)
- ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
- else
- ptep = find_init_mm_pte(addr, NULL);
+ ptep = __find_linux_pte(mm->pgd, addr, NULL, &shift);
local_irq_restore(flags);
+
if (!ptep || pte_special(*ptep))
return ULONG_MAX;
- return pte_pfn(*ptep);
+
+ pte = *ptep;
+ if (shift > PAGE_SHIFT) {
+ unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
+
+ pte = __pte(pte_val(pte) | (addr & rpnmask));
+ }
+ phys_addr = pte_pfn(pte) << PAGE_SHIFT;
+
+ return phys_addr;
}
/* flush SLBs and reload */
@@ -344,7 +352,7 @@ static const struct mce_derror_table mce_p9_derror_table[] = {
MCE_INITIATOR_CPU, MCE_SEV_SEVERE, true },
{ 0, false, 0, 0, 0, 0, 0 } };
-static int mce_find_instr_ea_and_pfn(struct pt_regs *regs, uint64_t *addr,
+static int mce_find_instr_ea_and_phys(struct pt_regs *regs, uint64_t *addr,
uint64_t *phys_addr)
{
/*
@@ -354,18 +362,16 @@ static int mce_find_instr_ea_and_pfn(struct pt_regs *regs, uint64_t *addr,
* faults
*/
int instr;
- unsigned long pfn, instr_addr;
+ unsigned long instr_addr;
struct instruction_op op;
struct pt_regs tmp = *regs;
- pfn = addr_to_pfn(regs, regs->nip);
- if (pfn != ULONG_MAX) {
- instr_addr = (pfn << PAGE_SHIFT) + (regs->nip & ~PAGE_MASK);
+ instr_addr = addr_to_phys(regs, regs->nip) + (regs->nip & ~PAGE_MASK);
+ if (instr_addr != ULONG_MAX) {
instr = *(unsigned int *)(instr_addr);
if (!analyse_instr(&op, &tmp, instr)) {
- pfn = addr_to_pfn(regs, op.ea);
*addr = op.ea;
- *phys_addr = (pfn << PAGE_SHIFT);
+ *phys_addr = addr_to_phys(regs, op.ea);
return 0;
}
/*
@@ -440,15 +446,9 @@ static int mce_handle_ierror(struct pt_regs *regs,
*addr = regs->nip;
if (mce_err->sync_error &&
table[i].error_type == MCE_ERROR_TYPE_UE) {
- unsigned long pfn;
-
- if (get_paca()->in_mce < MAX_MCE_DEPTH) {
- pfn = addr_to_pfn(regs, regs->nip);
- if (pfn != ULONG_MAX) {
- *phys_addr =
- (pfn << PAGE_SHIFT);
- }
- }
+ if (get_paca()->in_mce < MAX_MCE_DEPTH)
+ *phys_addr = addr_to_phys(regs,
+ regs->nip);
}
}
return handled;
@@ -541,7 +541,8 @@ static int mce_handle_derror(struct pt_regs *regs,
* kernel/exception-64s.h
*/
if (get_paca()->in_mce < MAX_MCE_DEPTH)
- mce_find_instr_ea_and_pfn(regs, addr, phys_addr);
+ mce_find_instr_ea_and_phys(regs, addr,
+ phys_addr);
}
found = 1;
}
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index f16fdd0f71f7..5743f6353638 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -739,13 +739,10 @@ static void pseries_do_memory_failure(struct pt_regs *regs,
if (mce_log->sub_err_type & UE_LOGICAL_ADDR_PROVIDED) {
paddr = be64_to_cpu(mce_log->logical_address);
} else if (mce_log->sub_err_type & UE_EFFECTIVE_ADDR_PROVIDED) {
- unsigned long pfn;
-
- pfn = addr_to_pfn(regs,
- be64_to_cpu(mce_log->effective_address));
- if (pfn == ULONG_MAX)
+ paddr = addr_to_phys(regs,
+ be64_to_cpu(mce_log->effective_address));
+ if (paddr == ULONG_MAX)
return;
- paddr = pfn << PAGE_SHIFT;
} else {
return;
}
--
2.21.0
^ permalink raw reply related
* [PATCH v9 3/7] powerpc/mce: Make machine_check_ue_event() static
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
From: Reza Arbab <arbab@linux.ibm.com>
The function doesn't get used outside this file, so make it static.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/mce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index cff31d4a501f..a3b122a685a5 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -34,7 +34,7 @@ static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
static void machine_check_process_queued_event(struct irq_work *work);
static void machine_check_ue_irq_work(struct irq_work *work);
-void machine_check_ue_event(struct machine_check_event *evt);
+static void machine_check_ue_event(struct machine_check_event *evt);
static void machine_process_ue_event(struct work_struct *work);
static struct irq_work mce_event_process_work = {
@@ -212,7 +212,7 @@ static void machine_check_ue_irq_work(struct irq_work *work)
/*
* Queue up the MCE event which then can be handled later.
*/
-void machine_check_ue_event(struct machine_check_event *evt)
+static void machine_check_ue_event(struct machine_check_event *evt)
{
int index;
--
2.21.0
^ permalink raw reply related
* [PATCH v9 4/7] extable: Add function to search only kernel exception table
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Thomas Gleixner, Reza Arbab, Ingo Molnar
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
Certain architecture specific operating modes (e.g., in powerpc machine
check handler that is unable to access vmalloc memory), the
search_exception_tables cannot be called because it also searches the
module exception tables if entry is not found in the kernel exception
table.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
include/linux/extable.h | 2 ++
kernel/extable.c | 11 +++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/extable.h b/include/linux/extable.h
index 41c5b3a25f67..81ecfaa83ad3 100644
--- a/include/linux/extable.h
+++ b/include/linux/extable.h
@@ -19,6 +19,8 @@ void trim_init_extable(struct module *m);
/* Given an address, look for it in the exception tables */
const struct exception_table_entry *search_exception_tables(unsigned long add);
+const struct exception_table_entry *
+search_kernel_exception_table(unsigned long addr);
#ifdef CONFIG_MODULES
/* For extable.c to search modules' exception tables. */
diff --git a/kernel/extable.c b/kernel/extable.c
index e23cce6e6092..f6c9406eec7d 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -40,13 +40,20 @@ void __init sort_main_extable(void)
}
}
+/* Given an address, look for it in the kernel exception table */
+const
+struct exception_table_entry *search_kernel_exception_table(unsigned long addr)
+{
+ return search_extable(__start___ex_table,
+ __stop___ex_table - __start___ex_table, addr);
+}
+
/* Given an address, look for it in the exception tables. */
const struct exception_table_entry *search_exception_tables(unsigned long addr)
{
const struct exception_table_entry *e;
- e = search_extable(__start___ex_table,
- __stop___ex_table - __start___ex_table, addr);
+ e = search_kernel_exception_table(addr);
if (!e)
e = search_module_extables(addr);
return e;
--
2.21.0
^ permalink raw reply related
* [PATCH v9 5/7] powerpc/memcpy: Add memcpy_mcsafe for pmem
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
From: Balbir Singh <bsingharora@gmail.com>
The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to
convert machine check exceptions into a return value on failure in case
a machine check exception is encountered during the memcpy. The return
value is the number of bytes remaining to be copied.
This patch largely borrows from the copyuser_power7 logic and does not add
the VMX optimizations, largely to keep the patch simple. If needed those
optimizations can be folded in.
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
[arbab@linux.ibm.com: Added symbol export]
Co-developed-by: Santosh Sivaraj <santosh@fossix.org>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
---
arch/powerpc/include/asm/string.h | 2 +
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/memcpy_mcsafe_64.S | 242 ++++++++++++++++++++++++++++
3 files changed, 245 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/lib/memcpy_mcsafe_64.S
diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h
index 9bf6dffb4090..b72692702f35 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -53,7 +53,9 @@ void *__memmove(void *to, const void *from, __kernel_size_t n);
#ifndef CONFIG_KASAN
#define __HAVE_ARCH_MEMSET32
#define __HAVE_ARCH_MEMSET64
+#define __HAVE_ARCH_MEMCPY_MCSAFE
+extern int memcpy_mcsafe(void *dst, const void *src, __kernel_size_t sz);
extern void *__memset16(uint16_t *, uint16_t v, __kernel_size_t);
extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t);
extern void *__memset64(uint64_t *, uint64_t v, __kernel_size_t);
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index eebc782d89a5..fa6b1b657b43 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \
memcpy_power7.o
obj64-y += copypage_64.o copyuser_64.o mem_64.o hweight_64.o \
- memcpy_64.o pmem.o
+ memcpy_64.o pmem.o memcpy_mcsafe_64.o
obj64-$(CONFIG_SMP) += locks.o
obj64-$(CONFIG_ALTIVEC) += vmx-helper.o
diff --git a/arch/powerpc/lib/memcpy_mcsafe_64.S b/arch/powerpc/lib/memcpy_mcsafe_64.S
new file mode 100644
index 000000000000..949976dc115d
--- /dev/null
+++ b/arch/powerpc/lib/memcpy_mcsafe_64.S
@@ -0,0 +1,242 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) IBM Corporation, 2011
+ * Derived from copyuser_power7.s by Anton Blanchard <anton@au.ibm.com>
+ * Author - Balbir Singh <bsingharora@gmail.com>
+ */
+#include <asm/ppc_asm.h>
+#include <asm/errno.h>
+#include <asm/export.h>
+
+ .macro err1
+100:
+ EX_TABLE(100b,.Ldo_err1)
+ .endm
+
+ .macro err2
+200:
+ EX_TABLE(200b,.Ldo_err2)
+ .endm
+
+ .macro err3
+300: EX_TABLE(300b,.Ldone)
+ .endm
+
+.Ldo_err2:
+ ld r22,STK_REG(R22)(r1)
+ ld r21,STK_REG(R21)(r1)
+ ld r20,STK_REG(R20)(r1)
+ ld r19,STK_REG(R19)(r1)
+ ld r18,STK_REG(R18)(r1)
+ ld r17,STK_REG(R17)(r1)
+ ld r16,STK_REG(R16)(r1)
+ ld r15,STK_REG(R15)(r1)
+ ld r14,STK_REG(R14)(r1)
+ addi r1,r1,STACKFRAMESIZE
+.Ldo_err1:
+ /* Do a byte by byte copy to get the exact remaining size */
+ mtctr r7
+46:
+err3; lbz r0,0(r4)
+ addi r4,r4,1
+err3; stb r0,0(r3)
+ addi r3,r3,1
+ bdnz 46b
+ li r3,0
+ blr
+
+.Ldone:
+ mfctr r3
+ blr
+
+
+_GLOBAL(memcpy_mcsafe)
+ mr r7,r5
+ cmpldi r5,16
+ blt .Lshort_copy
+
+.Lcopy:
+ /* Get the source 8B aligned */
+ neg r6,r4
+ mtocrf 0x01,r6
+ clrldi r6,r6,(64-3)
+
+ bf cr7*4+3,1f
+err1; lbz r0,0(r4)
+ addi r4,r4,1
+err1; stb r0,0(r3)
+ addi r3,r3,1
+ subi r7,r7,1
+
+1: bf cr7*4+2,2f
+err1; lhz r0,0(r4)
+ addi r4,r4,2
+err1; sth r0,0(r3)
+ addi r3,r3,2
+ subi r7,r7,2
+
+2: bf cr7*4+1,3f
+err1; lwz r0,0(r4)
+ addi r4,r4,4
+err1; stw r0,0(r3)
+ addi r3,r3,4
+ subi r7,r7,4
+
+3: sub r5,r5,r6
+ cmpldi r5,128
+ blt 5f
+
+ mflr r0
+ stdu r1,-STACKFRAMESIZE(r1)
+ std r14,STK_REG(R14)(r1)
+ std r15,STK_REG(R15)(r1)
+ std r16,STK_REG(R16)(r1)
+ std r17,STK_REG(R17)(r1)
+ std r18,STK_REG(R18)(r1)
+ std r19,STK_REG(R19)(r1)
+ std r20,STK_REG(R20)(r1)
+ std r21,STK_REG(R21)(r1)
+ std r22,STK_REG(R22)(r1)
+ std r0,STACKFRAMESIZE+16(r1)
+
+ srdi r6,r5,7
+ mtctr r6
+
+ /* Now do cacheline (128B) sized loads and stores. */
+ .align 5
+4:
+err2; ld r0,0(r4)
+err2; ld r6,8(r4)
+err2; ld r8,16(r4)
+err2; ld r9,24(r4)
+err2; ld r10,32(r4)
+err2; ld r11,40(r4)
+err2; ld r12,48(r4)
+err2; ld r14,56(r4)
+err2; ld r15,64(r4)
+err2; ld r16,72(r4)
+err2; ld r17,80(r4)
+err2; ld r18,88(r4)
+err2; ld r19,96(r4)
+err2; ld r20,104(r4)
+err2; ld r21,112(r4)
+err2; ld r22,120(r4)
+ addi r4,r4,128
+err2; std r0,0(r3)
+err2; std r6,8(r3)
+err2; std r8,16(r3)
+err2; std r9,24(r3)
+err2; std r10,32(r3)
+err2; std r11,40(r3)
+err2; std r12,48(r3)
+err2; std r14,56(r3)
+err2; std r15,64(r3)
+err2; std r16,72(r3)
+err2; std r17,80(r3)
+err2; std r18,88(r3)
+err2; std r19,96(r3)
+err2; std r20,104(r3)
+err2; std r21,112(r3)
+err2; std r22,120(r3)
+ addi r3,r3,128
+ subi r7,r7,128
+ bdnz 4b
+
+ clrldi r5,r5,(64-7)
+
+ /* Up to 127B to go */
+5: srdi r6,r5,4
+ mtocrf 0x01,r6
+
+6: bf cr7*4+1,7f
+err2; ld r0,0(r4)
+err2; ld r6,8(r4)
+err2; ld r8,16(r4)
+err2; ld r9,24(r4)
+err2; ld r10,32(r4)
+err2; ld r11,40(r4)
+err2; ld r12,48(r4)
+err2; ld r14,56(r4)
+ addi r4,r4,64
+err2; std r0,0(r3)
+err2; std r6,8(r3)
+err2; std r8,16(r3)
+err2; std r9,24(r3)
+err2; std r10,32(r3)
+err2; std r11,40(r3)
+err2; std r12,48(r3)
+err2; std r14,56(r3)
+ addi r3,r3,64
+ subi r7,r7,64
+
+7: ld r14,STK_REG(R14)(r1)
+ ld r15,STK_REG(R15)(r1)
+ ld r16,STK_REG(R16)(r1)
+ ld r17,STK_REG(R17)(r1)
+ ld r18,STK_REG(R18)(r1)
+ ld r19,STK_REG(R19)(r1)
+ ld r20,STK_REG(R20)(r1)
+ ld r21,STK_REG(R21)(r1)
+ ld r22,STK_REG(R22)(r1)
+ addi r1,r1,STACKFRAMESIZE
+
+ /* Up to 63B to go */
+ bf cr7*4+2,8f
+err1; ld r0,0(r4)
+err1; ld r6,8(r4)
+err1; ld r8,16(r4)
+err1; ld r9,24(r4)
+ addi r4,r4,32
+err1; std r0,0(r3)
+err1; std r6,8(r3)
+err1; std r8,16(r3)
+err1; std r9,24(r3)
+ addi r3,r3,32
+ subi r7,r7,32
+
+ /* Up to 31B to go */
+8: bf cr7*4+3,9f
+err1; ld r0,0(r4)
+err1; ld r6,8(r4)
+ addi r4,r4,16
+err1; std r0,0(r3)
+err1; std r6,8(r3)
+ addi r3,r3,16
+ subi r7,r7,16
+
+9: clrldi r5,r5,(64-4)
+
+ /* Up to 15B to go */
+.Lshort_copy:
+ mtocrf 0x01,r5
+ bf cr7*4+0,12f
+err1; lwz r0,0(r4) /* Less chance of a reject with word ops */
+err1; lwz r6,4(r4)
+ addi r4,r4,8
+err1; stw r0,0(r3)
+err1; stw r6,4(r3)
+ addi r3,r3,8
+ subi r7,r7,8
+
+12: bf cr7*4+1,13f
+err1; lwz r0,0(r4)
+ addi r4,r4,4
+err1; stw r0,0(r3)
+ addi r3,r3,4
+ subi r7,r7,4
+
+13: bf cr7*4+2,14f
+err1; lhz r0,0(r4)
+ addi r4,r4,2
+err1; sth r0,0(r3)
+ addi r3,r3,2
+ subi r7,r7,2
+
+14: bf cr7*4+3,15f
+err1; lbz r0,0(r4)
+err1; stb r0,0(r3)
+
+15: li r3,0
+ blr
+
+EXPORT_SYMBOL_GPL(memcpy_mcsafe);
--
2.21.0
^ permalink raw reply related
* [PATCH v9 6/7] powerpc/mce: Handle UE event for memcpy_mcsafe
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
If we take a UE on one of the instructions with a fixup entry, set nip
to continue execution at the fixup entry. Stop processing the event
further or print it.
Co-developed-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
---
arch/powerpc/include/asm/mce.h | 4 +++-
arch/powerpc/kernel/mce.c | 16 ++++++++++++++++
arch/powerpc/kernel/mce_power.c | 15 +++++++++++++--
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index f3a6036b6bc0..e1931c8c2743 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -122,7 +122,8 @@ struct machine_check_event {
enum MCE_UeErrorType ue_error_type:8;
u8 effective_address_provided;
u8 physical_address_provided;
- u8 reserved_1[5];
+ u8 ignore_event;
+ u8 reserved_1[4];
u64 effective_address;
u64 physical_address;
u8 reserved_2[8];
@@ -193,6 +194,7 @@ struct mce_error_info {
enum MCE_Initiator initiator:8;
enum MCE_ErrorClass error_class:8;
bool sync_error;
+ bool ignore_event;
};
#define MAX_MC_EVT 100
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index a3b122a685a5..ec4b3e1087be 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -149,6 +149,7 @@ void save_mce_event(struct pt_regs *regs, long handled,
if (phys_addr != ULONG_MAX) {
mce->u.ue_error.physical_address_provided = true;
mce->u.ue_error.physical_address = phys_addr;
+ mce->u.ue_error.ignore_event = mce_err->ignore_event;
machine_check_ue_event(mce);
}
}
@@ -266,8 +267,17 @@ static void machine_process_ue_event(struct work_struct *work)
/*
* This should probably queued elsewhere, but
* oh! well
+ *
+ * Don't report this machine check because the caller has a
+ * asked us to ignore the event, it has a fixup handler which
+ * will do the appropriate error handling and reporting.
*/
if (evt->error_type == MCE_ERROR_TYPE_UE) {
+ if (evt->u.ue_error.ignore_event) {
+ __this_cpu_dec(mce_ue_count);
+ continue;
+ }
+
if (evt->u.ue_error.physical_address_provided) {
unsigned long pfn;
@@ -301,6 +311,12 @@ static void machine_check_process_queued_event(struct irq_work *work)
while (__this_cpu_read(mce_queue_count) > 0) {
index = __this_cpu_read(mce_queue_count) - 1;
evt = this_cpu_ptr(&mce_event_queue[index]);
+
+ if (evt->error_type == MCE_ERROR_TYPE_UE &&
+ evt->u.ue_error.ignore_event) {
+ __this_cpu_dec(mce_queue_count);
+ continue;
+ }
machine_check_print_event_info(evt, false, false);
__this_cpu_dec(mce_queue_count);
}
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index e74816f045f8..1dd87f6f5186 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -11,6 +11,7 @@
#include <linux/types.h>
#include <linux/ptrace.h>
+#include <linux/extable.h>
#include <asm/mmu.h>
#include <asm/mce.h>
#include <asm/machdep.h>
@@ -18,6 +19,7 @@
#include <asm/pte-walk.h>
#include <asm/sstep.h>
#include <asm/exception-64s.h>
+#include <asm/extable.h>
/*
* Convert an address related to an mm to a physical address.
@@ -559,9 +561,18 @@ static int mce_handle_derror(struct pt_regs *regs,
return 0;
}
-static long mce_handle_ue_error(struct pt_regs *regs)
+static long mce_handle_ue_error(struct pt_regs *regs,
+ struct mce_error_info *mce_err)
{
long handled = 0;
+ const struct exception_table_entry *entry;
+
+ entry = search_kernel_exception_table(regs->nip);
+ if (entry) {
+ mce_err->ignore_event = true;
+ regs->nip = extable_fixup(entry);
+ return 1;
+ }
/*
* On specific SCOM read via MMIO we may get a machine check
@@ -594,7 +605,7 @@ static long mce_handle_error(struct pt_regs *regs,
&phys_addr);
if (!handled && mce_err.error_type == MCE_ERROR_TYPE_UE)
- handled = mce_handle_ue_error(regs);
+ handled = mce_handle_ue_error(regs, &mce_err);
save_mce_event(regs, handled, &mce_err, regs->nip, addr, phys_addr);
--
2.21.0
^ permalink raw reply related
* [PATCH v9 7/7] powerpc: add machine check safe copy_to_user
From: Santosh Sivaraj @ 2019-08-12 9:22 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190812092236.16648-1-santosh@fossix.org>
Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/uaccess.h | 14 ++++++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 77f6ebf97113..4316e36095a2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -137,6 +137,7 @@ config PPC
select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !RELOCATABLE && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE if PPC64
+ select ARCH_HAS_UACCESS_MCSAFE if PPC64
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_KEEP_MEMBLOCK
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 8b03eb44e876..15002b51ff18 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -387,6 +387,20 @@ static inline unsigned long raw_copy_to_user(void __user *to,
return ret;
}
+static __always_inline unsigned long __must_check
+copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
+{
+ if (likely(check_copy_size(from, n, true))) {
+ if (access_ok(to, n)) {
+ allow_write_to_user(to, n);
+ n = memcpy_mcsafe((void *)to, from, n);
+ prevent_write_to_user(to, n);
+ }
+ }
+
+ return n;
+}
+
extern unsigned long __clear_user(void __user *addr, unsigned long size);
static inline unsigned long clear_user(void __user *addr, unsigned long size)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v4 05/25] pseries/fadump: introduce callbacks for platform specific operations
From: Mahesh J Salgaonkar @ 2019-08-12 9:42 UTC (permalink / raw)
To: Hari Bathini
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Nicholas Piggin,
linuxppc-dev, Oliver, Vasant Hegde, Stewart Smith, Daniel Axtens
In-Reply-To: <156327675065.27462.14816232938604700506.stgit@hbathini.in.ibm.com>
On 2019-07-16 17:02:30 Tue, Hari Bathini wrote:
> Introduce callback functions for platform specific operations like
> register, unregister, invalidate & such. Also, define place-holders
> for the same on pSeries platform.
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> arch/powerpc/kernel/fadump-common.h | 33 ++++++
> arch/powerpc/kernel/fadump.c | 47 +--------
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/rtas-fadump.c | 134 ++++++++++++++++++++++++++
> 4 files changed, 171 insertions(+), 44 deletions(-)
> create mode 100644 arch/powerpc/platforms/pseries/rtas-fadump.c
>
> diff --git a/arch/powerpc/kernel/fadump-common.h b/arch/powerpc/kernel/fadump-common.h
> index 09d6161..020d582 100644
> --- a/arch/powerpc/kernel/fadump-common.h
> +++ b/arch/powerpc/kernel/fadump-common.h
> @@ -50,6 +50,12 @@
> #define FADUMP_UNREGISTER 2
> #define FADUMP_INVALIDATE 3
>
> +/* Firmware-Assited Dump platforms */
> +enum fadump_platform_type {
> + FADUMP_PLATFORM_UNKNOWN = 0,
> + FADUMP_PLATFORM_PSERIES,
> +};
Do we really need these ? Aren't we hiding all platform specific things
under fadump_ops functions ? I see that these values are used only for
assignements and not making any decision in code flow. Am I missing
anything here ?
Thanks,
-Mahesh.
> +
> /*
> * Copy the ascii values for first 8 characters from a string into u64
> * variable at their respective indexes.
> @@ -84,6 +90,9 @@ struct fad_crash_memory_ranges {
> unsigned long long size;
> };
>
> +/* Platform specific callback functions */
> +struct fadump_ops;
> +
> /* Firmware-assisted dump configuration details. */
> struct fw_dump {
> unsigned long reserve_dump_area_start;
> @@ -106,6 +115,21 @@ struct fw_dump {
> unsigned long dump_active:1;
> unsigned long dump_registered:1;
> unsigned long nocma:1;
> +
> + enum fadump_platform_type fadump_platform;
> + struct fadump_ops *ops;
> +};
> +
> +struct fadump_ops {
> + ulong (*init_fadump_mem_struct)(struct fw_dump *fadump_config);
> + int (*register_fadump)(struct fw_dump *fadump_config);
> + int (*unregister_fadump)(struct fw_dump *fadump_config);
> + int (*invalidate_fadump)(struct fw_dump *fadump_config);
> + int (*process_fadump)(struct fw_dump *fadump_config);
> + void (*fadump_region_show)(struct fw_dump *fadump_config,
> + struct seq_file *m);
> + void (*fadump_trigger)(struct fadump_crash_info_header *fdh,
> + const char *msg);
> };
>
> /* Helper functions */
> @@ -116,4 +140,13 @@ void fadump_update_elfcore_header(struct fw_dump *fadump_config, char *bufp);
> int is_fadump_boot_mem_contiguous(struct fw_dump *fadump_conf);
> int is_fadump_reserved_mem_contiguous(struct fw_dump *fadump_conf);
>
> +#ifdef CONFIG_PPC_PSERIES
> +extern int rtas_fadump_dt_scan(struct fw_dump *fadump_config, ulong node);
> +#else
> +static inline int rtas_fadump_dt_scan(struct fw_dump *fadump_config, ulong node)
> +{
> + return 1;
> +}
> +#endif
> +
> #endif /* __PPC64_FA_DUMP_INTERNAL_H__ */
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index f571cb3..a901ca1 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -112,24 +112,12 @@ static int __init fadump_cma_init(void) { return 1; }
> int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
> int depth, void *data)
> {
> - const __be32 *sections;
> - int i, num_sections;
> - int size;
> - const __be32 *token;
> + int ret;
>
> if (depth != 1 || strcmp(uname, "rtas") != 0)
> return 0;
>
> - /*
> - * Check if Firmware Assisted dump is supported. if yes, check
> - * if dump has been initiated on last reboot.
> - */
> - token = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL);
> - if (!token)
> - return 1;
> -
> - fw_dump.fadump_supported = 1;
> - fw_dump.ibm_configure_kernel_dump = be32_to_cpu(*token);
> + ret = rtas_fadump_dt_scan(&fw_dump, node);
>
> /*
> * The 'ibm,kernel-dump' rtas node is present only if there is
> @@ -139,36 +127,7 @@ int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
> if (fdm_active)
> fw_dump.dump_active = 1;
>
> - /* Get the sizes required to store dump data for the firmware provided
> - * dump sections.
> - * For each dump section type supported, a 32bit cell which defines
> - * the ID of a supported section followed by two 32 bit cells which
> - * gives teh size of the section in bytes.
> - */
> - sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> - &size);
> -
> - if (!sections)
> - return 1;
> -
> - num_sections = size / (3 * sizeof(u32));
> -
> - for (i = 0; i < num_sections; i++, sections += 3) {
> - u32 type = (u32)of_read_number(sections, 1);
> -
> - switch (type) {
> - case RTAS_FADUMP_CPU_STATE_DATA:
> - fw_dump.cpu_state_data_size =
> - of_read_ulong(§ions[1], 2);
> - break;
> - case RTAS_FADUMP_HPTE_REGION:
> - fw_dump.hpte_region_size =
> - of_read_ulong(§ions[1], 2);
> - break;
> - }
> - }
> -
> - return 1;
> + return ret;
> }
>
> /*
> diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> index ab3d59a..e248724 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_IBMVIO) += vio.o
> obj-$(CONFIG_IBMEBUS) += ibmebus.o
> obj-$(CONFIG_PAPR_SCM) += papr_scm.o
> obj-$(CONFIG_PPC_SPLPAR) += vphn.o
> +obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
>
> ifdef CONFIG_PPC_PSERIES
> obj-$(CONFIG_SUSPEND) += suspend.o
> diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.c b/arch/powerpc/platforms/pseries/rtas-fadump.c
> new file mode 100644
> index 0000000..9e7c9bf
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/rtas-fadump.c
> @@ -0,0 +1,134 @@
> +/*
> + * Firmware-Assisted Dump support on POWERVM platform.
> + *
> + * Copyright 2011, IBM Corporation
> + * Author: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> + *
> + * Copyright 2019, IBM Corp.
> + * Author: Hari Bathini <hbathini@linux.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#undef DEBUG
> +#define pr_fmt(fmt) "rtas fadump: " fmt
> +
> +#include <linux/string.h>
> +#include <linux/memblock.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/crash_dump.h>
> +
> +#include <asm/page.h>
> +#include <asm/prom.h>
> +#include <asm/rtas.h>
> +#include <asm/fadump.h>
> +
> +#include "../../kernel/fadump-common.h"
> +#include "rtas-fadump.h"
> +
> +static ulong rtas_fadump_init_mem_struct(struct fw_dump *fadump_conf)
> +{
> + return fadump_conf->reserve_dump_area_start;
> +}
> +
> +static int rtas_fadump_register_fadump(struct fw_dump *fadump_conf)
> +{
> + return -EIO;
> +}
> +
> +static int rtas_fadump_unregister_fadump(struct fw_dump *fadump_conf)
> +{
> + return -EIO;
> +}
> +
> +static int rtas_fadump_invalidate_fadump(struct fw_dump *fadump_conf)
> +{
> + return -EIO;
> +}
> +
> +/*
> + * Validate and process the dump data stored by firmware before exporting
> + * it through '/proc/vmcore'.
> + */
> +static int __init rtas_fadump_process_fadump(struct fw_dump *fadump_conf)
> +{
> + return -EINVAL;
> +}
> +
> +static void rtas_fadump_region_show(struct fw_dump *fadump_conf,
> + struct seq_file *m)
> +{
> +}
> +
> +static void rtas_fadump_trigger(struct fadump_crash_info_header *fdh,
> + const char *msg)
> +{
> + /* Call ibm,os-term rtas call to trigger firmware assisted dump */
> + rtas_os_term((char *)msg);
> +}
> +
> +static struct fadump_ops rtas_fadump_ops = {
> + .init_fadump_mem_struct = rtas_fadump_init_mem_struct,
> + .register_fadump = rtas_fadump_register_fadump,
> + .unregister_fadump = rtas_fadump_unregister_fadump,
> + .invalidate_fadump = rtas_fadump_invalidate_fadump,
> + .process_fadump = rtas_fadump_process_fadump,
> + .fadump_region_show = rtas_fadump_region_show,
> + .fadump_trigger = rtas_fadump_trigger,
> +};
> +
> +int __init rtas_fadump_dt_scan(struct fw_dump *fadump_conf, ulong node)
> +{
> + const __be32 *sections;
> + int i, num_sections;
> + int size;
> + const __be32 *token;
> +
> + /*
> + * Check if Firmware Assisted dump is supported. if yes, check
> + * if dump has been initiated on last reboot.
> + */
> + token = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL);
> + if (!token)
> + return 1;
> +
> + fadump_conf->ibm_configure_kernel_dump = be32_to_cpu(*token);
> + fadump_conf->ops = &rtas_fadump_ops;
> + fadump_conf->fadump_platform = FADUMP_PLATFORM_PSERIES;
> + fadump_conf->fadump_supported = 1;
> +
> + /* Get the sizes required to store dump data for the firmware provided
> + * dump sections.
> + * For each dump section type supported, a 32bit cell which defines
> + * the ID of a supported section followed by two 32 bit cells which
> + * gives the size of the section in bytes.
> + */
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + &size);
> +
> + if (!sections)
> + return 1;
> +
> + num_sections = size / (3 * sizeof(u32));
> +
> + for (i = 0; i < num_sections; i++, sections += 3) {
> + u32 type = (u32)of_read_number(sections, 1);
> +
> + switch (type) {
> + case RTAS_FADUMP_CPU_STATE_DATA:
> + fadump_conf->cpu_state_data_size =
> + of_read_ulong(§ions[1], 2);
> + break;
> + case RTAS_FADUMP_HPTE_REGION:
> + fadump_conf->hpte_region_size =
> + of_read_ulong(§ions[1], 2);
> + break;
> + }
> + }
> +
> + return 1;
> +}
>
--
Mahesh J Salgaonkar
^ permalink raw reply
* Re: [PATCHv3 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Lorenzo Pieralisi @ 2019-08-12 10:06 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, arnd, devicetree, gregkh, kstewart,
linuxppc-dev, linux-pci, linux-kernel, kishon, minghuan.Lian,
robh+dt, linux-arm-kernel, pombredanne, bhelgaas, leoyang.li,
shawnguo, shawn.lin, mingkai.hu
In-Reply-To: <20190628013826.4705-2-xiaowei.bao@nxp.com>
On Fri, Jun 28, 2019 at 09:38:26AM +0800, Xiaowei Bao wrote:
> Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - No change.
> v3:
> - modify the commit message.
>
> drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
> drivers/pci/controller/dwc/Makefile | 3 ++-
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index a6ce1ee..a41ccf5 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
> DesignWare core functions to implement the driver.
>
> config PCI_LAYERSCAPE
> - bool "Freescale Layerscape PCIe controller"
> + bool "Freescale Layerscape PCIe controller - Host mode"
> depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> depends on PCI_MSI_IRQ_DOMAIN
> select MFD_SYSCON
> select PCIE_DW_HOST
> help
> - Say Y here if you want PCIe controller support on Layerscape SoCs.
> + Say Y here if you want to enable PCIe controller support on Layerscape
> + SoCs to work in Host mode.
> + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
What's "The RCW" ? This entry should explain why a kernel configuration
should enable it.
Lorenzo
> + determines which PCIe controller works in EP mode and which PCIe
> + controller works in RC mode.
> +
> +config PCI_LAYERSCAPE_EP
> + bool "Freescale Layerscape PCIe controller - Endpoint mode"
> + depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> + depends on PCI_ENDPOINT
> + select PCIE_DW_EP
> + help
> + Say Y here if you want to enable PCIe controller support on Layerscape
> + SoCs to work in Endpoint mode.
> + This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
> + determines which PCIe controller works in EP mode and which PCIe
> + controller works in RC mode.
>
> config PCI_HISI
> depends on OF && (ARM64 || COMPILE_TEST)
> diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> index b085dfd..824fde7 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
> -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
> +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> +obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Lorenzo Pieralisi @ 2019-08-12 10:12 UTC (permalink / raw)
To: Xiaowei Bao, kishon
Cc: mark.rutland, roy.zang, arnd, devicetree, gregkh, kstewart,
linuxppc-dev, linux-pci, linux-kernel, leoyang.li, minghuan.Lian,
robh+dt, linux-arm-kernel, pombredanne, bhelgaas, shawnguo,
shawn.lin, mingkai.hu
In-Reply-To: <20190628013826.4705-1-xiaowei.bao@nxp.com>
First off:
Trim the CC list, you CC'ed maintainers (and mailing lists) for no
reasons whatsover.
Then, read this:
https://lore.kernel.org/linux-pci/20171026223701.GA25649@bhelgaas-glaptop.roam.corp.google.com/
and make your patches compliant please.
On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
> is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
> so set the bar_fixed_64bit with 0x14.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - Replace value 0x14 with a macro.
> v3:
> - No change.
>
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index be61d96..227c33b 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> .linkup_notifier = false,
> .msi_capable = true,
> .msix_capable = false,
> + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
I would appreciate Kishon's ACK on this.
Lorenzo
> };
>
> static const struct pci_epc_features*
> --
> 1.7.1
>
^ permalink raw reply
* RE: [EXT] Re: [PATCHv3 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-08-12 10:18 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190812100600.GA20861@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月12日 18:06
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian
> <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang
> <roy.zang@nxp.com>; kstewart@linuxfoundation.org;
> pombredanne@nexb.com; shawn.lin@rock-chips.com;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: [EXT] Re: [PATCHv3 2/2] PCI: layerscape: Add
> CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
>
> Caution: EXT Email
>
> On Fri, Jun 28, 2019 at 09:38:26AM +0800, Xiaowei Bao wrote:
> > Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> > v3:
> > - modify the commit message.
> >
> > drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
> > drivers/pci/controller/dwc/Makefile | 3 ++-
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/Kconfig
> > b/drivers/pci/controller/dwc/Kconfig
> > index a6ce1ee..a41ccf5 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
> > DesignWare core functions to implement the driver.
> >
> > config PCI_LAYERSCAPE
> > - bool "Freescale Layerscape PCIe controller"
> > + bool "Freescale Layerscape PCIe controller - Host mode"
> > depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> > depends on PCI_MSI_IRQ_DOMAIN
> > select MFD_SYSCON
> > select PCIE_DW_HOST
> > help
> > - Say Y here if you want PCIe controller support on Layerscape SoCs.
> > + Say Y here if you want to enable PCIe controller support on
> Layerscape
> > + SoCs to work in Host mode.
> > + This controller can work either as EP or RC. The
> > + RCW[HOST_AGT_PEX]
>
> What's "The RCW" ? This entry should explain why a kernel configuration
> should enable it.
[Xiaowei Bao] Hi Lorenzo, the RCW full name is "reset configuration word", it can be built to a bin file and program to the flash, rather than configure by kernel, almost the NXP Layerscaple platform use this way.
>
> Lorenzo
>
> > + determines which PCIe controller works in EP mode and which
> PCIe
> > + controller works in RC mode.
> > +
> > +config PCI_LAYERSCAPE_EP
> > + bool "Freescale Layerscape PCIe controller - Endpoint mode"
> > + depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> > + depends on PCI_ENDPOINT
> > + select PCIE_DW_EP
> > + help
> > + Say Y here if you want to enable PCIe controller support on
> Layerscape
> > + SoCs to work in Endpoint mode.
> > + This controller can work either as EP or RC. The
> RCW[HOST_AGT_PEX]
> > + determines which PCIe controller works in EP mode and which
> PCIe
> > + controller works in RC mode.
> >
> > config PCI_HISI
> > depends on OF && (ARM64 || COMPILE_TEST) diff --git
> > a/drivers/pci/controller/dwc/Makefile
> > b/drivers/pci/controller/dwc/Makefile
> > index b085dfd..824fde7 100644
> > --- a/drivers/pci/controller/dwc/Makefile
> > +++ b/drivers/pci/controller/dwc/Makefile
> > @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> > obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> > obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> > obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
> > -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
> > +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> > +obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
> > obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> > obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> > obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> > --
> > 1.7.1
> >
^ permalink raw reply
* RE: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-12 10:39 UTC (permalink / raw)
To: Lorenzo Pieralisi, kishon@ti.com
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190812101213.GB20861@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月12日 18:12
> To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai
> Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> kstewart@linuxfoundation.org; pombredanne@nexb.com;
> shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> property in EP driver.
>
> Caution: EXT Email
>
> First off:
>
> Trim the CC list, you CC'ed maintainers (and mailing lists) for no reasons
> whatsover.
[Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the command "git send-email --to", I will try to send the patch again, do I need to modify the version is v4 when I send this patch again?
>
> Then, read this:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
>
> and make your patches compliant please.
>
> On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is
> > 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, so set
> > the bar_fixed_64bit with 0x14.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Replace value 0x14 with a macro.
> > v3:
> > - No change.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index be61d96..227c33b 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> > .linkup_notifier = false,
> > .msi_capable = true,
> > .msix_capable = false,
> > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
>
> I would appreciate Kishon's ACK on this.
>
> Lorenzo
>
> > };
> >
> > static const struct pci_epc_features*
> > --
> > 1.7.1
> >
^ permalink raw reply
* Re: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Lorenzo Pieralisi @ 2019-08-12 11:35 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, kishon@ti.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <AM5PR04MB329929A0B046F6BEB94B0120F5D30@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Mon, Aug 12, 2019 at 10:39:00AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Sent: 2019年8月12日 18:12
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> > gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai
> > Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > kstewart@linuxfoundation.org; pombredanne@nexb.com;
> > shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> > property in EP driver.
> >
> > Caution: EXT Email
> >
> > First off:
> >
> > Trim the CC list, you CC'ed maintainers (and mailing lists) for no reasons
> > whatsover.
> [Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the command "git send-email --to", I will try to send the patch again, do I need to modify the version is v4 when I send this patch again?
Yes you do.
Wrap lines to max 80 characters. There is no need to add [Xiaowei Bao].
1) Read, email etiquette
https://kernelnewbies.org/PatchCulture
2) get_maintainer.pl -f drivers/pci/controller/dwc/pci-layerscape.c
Compare the output to the people in CC, trim it accordingly.
3) The NXP maintainers in the MAINTAINERS file have not given a single
comment for this patchset. Either they show up or I will remove them
from the MAINTAINERS list.
4) Before submitting patches, talk to someone at NXP who can help you
format them in preparation for posting, I do not have time to write
guidelines for everyone posting on linux-pci, sorry, the information
is out there if you care to read it.
Thanks,
Lorenzo
> >
> > Then, read this:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> > rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> > m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> > 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> > duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
> >
> > and make your patches compliant please.
> >
> > On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is
> > > 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, so set
> > > the bar_fixed_64bit with 0x14.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - Replace value 0x14 with a macro.
> > > v3:
> > > - No change.
> > >
> > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > index be61d96..227c33b 100644
> > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> > > .linkup_notifier = false,
> > > .msi_capable = true,
> > > .msix_capable = false,
> > > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> >
> > I would appreciate Kishon's ACK on this.
> >
> > Lorenzo
> >
> > > };
> > >
> > > static const struct pci_epc_features*
> > > --
> > > 1.7.1
> > >
^ permalink raw reply
* Re: [PATCH 3/6] usb: add a HCD_DMA flag instead of guestimating DMA capabilities
From: Christoph Hellwig @ 2019-08-12 11:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, Maxime Chevallier
Cc: linux-arch, Gavin Li, Pengutronix Kernel Team, Mathias Nyman,
Geoff Levand, Olav Kongas, Sascha Hauer, linux-usb, Michal Simek,
linux-kernel, Tony Prisk, iommu, Alan Stern, NXP Linux Team,
Fabio Estevam, Minas Harutyunyan, Shawn Guo, linuxppc-dev,
Bin Liu, linux-arm-kernel, Laurentiu Tudor
In-Reply-To: <20190811080520.21712-4-hch@lst.de>
> diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
> index 576f7d79ad4e..9d17e0695e35 100644
> --- a/drivers/usb/host/ehci-ppc-of.c
> +++ b/drivers/usb/host/ehci-ppc-of.c
> @@ -31,7 +31,7 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
> * generic hardware linkage
> */
> .irq = ehci_irq,
> - .flags = HCD_MEMORY | HCD_USB2 | HCD_BH,
> + .flags = HCD_MEMORY | HC_DMA | HCD_USB2 | HCD_BH,
FYI, the kbuild bot found a little typo here, so even for the unlikely
case that the series is otherwise perfect I'll have to resend it at
least once.
^ permalink raw reply
* Re: [PATCH v3 1/3] powerpc/spinlocks: Refactor SHARED_PROCESSOR
From: Michael Ellerman @ 2019-08-12 12:08 UTC (permalink / raw)
To: kbuild test robot, Christopher M. Riedl
Cc: linuxppc-dev, kbuild-all, Andrew Donnellan
In-Reply-To: <201908120917.L7bXpUsz%lkp@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Hi "Christopher,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc4 next-20190809]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Christopher-M-Riedl/Fix-oops-in-shared-processor-spinlocks/20190806-204502
> config: powerpc-powernv_defconfig (attached as .config)
> compiler: powerpc64le-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/spinlock.h:89:0,
> from include/linux/seqlock.h:36,
> from include/linux/time.h:6,
> from include/linux/compat.h:10,
> from arch/powerpc/kernel/asm-offsets.c:14:
> arch/powerpc/include/asm/spinlock.h: In function 'is_shared_processor':
>>> arch/powerpc/include/asm/spinlock.h:119:34: error: 'struct paca_struct' has no member named 'lppaca_ptr'; did you mean 'slb_cache_ptr'?
> lppaca_shared_proc(local_paca->lppaca_ptr));
> ^~~~~~~~~~
> slb_cache_ptr
> make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
> make[2]: Target '__build' not remade because of errors.
> make[1]: *** [prepare0] Error 2
> make[1]: Target 'prepare' not remade because of errors.
> make: *** [sub-make] Error 2
> 7 real 4 user 3 sys 110.24% cpu make prepare
>
> vim +119 arch/powerpc/include/asm/spinlock.h
>
> 110
> 111 static inline bool is_shared_processor(void)
> 112 {
> 113 /*
> 114 * LPPACA is only available on BOOK3S so guard anything LPPACA related to
> 115 * allow other platforms (which include this common header) to compile.
> 116 */
> 117 #ifdef CONFIG_PPC_BOOK3S
I think you should use PPC_PSERIES here and that will fix it.
cheers
> 118 return (IS_ENABLED(CONFIG_PPC_SPLPAR) &&
> > 119 lppaca_shared_proc(local_paca->lppaca_ptr));
> 120 #else
> 121 return false;
> 122 #endif
> 123 }
> 124
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v3 08/16] powerpc/pseries/svm: Use shared memory for LPPACA structures
From: Michael Ellerman @ 2019-08-12 12:36 UTC (permalink / raw)
To: Thiago Jung Bauermann, linuxppc-dev
Cc: Anshuman Khandual, Alexey Kardashevskiy, Mike Anderson, Ram Pai,
linux-kernel, Claudio Carvalho, Paul Mackerras, Christoph Hellwig,
Thiago Jung Bauermann, Anshuman Khandual
In-Reply-To: <20190806052237.12525-9-bauerman@linux.ibm.com>
Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
> From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>
> LPPACA structures need to be shared with the host. Hence they need to be in
> shared memory. Instead of allocating individual chunks of memory for a
> given structure from memblock, a contiguous chunk of memory is allocated
> and then converted into shared memory. Subsequent allocation requests will
> come from the contiguous chunk which will be always shared memory for all
> structures.
>
> While we are able to use a kmem_cache constructor for the Debug Trace Log,
> LPPACAs are allocated very early in the boot process (before SLUB is
> available) so we need to use a simpler scheme here.
>
> Introduce helper is_svm_platform() which uses the S bit of the MSR to tell
> whether we're running as a secure guest.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> ---
> arch/powerpc/include/asm/svm.h | 26 ++++++++++++++++++++
> arch/powerpc/kernel/paca.c | 43 +++++++++++++++++++++++++++++++++-
> 2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
> new file mode 100644
> index 000000000000..fef3740f46a6
> --- /dev/null
> +++ b/arch/powerpc/include/asm/svm.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * SVM helper functions
> + *
> + * Copyright 2019 Anshuman Khandual, IBM Corporation.
Are we sure this copyright date is correct?
cheers
^ permalink raw reply
* Re: [PATCH v3 11/16] powerpc/pseries/svm: Export guest SVM status to user space via sysfs
From: Michael Ellerman @ 2019-08-12 13:03 UTC (permalink / raw)
To: Thiago Jung Bauermann, linuxppc-dev
Cc: Anshuman Khandual, Alexey Kardashevskiy, Mike Anderson, Ram Pai,
linux-kernel, Claudio Carvalho, Ryan Grimm, Paul Mackerras,
Christoph Hellwig, Thiago Jung Bauermann
In-Reply-To: <20190806052237.12525-12-bauerman@linux.ibm.com>
Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
> From: Ryan Grimm <grimm@linux.vnet.ibm.com>
>
> User space might want to know it's running in a secure VM. It can't do
> a mfmsr because mfmsr is a privileged instruction.
>
> The solution here is to create a cpu attribute:
>
> /sys/devices/system/cpu/svm
>
> which will read 0 or 1 based on the S bit of the guest's CPU 0.
Why CPU 0?
If we have different CPUs running with different MSR_S then something
has gone badly wrong, no?
So can't we just read the MSR on whatever CPU the sysfs code happens to
run on.
cheers
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index e2147d7c9e72..f7100ab77d29 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -19,6 +19,7 @@
> #include <asm/smp.h>
> #include <asm/pmc.h>
> #include <asm/firmware.h>
> +#include <asm/svm.h>
>
> #include "cacheinfo.h"
> #include "setup.h"
> @@ -715,6 +716,32 @@ static struct device_attribute pa6t_attrs[] = {
> #endif /* HAS_PPC_PMC_PA6T */
> #endif /* HAS_PPC_PMC_CLASSIC */
>
> +#ifdef CONFIG_PPC_SVM
> +static void get_svm(void *val)
> +{
> + u32 *value = val;
> +
> + *value = is_secure_guest();
> +}
> +
> +static ssize_t show_svm(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + u32 val;
> + smp_call_function_single(0, get_svm, &val, 1);
> + return sprintf(buf, "%u\n", val);
> +}
> +static DEVICE_ATTR(svm, 0444, show_svm, NULL);
> +
> +static void create_svm_file(void)
> +{
> + device_create_file(cpu_subsys.dev_root, &dev_attr_svm);
> +}
> +#else
> +static void create_svm_file(void)
> +{
> +}
> +#endif /* CONFIG_PPC_SVM */
> +
> static int register_cpu_online(unsigned int cpu)
> {
> struct cpu *c = &per_cpu(cpu_devices, cpu);
> @@ -1058,6 +1085,8 @@ static int __init topology_init(void)
> sysfs_create_dscr_default();
> #endif /* CONFIG_PPC64 */
>
> + create_svm_file();
> +
> return 0;
> }
> subsys_initcall(topology_init);
^ permalink raw reply
* Applied "ASoC: fsl_esai: Add compatible string for imx6ull" to the asoc tree
From: Mark Brown @ 2019-08-12 13:09 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, linux-kernel, robh+dt, Nicolin Chen, Mark Brown,
festevam
In-Reply-To: <1565346467-5769-1-git-send-email-shengjiu.wang@nxp.com>
The patch
ASoC: fsl_esai: Add compatible string for imx6ull
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9c2806c4941641a6c75736f8c4303c89d2013cc4 Mon Sep 17 00:00:00 2001
From: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Fri, 9 Aug 2019 18:27:46 +0800
Subject: [PATCH] ASoC: fsl_esai: Add compatible string for imx6ull
Add compatible string for imx6ull, from imx6ull platform,
the issue of channel swap after xrun is fixed in hardware.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Link: https://lore.kernel.org/r/1565346467-5769-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/fsl/fsl_esai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 5832144beb9f..a78e4ab478df 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -1049,6 +1049,7 @@ static int fsl_esai_remove(struct platform_device *pdev)
static const struct of_device_id fsl_esai_dt_ids[] = {
{ .compatible = "fsl,imx35-esai", },
{ .compatible = "fsl,vf610-esai", },
+ { .compatible = "fsl,imx6ull-esai", },
{}
};
MODULE_DEVICE_TABLE(of, fsl_esai_dt_ids);
--
2.20.1
^ permalink raw reply related
* Applied "ASoC: fsl_esai: Add new compatible string for imx6ull" to the asoc tree
From: Mark Brown @ 2019-08-12 13:09 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, linux-kernel, robh+dt, Nicolin Chen, Mark Brown,
festevam
In-Reply-To: <1565346467-5769-2-git-send-email-shengjiu.wang@nxp.com>
The patch
ASoC: fsl_esai: Add new compatible string for imx6ull
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9ea08f2a6d27b6a26d33dae5c58e4099672d6bb3 Mon Sep 17 00:00:00 2001
From: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Fri, 9 Aug 2019 18:27:47 +0800
Subject: [PATCH] ASoC: fsl_esai: Add new compatible string for imx6ull
Add new compatible string "fsl,imx6ull-esai" in the binding document.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Link: https://lore.kernel.org/r/1565346467-5769-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/devicetree/bindings/sound/fsl,esai.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index 5b9914367610..0e6e2166f76c 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -7,8 +7,11 @@ other DSPs. It has up to six transmitters and four receivers.
Required properties:
- - compatible : Compatible list, must contain "fsl,imx35-esai" or
- "fsl,vf610-esai"
+ - compatible : Compatible list, should contain one of the following
+ compatibles:
+ "fsl,imx35-esai",
+ "fsl,vf610-esai",
+ "fsl,imx6ull-esai",
- reg : Offset and length of the register set for the device.
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox