On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> Chris Packham writes:
> > Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
> > these SoCs is 32KiB and is split into 64 byte blocks (lines).
> >
> > Signed-off-by: Chris Packham
> > ---
> >
On 23/3/20 3:52 pm, Christopher M. Riedl wrote:
When compiled with CONFIG_STRICT_KERNEL_RWX, the kernel must create
temporary mappings when patching itself. These mappings temporarily
override the strict RWX text protections to permit a write. Currently,
powerpc allocates a per-CPU VM area for
Quoting Mauro Carvalho Chehab (2020-02-22 01:00:03)
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
Fixes the below crash
BUG: Kernel NULL pointer dereference on read at 0x
Faulting instruction address: 0xc0c3447c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest
On 24/03/2020 18:54, Christoph Hellwig wrote:
> On Tue, Mar 24, 2020 at 02:05:54PM +1100, Alexey Kardashevskiy wrote:
>> This is for persistent memory which you can DMA to/from but yet it does
>> not appear in the system as a normal memory and therefore requires
>> special handling anyway
On Wed, 25 Mar 2020 at 05:19, Fangrui Song wrote:
>
> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
> binding to STB_WEAK. They should not be used together. It is accidetal
> rather then intentional that GNU as let .weak override .globl while
> clang integrated assembler let
On Mon, 2020-03-23 at 12:23 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:15 pm:
> >
> > Setup thread IRQ handler per each VAS instance. When NX sees a fault
> > on CRB, kernel gets an interrupt and vas_fault_handler will be
> > executed to process fault CRBs. Read all valid
On 2020/3/19 6:52, Mike Kravetz wrote:
> On 3/18/20 3:15 PM, Dave Hansen wrote:
>> Hi Mike,
>>
>> The series looks like a great idea to me. One nit on the x86 bits,
>> though...
>>
>>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>>> index 5bfd5aef5378..51e6208fdeec
On Tue, 2020-03-24 at 14:41 +1100, Michael Ellerman wrote:
> Daniel Axtens writes:
> > Michael Ellerman writes:
> >> Daniel Axtens writes:
> >>> Haren Myneni writes:
> diff --git a/arch/powerpc/platforms/powernv/vas-api.c
> b/arch/powerpc/platforms/powernv/vas-api.c
> new file
On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > Chris Packham writes:
> > > Add the d-cache/i-cache properties for the T208x SoCs. The L1
> > > cache on
> > > these SoCs is 32KiB and is split into 64 byte blocks (lines).
> > >
On Wed, 2020-03-25 at 15:38 +1300, Chris Packham wrote:
> On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> > On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > > Chris Packham writes:
> > > > Add the d-cache/i-cache properties for the T208x SoCs. The L1
> > > > cache on
> > > >
On Mon, 2020-03-23 at 12:40 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:18 pm:
> >
> > System checkstops if RxFIFO overruns with more requests than the
> > maximum possible number of CRBs allowed in FIFO at any time. So
> > max credits value (rxattr.wcreds_max) is set and
If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use
the block-size value for both. Per the devicetree spec cache-line-size
is only needed if it differs from the block size.
Signed-off-by: Chris Packham
---
It looks as though the bsizep = lsizep is not required per the spec but
On Mon, 2020-03-23 at 12:44 +1000, Nicholas Piggin wrote:
> Haren Myneni's on March 19, 2020 4:19 pm:
> >
> > NX expects OS to return credit for send window after processing each
> > fault. Also credit has to be returned even for fault window.
>
> And this should be merged in the fault handler
The ISA has a quirk that's useful for the Linux implementation.
Document it here so others are less likely to trip over it.
Signed-off-by: Michael Neuling
Suggested-by: Michael Ellerman
---
.../powerpc/transactional_memory.rst | 27 +++
1 file changed, 27 insertions(+)
On 3/24/20 12:08 PM, Michael Ellerman wrote:
"Aneesh Kumar K.V" writes:
THP config can result in compound pages. Make sure kernel enables the
PageCompound() check when only THP is enabled.
Or else what happens ... nothing, rampant data corruption, something in
between?
We can get a stale
On Tue, Mar 24, 2020 at 12:00:09PM +0530, Aneesh Kumar K.V wrote:
> dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
> unsigned long offset, size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> phys_addr_t phys =
On Tue, Mar 24, 2020 at 02:05:54PM +1100, Alexey Kardashevskiy wrote:
> This is for persistent memory which you can DMA to/from but yet it does
> not appear in the system as a normal memory and therefore requires
> special handling anyway (O_DIRECT or DAX, I do not know the exact
> mechanics). All
Christophe Leroy writes:
> On 03/20/2020 02:12 AM, Michael Ellerman wrote:
>> Christophe Leroy writes:
>>> Move ADV_DEBUG_REGS functions out of ptrace.c, into
>>> ptrace-adv.c and ptrace-noadv.c
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v4: Leave hw_breakpoint.h for ptrace.c
>>> ---
On Tue, Mar 24, 2020 at 02:37:59PM +1100, Alexey Kardashevskiy wrote:
> dma_alloc_direct() and dma_map_direct() do the same thing now which is
> good, did I miss anything else?
dma_alloc_direct looks at coherent_dma_mask, dma_map_direct looks
at dma_mask.
Michal Suchanek's on March 19, 2020 10:19 pm:
> There are two almost identical copies for 32bit and 64bit.
>
> The function is used only in 32bit code which will be split out in next
> patch so consolidate to one function.
>
> Signed-off-by: Michal Suchanek
> Reviewed-by: Christophe Leroy
>
Michal Suchanek's on March 19, 2020 10:19 pm:
> diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
> index 4b0152108f61..a264989626fd 100644
> --- a/arch/powerpc/kernel/signal.c
> +++ b/arch/powerpc/kernel/signal.c
> @@ -247,7 +247,6 @@ static void do_signal(struct
On Tue, 2020-03-24 at 14:52 +1100, Michael Ellerman wrote:
> "Naveen N. Rao" writes:
> > Segher Boessenkool wrote:
> > > On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote:
> > > > Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit
> > > > designs prior to PowerPC
"Aneesh Kumar K.V" writes:
> THP config can result in compound pages. Make sure kernel enables the
> PageCompound() check when only THP is enabled.
Or else what happens ... nothing, rampant data corruption, something in
between?
And "when only THP is enabled" is not very clear, AFAIK there is
Alexey Kardashevskiy writes:
> On 24/03/2020 04:22, Christoph Hellwig wrote:
>> On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>>>
>>> This is what I was trying, but considering I am new to DMA subsystem, I
>>> am not sure I got all the details correct. The idea is to look at
Hi Sachin,
On 03/24/20 at 11:25am, Sachin Sant wrote:
> While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered.
>
> Bisect leads me to commit d41e2f3bd546
> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>
> Reverting this commit helps and the tests
On Mon, Mar 23, 2020 at 02:23:49PM -0400, Joel Fernandes wrote:
> On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> > "Joel Fernandes (Google)" writes:
> >
> > > Reword and clarify better about the rwsem non-owner release issue.
> > >
> > > Link:
On Mon, 2020-03-23 at 07:46 -0500, Segher Boessenkool wrote:
> On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote:
> > Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit
> > designs prior to PowerPC architecture version 2.01 and got obsolete
> > from version 2.01.
>
>
On Tue, 2020-03-24 at 14:18 +1100, Jordan Niethe wrote:
> On Mon, Mar 23, 2020 at 10:13 PM Balamuruhan S wrote:
> > On Fri, 2020-03-20 at 16:18 +1100, Jordan Niethe wrote:
> > > In preparation for prefixed instructions where all instructions are no
> > > longer words, use an accessor for getting
"Rafael J. Wysocki" writes:
> On Monday, March 16, 2020 2:57:43 PM CET Pratik Rajesh Sampat wrote:
>> The patch avoids allocating cpufreq_policy on stack hence fixing frame
>> size overflow in 'powernv_cpufreq_work_fn'
>>
>> Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to
Hi
Am 14.03.20 um 11:59 schrieb Krzysztof Kozlowski:
> On Thu, Mar 12, 2020 at 11:49:05AM +0100, Thomas Zimmermann wrote:
>> Hi Krzysztof,
>>
>> I just received a resend email from 3 weeks ago :/
>>
>> Do you want me to merge the mgag200 patch into drm-misc-next?
>
> Thanks but it depends on the
> On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V
> wrote:
>
> Sachin Sant writes:
>
>> While running ndctl[1] tests against 5.6.0-rc7 following crash is
>> encountered.
>>
>> Bisect leads me to commit d41e2f3bd546
>> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>>
>>
On 03/24/20 at 03:06pm, Sachin Sant wrote:
>
>
> > On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V
> > wrote:
> >
> > Sachin Sant writes:
> >
> >> While running ndctl[1] tests against 5.6.0-rc7 following crash is
> >> encountered.
> >>
> >> Bisect leads me to commit d41e2f3bd546
> >>
Sachin Sant writes:
> While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered.
>
> Bisect leads me to commit d41e2f3bd546
> mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
>
> Reverting this commit helps and the tests complete without any crash.
>
> pmem0:
Hi All,
The DMA mapping works great on our PowerPC machines currently. It was a
long way to get the new DMA mapping code to work successfully on our
PowerPC machines.
P L E A S E don't modify the good working DMA mapping code. There are
many other topics which needs improvements. For us
Hi Michael Ellerman,
On Thu, Mar 12, 2020 at 12:12:55PM +0530, afzal mohammed wrote:
> request_irq() is preferred over setup_irq(). Invocations of setup_irq()
> occur after memory allocators are ready.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the
On 3/23/20 8:02 PM, Haren Myneni wrote:
> On Mon, 2020-03-23 at 10:27 +0100, Cédric Le Goater wrote:
>> On 3/23/20 10:06 AM, Cédric Le Goater wrote:
>>> On 3/19/20 7:14 AM, Haren Myneni wrote:
Alloc IRQ and get trigger port address for each VAS instance. Kernel
register this IRQ per
On Fri, Mar 20, 2020 at 06:24:04PM +0530, Kajol Jain wrote:
SNIP
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 52fb119d25c8..b4b91d8ad5be 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -474,8 +474,13 @@ static bool
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
Le 24/03/2020 à 13:00, Greg Kurz a écrit :
On Tue, 24 Mar 2020 10:43:23 +1100
Paul Mackerras wrote:
On Fri, Mar 20, 2020 at 01:22:48PM +0100, Greg Kurz wrote:
On Fri, 20 Mar 2020 11:26:42 +0100
Laurent Dufour wrote:
The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
On Fri, Mar 20, 2020 at 06:24:04PM +0530, Kajol Jain wrote:
> Patch enhances current metric infrastructure to handle "?" in the metric
> expression. The "?" can be use for parameters whose value not known while
> creating metric events and which can be replace later at runtime to
> the proper
From: Vlastimil Babka
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x73b0
Faulting instruction address: 0xc03d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
On 3/24/20 3:26 AM, Oliver O'Halloran wrote:
> On Mon, Mar 23, 2020 at 8:28 PM Cédric Le Goater wrote:
>>
>> On 3/23/20 10:06 AM, Cédric Le Goater wrote:
>>> On 3/19/20 7:14 AM, Haren Myneni wrote:
Alloc IRQ and get trigger port address for each VAS instance. Kernel
register this
On 3/19/20 7:13 AM, Haren Myneni wrote:
>
> pnv_ocxl_alloc_xive_irq() in ocxl.c allocates IRQ and gets trigger port
> address. VAS also needs this function, but based on chip ID. So moved
> this common function to xive/native.c.
>
> Signed-off-by: Haren Myneni
I think we should work on a new
On Tue, 24 Mar 2020 10:43:23 +1100
Paul Mackerras wrote:
> On Fri, Mar 20, 2020 at 01:22:48PM +0100, Greg Kurz wrote:
> > On Fri, 20 Mar 2020 11:26:42 +0100
> > Laurent Dufour wrote:
> >
> > > The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing
> > > prevent a malicious VM
On 3/19/20 7:14 AM, Haren Myneni wrote:
>
> Alloc IRQ and get trigger port address for each VAS instance. Kernel
> register this IRQ per VAS instance and sets this port for each send
> window. NX interrupts the kernel when it sees page fault.
>
> Signed-off-by: Haren Myneni
> ---
>
On 3/19/20 7:12 AM, Haren Myneni wrote:
>
> This function allocates IRQ on a specific chip. VAS needs per chip
> IRQ allocation and will have IRQ handler per VAS instance.
>
> Signed-off-by: Haren Myneni
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> arch/powerpc/include/asm/xive.h |
Le 23/03/2020 à 15:04, Christophe Leroy a écrit :
On 03/23/2020 11:30 AM, Christophe Leroy wrote:
On 03/23/2020 04:52 AM, Christopher M. Riedl wrote:
When compiled with CONFIG_STRICT_KERNEL_RWX, the kernel must create
temporary mappings when patching itself. These mappings temporarily
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
x86 supports the notion of a temporary mm which restricts access to
temporary PTEs to a single CPU. A temporary mm is useful for situations
where a CPU needs to perform sensitive operations (such as patching a
STRICT_KERNEL_RWX kernel)
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
When code patching a STRICT_KERNEL_RWX kernel the page containing the
address to be patched is temporarily mapped with permissive memory
protections. Currently, a per-cpu vmalloc patch area is used for this
purpose. While the patch area is
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
Currently, code patching a STRICT_KERNEL_RWX exposes the temporary
mappings to other CPUs. These mappings should be kept local to the CPU
doing the patching. Use the pre-initialized temporary mm and patching
address for this purpose. Also
The if statement that this comment referred to was removed in
commit 11fdb309341c ("powerpc/prom_init: Remove support for OPAL v2").
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kernel/prom_init.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c
QEMU can now print the ibm,os-term message[1], so let's include it in
the RTAS call. E.g.:
qemu-system-ppc64: OS terminated: Switch to secure mode failed.
1- https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a4c3791ae0
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kernel/prom_init.c | 3 +++
Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
these SoCs is 32KiB and is split into 64 byte blocks (lines).
Signed-off-by: Chris Packham
---
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 16
1 file changed, 16 insertions(+)
diff --git
On Tue, Mar 24, 2020 at 08:15:39AM +, Will Deacon wrote:
> On Mon, Mar 23, 2020 at 02:23:49PM -0400, Joel Fernandes wrote:
> > On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> > > "Joel Fernandes (Google)" writes:
> > >
> > > > Reword and clarify better about the rwsem non-owner
On Tue, 2020-03-24 at 15:47 +1100, Michael Ellerman wrote:
> Chris Packham writes:
> > Hi All,
> >
> > Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
> > following mesage.
> >
> > kern.warning linuxbox kernel: Argh, can't find dcache properties !
> > kern.warning linuxbox
T0] radix-mmu: Mapped 0x-0x0160
with 2.00 MiB pages (exec)
[0.00][T0] radix-mmu: Mapped 0x0160-0x4000
with 2.00 MiB pages
[0.00][T0] radix-mmu: Mapped 0x4000-0x0020
with 1.00 GiB pages
[0
On Tue, 2020-03-24 at 15:48 +0100, Cédric Le Goater wrote:
> On 3/19/20 7:14 AM, Haren Myneni wrote:
> >
> > Alloc IRQ and get trigger port address for each VAS instance. Kernel
> > register this IRQ per VAS instance and sets this port for each send
> > window. NX interrupts the kernel when it
On 24 Mar 2020, at 1:22, Anshuman Khandual wrote:
> This adds new tests validating arch page table helpers for these following
> core memory features. These tests create and test specific mapping types at
> various page table levels.
>
> 1. SPECIAL mapping
> 2. PROTNONE mapping
> 3. DEVMAP
On Tue, Mar 24, 2020 at 06:48:20PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on March 19, 2020 10:19 pm:
> > There are two almost identical copies for 32bit and 64bit.
> >
> > The function is used only in 32bit code which will be split out in next
> > patch so consolidate to one function.
On 3/24/20 10:57 AM, Michael Ellerman wrote:
Ganesh Goudar writes:
If we hit UE at an instruction with a fixup entry, flag to
ignore the event and set nip to continue execution at the
fixup entry.
You don't explain why we would want to do that. Or what the consequences
are if we *don't* do
On Tue, Mar 24, 2020 at 06:54:20PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on March 19, 2020 10:19 pm:
> > diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
> > index 4b0152108f61..a264989626fd 100644
> > --- a/arch/powerpc/kernel/signal.c
> > +++
Chris Packham writes:
> Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
> these SoCs is 32KiB and is split into 64 byte blocks (lines).
>
> Signed-off-by: Chris Packham
> ---
> arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 16
> 1 file changed, 16
Paul,
"Paul E. McKenney" writes:
> On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> In the normal case where the task sleeps through the entire lock
> acquisition, the sequence of events is as follows:
>
> state = UNINTERRUPTIBLE
> lock()
>block()
>
On Wed, Mar 25, 2020 at 12:13:34AM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" writes:
> > On Sat, Mar 21, 2020 at 12:25:57PM +0100, Thomas Gleixner wrote:
> > In the normal case where the task sleeps through the entire lock
> > acquisition, the sequence of events is as follows:
On 3/23/20 8:47 PM, Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
wrote:
>
>
> On 2020/3/24 8:43, Mina Almasry wrote:
>> On Wed, Mar 18, 2020 at 3:07 PM Mike Kravetz wrote:
>>> +default_hugepagesz - Specify the default huge page size. This parameter
>>> can
>>> + only be
67 matches
Mail list logo
