On 12/08/19 9:31 PM, Mahesh J Salgaonkar wrote:
> On 2019-07-16 17:02:38 Tue, Hari Bathini wrote:
>> Make RTAS calls to register and un-register for FADump. Also, update
>> how fadump_region contents are diplayed to provide more information.
>>
>> Signed-off-by: Hari Bathini
>> ---
>> arch/pow
On 12/08/19 3:12 PM, Mahesh J Salgaonkar wrote:
> 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:
The on chip memory allocator is entirely unused in the kernel tree.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/configs/ppc40x_defconfig | 1 -
arch/powerpc/include/asm/ppc4xx_ocm.h | 31 --
arch/powerpc/platforms/44x/Kconfig| 8 -
arch/powerpc/platforms/4xx/Makefile | 1 -
ar
Hi Nick,
Le 07/06/2018 à 03:43, Nicholas Piggin a écrit :
On Wed, 6 Jun 2018 14:21:08 + (UTC)
Christophe Leroy wrote:
scaled cputime is only meaningfull when the processor has
SPURR and/or PURR, which means only on PPC64.
[...]
I wonder if we could make this depend on PPC_PSERIES
On Wed, Aug 14, 2019 at 08:23:54AM +0200, Christophe Leroy wrote:
> Le 14/08/2019 à 07:49, Christoph Hellwig a écrit :
> > Somehow this series is missing a cover letter.
> >
> > While you are touching all this "fun" can you also look into killing
> > __ioremap? It seems to be a weird non-standard
Le 14/08/2019 à 07:49, Christoph Hellwig a écrit :
Somehow this series is missing a cover letter.
While you are touching all this "fun" can you also look into killing
__ioremap? It seems to be a weird non-standard version of ioremap_prot
(probably predating ioremap_prot) that is missing a fe
On Wed, Aug 14, 2019 at 08:10:59AM +0200, Christophe Leroy wrote:
> > Note that while a few other architectures have a magic hack like powerpc
> > to make ioremap work before vmalloc, the normal practice would be
> > to explicitly use early_ioremap. I guess your change is fine for now,
> > but it
Le 14/08/2019 à 07:55, Christoph Hellwig a écrit :
On Tue, Aug 13, 2019 at 08:11:38PM +, Christophe Leroy wrote:
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
Note that while a few other architectures have a magic hack l
On Wed, Aug 14, 2019 at 02:46:38PM +1000, Jordan Niethe wrote:
> On Tue, 2019-08-13 at 20:03 +1000, Paul Mackerras wrote:
[snip]
> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> > index 337e644..2e7e788 100644
> > --- a/arch/powerpc/kvm/book3
On Tue, Aug 13, 2019 at 08:11:38PM +, Christophe Leroy wrote:
> Until vmalloc system is up and running, ioremap basically
> allocates addresses at the border of the IOREMAP area.
Note that while a few other architectures have a magic hack like powerpc
to make ioremap work before vmalloc, the n
Somehow this series is missing a cover letter.
While you are touching all this "fun" can you also look into killing
__ioremap? It seems to be a weird non-standard version of ioremap_prot
(probably predating ioremap_prot) that is missing a few lines of code
setting attributes that might not even b
On Tue, Aug 13, 2019 at 08:11:34PM +, Christophe Leroy wrote:
> ppc_md.ioremap() is only used for I/O workaround on CELL platform,
> so indirect function call can be avoided.
>
> This patch reworks the io-workaround and ioremap() functions to
> use static keys for the activation of io-workarou
On Wed, Aug 14, 2019 at 05:28:35AM +, Christophe Leroy wrote:
> When KASAN is selected, the definitive hash table has to be
> set up later, but there is already an early temporary one.
>
> When KASAN is not selected, there is no early hash table,
> so the setup of the definitive hash table can
Hi
Le 13/08/2019 à 17:51, Jonathan Neuschäfer a écrit :
Hi,
I noticed that my Nintendo Wii doesn't boot with wii_defconfig plus
CONFIG_DEBUG_PAGEALLOC=y and CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
on recent kernels. I get a splash like this one:
[0.022245] BUG: Unable to handle kernel data
When KASAN is selected, the definitive hash table has to be
set up later, but there is already an early temporary one.
When KASAN is not selected, there is no early hash table,
so the setup of the definitive hash table cannot be delayed.
Reported-by: Jonathan Neuschafer
Fixes: 72f208c6a8f7 ("pow
> +/**
> + * __iounmap_from - Low level function to tear down the page tables
> + * for an IO mapping. This is used for mappings that
> + * are manipulated manually, like partial unmapping of
> + * PCI IOs or ISA space.
> + */
> +void __iounmap_at(
On Tue, Aug 13, 2019 at 08:11:33PM +, Christophe Leroy wrote:
> ppc_md.iounmap() is never set, drop it.
>
> Signed-off-by: Christophe Leroy
Hah, I was just going to send the same patch as part of an tree-wide
ioremap related series..
Reviewed-by: Christoph Hellwig
On Tue, 2019-08-13 at 20:03 +1000, Paul Mackerras wrote:
> Escalation interrupts are interrupts sent to the host by the XIVE
> hardware when it has an interrupt to deliver to a guest VCPU but that
> VCPU is not running anywhere in the system. Hence we disable the
> escalation interrupt for the VCP
Hi Aneesh, logic looks correct but there are some cleanups I'd like to
see and a lead-in patch that I attached.
I've started prefixing nvdimm patches with:
libnvdimm/$component:
...since this patch mostly impacts the pmem driver lets prefix it
"libnvdimm/pmem: "
On Fri, Aug 9, 2019 at 12:45
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
v3:
- modify the commit message.
v4:
- send the patch again with '--to'.
v5:
- No change.
v6:
- remove the [EXT] tag of the $SUBJECT in email.
drivers/pci/controller/dwc/Kconfig | 20 ++
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR2 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
v4:
- send the patch again with '--to
On Tue, Aug 13, 2019 at 09:59:35AM +, Christophe Leroy wrote:
[snip]
> +.macro __LOAD_REG_IMMEDIATE r, x
> + .if \x & ~0x != 0
> + __LOAD_REG_IMMEDIATE_32 \r, (\x) >> 32
> + rldicr \r, \r, 32, 31
> + .if (\x) & 0x != 0
> +
Hi Nick,
Just a few comments.
Nicholas Piggin writes:
> diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c
> b/arch/powerpc/mm/book3s64/radix_tlb.c
> index 71f7fede2fa4..56ceecbd3d5c 100644
> --- a/arch/powerpc/mm/book3s64/radix_tlb.c
> +++ b/arch/powerpc/mm/book3s64/radix_tlb.c
> @@ -285,6 +286
__ioremap_caller() do the same thing. Define a common one.
__ioremap() is not reused because most of the tests included in
it are unnecessary when coming from __ioremap_caller()
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ioremap.c| 99
a
book3s64's ioremap_range() is almost same as fallback ioremap_range(),
except that it calls radix__ioremap_range() when radix is enabled.
radix__ioremap_range() is also very similar to the other ones, expect
that it calls ioremap_page_range when slab is available.
Lets keep only one version of io
Allthough __ioremap_at() and __iounmap_at() are specific to PPC64,
lets move them into ioremap.c as it wouldn't be worth creating an
ioremap_64.c only for those functions.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ioremap.c| 43 +++
arch/powe
On PPC64 iounmap() does nothing else than calling __iounmap()
and is the only user of __iounmap().
__iounmap() is almost similar to PPC32 iounmap().
Lets define a common iounmap() and drop __iounmap().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
arc
Drop multiple definitions of ioremap_bot and make one common to
all subarches.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 --
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
arch/powerpc/include/asm/nohash/32/pgtable.h | 2 --
arch/powerpc/include/as
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
On PPC32, addresses are allocated down from the top of the area
while on PPC64, addresses are allocated up from the base of the
area.
On PPC32, the base of vmalloc area is not known ye
ppc_md.ioremap() is only used for I/O workaround on CELL platform,
so indirect function call can be avoided.
This patch reworks the io-workaround and ioremap() functions to
use static keys for the activation of io-workaround.
When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not
sele
ppc_md.iounmap() is never set, drop it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/machdep.h | 2 --
arch/powerpc/mm/pgtable_64.c | 5 +
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machde
ioremap(), __ioremap(), ioremap_wc() and ioremap_coherent() are
now identical on PPC32 and PPC64 as iowa_is_active() will always
return false on PPC32. Move them into a new common location called
ioremap.c
Allthough ioremap_wt() only exists on PPC32, move it into ioremap.c
as well. As it is the on
Both ioremap_prot() are idenfical, move them into ioremap.c
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ioremap.c| 19 +++
arch/powerpc/mm/pgtable_32.c | 17 -
arch/powerpc/mm/pgtable_64.c | 24
3 files changed, 19 insertions(+
Gautham R Shenoy writes:
> On Sat, Aug 3, 2019 at 1:03 AM Nathan Lynch wrote:
>>
>> rtas_cpu_state_change_mask() potentially operates on scores of cpus,
>> so explicitly allow rescheduling in the loop body.
>>
>
> Are we seeing softlockups/rcu stalls while running this ?
I have not seen a repor
On Sat, Aug 3, 2019 at 1:03 AM Nathan Lynch wrote:
>
> rtas_cpu_state_change_mask() potentially operates on scores of cpus,
> so explicitly allow rescheduling in the loop body.
>
Are we seeing softlockups/rcu stalls while running this ?
> Signed-off-by: Nathan Lynch
Reviewed-by: Gautham R. She
Since BPF constant blinding is performed after the verifier pass, there
are certain ALU32 instructions inserted which don't have a corresponding
zext instruction inserted after. This is causing a kernel oops on
powerpc and can be reproduced by running 'test_cgroup_storage' with
bpf_jit_harden=2.
F
Hello Nathan,
On Sat, Aug 3, 2019 at 1:06 AM Nathan Lynch wrote:
>
> The LPAR migration implementation and userspace-initiated cpu hotplug
> can interleave their executions like so:
>
> 1. Set cpu 7 offline via sysfs.
>
> 2. Begin a partition migration, whose implementation requires the OS
>t
Hi,
I noticed that my Nintendo Wii doesn't boot with wii_defconfig plus
CONFIG_DEBUG_PAGEALLOC=y and CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
on recent kernels. I get a splash like this one:
[0.022245] BUG: Unable to handle kernel data access at 0x6601
[0.025172] Faulting instruction a
https://bugzilla.kernel.org/show_bug.cgi?id=204371
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC||christophe.le
On 2019-07-16 17:03:30 Tue, Hari Bathini wrote:
> Firmware uses 32-bit field for region size while copying/backing-up
> memory during MPIPL. So, the maximum copy size for a region would
> be a page less than 4GB (aligned to pagesize) but FADump capture
> kernel usually needs more memory than that t
On 2019-07-16 17:03:23 Tue, Hari Bathini wrote:
> Make OPAL calls to register and un-register with firmware for MPIPL.
>
> Signed-off-by: Hari Bathini
> ---
> arch/powerpc/platforms/powernv/opal-fadump.c | 71
> +-
> 1 file changed, 69 insertions(+), 2 deletions(-)
>
On 13/08/2019 12:01, Paul Mackerras wrote:
> At present, when running a guest on POWER9 using HV KVM but not using
> an in-kernel interrupt controller (XICS or XIVE), for example if QEMU
> is run with the kernel_irqchip=off option, the guest entry code goes
> ahead and tries to load the guest conte
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #284271|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #18)
> Two possibilities, either the value in .rodata.cst16 is wrong or the stack
> gets corrupted.
>
> Maybe you could try disabling KASAN in li
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284355
--> https://bugzilla.kernel.org/attachment.cgi?id=284355&action=edit
dmesg (kernel 5.3-rc4 + shadow patch + parallel patch, PowerMac G4 DP)
--
You are receivin
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年8月13日 18:04
> To: Xiaowei Bao
> Cc: bhelg...@google.com; M.h. Lian ; Mingkai Hu
> ; Roy Zang ;
> l.st...@pengutronix.de; kis...@ti.com; tpie...@impinj.com; Leonard
> Crestez ; andrew.smir...@gmail.com;
> yue.w...@amlogic.com; h
On 2019-07-16 17:03:15 Tue, Hari Bathini wrote:
> OPAL allows registering address with it in the first kernel and
> retrieving it after MPIPL. Setup kernel metadata and register its
> address with OPAL to use it for processing the crash dump.
>
> Signed-off-by: Hari Bathini
> ---
> arch/powerpc/
Escalation interrupts are interrupts sent to the host by the XIVE
hardware when it has an interrupt to deliver to a guest VCPU but that
VCPU is not running anywhere in the system. Hence we disable the
escalation interrupt for the VCPU being run when we enter the guest
and re-enable it when the gue
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
At present, when running a guest on POWER9 using HV KVM but not using
an in-kernel interrupt controller (XICS or XIVE), for example if QEMU
is run with the kernel_irqchip=off option, the guest entry code goes
ahead and tries to load the guest context into the XIVE hardware, even
though no context h
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 be
git log --oneline --follow drivers/pci/controller/dwc/pci-layerscape.c
Do you see any commit with a $SUBJECT ending with a period ?
There is not. So remove it from yours too.
On Tue, Aug 13, 2019 at 02:28:39PM +0800, Xiaowei Bao wrote:
> The PCIe controller of layerscape just have 4 BARs, BAR0 a
LOAD_MSR_KERNEL() and LOAD_REG_IMMEDIATE() are doing the same thing
in the same way. Drop LOAD_MSR_KERNEL()
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/entry_32.S | 18 +-
arch/powerpc/kernel/head_32.h | 21 -
2 files changed, 13 insertions(+), 26
Today LOAD_REG_IMMEDIATE() is a basic #define which loads all
parts on a value into a register, including the parts that are NUL.
This means always 2 instructions on PPC32 and always 5 instructions
on PPC64. And those instructions cannot run in parallele as they are
updating the same register.
Ex
You should fix your email client set-up to avoid sticking an [EXT]
tag to your emails $SUBJECT.
On Tue, Aug 13, 2019 at 07:39:48AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Kishon Vijay Abraham I
> > Sent: 2019年8月13日 15:30
> > To: Xiaowei Bao ; lorenzo.pieral...@arm
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
On Fri, 09 Aug 2019 12:31:26 +
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
# cat ~/bisect01.log
binäre Suche: danach noch 37903 Com
https://bugzilla.kernel.org/show_bug.cgi?id=204371
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #284035|0 |1
is obsolete|
On 13/08/19 11:58 AM, Xiaowei Bao wrote:
> The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
> is 32bit, BAR2 and BAR4 is 64bit, this is determined by hardware,
> so set the bar_fixed_64bit with 0x14.
>
> Signed-off-by: Xiaowei Bao
Acked-by: Kishon Vijay Abraham I
> ---
> v2:
> -Original Message-
> From: Kishon Vijay Abraham I
> Sent: 2019年8月13日 15:30
> To: Xiaowei Bao ; lorenzo.pieral...@arm.com;
> bhelg...@google.com; M.h. Lian ; Mingkai Hu
> ; Roy Zang ;
> l.st...@pengutronix.de; tpie...@impinj.com; Leonard Crestez
> ; andrew.smir...@gmail.com;
> yue.w...@
59 matches
Mail list logo