On Mon, Jul 01, 2019 at 04:30:55PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 01/07/2019 16:17, maddy wrote:
> >
> > On 01/07/19 11:24 AM, Alexey Kardashevskiy wrote:
> >>
> >> On 29/06/2019 06:08, Claudio Carvalho wrote:
> >>> When the ultravisor firmware is available, it takes control over th
vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
Whether or not a vmap is huge depends on the architecture details,
alignments, boot options, etc., which the caller can not be expected
to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
This change teaches vmallo
The subsequent patch to fix vmalloc_to_page with huge vmap requires
HUGE_VMAP archs to provide p?d_large definitions for the non-pgd page
table levels they support.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 24
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_large() functions/macros.
For arm64, we already have p?d_sect() macros which we
This is a change broken out from the huge vmap vmalloc series as
requested. There is a little bit of dependency juggling across
trees, but patches are pretty trivial. Ideally if Andrew accepts
this patch and queues it up for next, then the arch patches would
be merged through those trees then patch
On 01/07/2019 16:17, maddy wrote:
>
> On 01/07/19 11:24 AM, Alexey Kardashevskiy wrote:
>>
>> On 29/06/2019 06:08, Claudio Carvalho wrote:
>>> When the ultravisor firmware is available, it takes control over the
>>> LDBAR register. In this case, thread-imc updates and save/restore
>>> operation
On 01/07/19 11:24 AM, Alexey Kardashevskiy wrote:
On 29/06/2019 06:08, Claudio Carvalho wrote:
When the ultravisor firmware is available, it takes control over the
LDBAR register. In this case, thread-imc updates and save/restore
operations on the LDBAR register are handled by ultravisor.
Wh
On 29/06/2019 06:08, Claudio Carvalho wrote:
> From: Ram Pai
>
> Ultravisor is responsible for flushing the tlb cache, since it manages
> the PATE entries. Hence skip tlb flush, if the ultravisor firmware is
> available.
>
> Signed-off-by: Ram Pai
> Signed-off-by: Claudio Carvalho
> ---
>
On 29/06/2019 06:08, Claudio Carvalho wrote:
> When the ultravisor firmware is available, it takes control over the
> LDBAR register. In this case, thread-imc updates and save/restore
> operations on the LDBAR register are handled by ultravisor.
What does LDBAR do? "Power ISA™ Version 3.0 B" or
On Friday 28 June 2019 10:57 PM, Nathan Lynch wrote:
> Aravinda Prasad writes:
>> Calculating the maximum memory based on the number of lmbs
>> and lmb size does not account for the RMA region. Hence
>> use memory_hotplug_max(), which already accounts for the
>> RMA region, to fetch the maximum
On 29/06/2019 08:33, Thiago Jung Bauermann wrote:
>
> Hello Alexey,
>
> Thanks for reviewing this patch!
>
> Alexey Kardashevskiy writes:
>
>> On 21/05/2019 14:49, Thiago Jung Bauermann wrote:
>>> @@ -1707,6 +1723,43 @@ static void __init prom_close_stdin(void)
>>> }
>>> }
>>>
>>> +#
On 29/06/2019 18:03, Christoph Hellwig wrote:
> Use the dma_get_mask helper from dma-mapping.h instead.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/include/asm/iommu.h | 8
> arch/powerpc/kernel/dma-iommu.c | 4 ++--
> a
Aneesh Kumar K.V's on June 29, 2019 5:38 pm:
> Also on hash with 4K PAGE_SIZE make sure we use 4K page size for
> vmemmap.
Can you add a line in the changelog to describe the radix problem
you fixed?
Also I would say the also could be a separate patch?
Thanks,
Nick
>
> Fixes: 2bfd65e45e87 ("po
On 28/6/19 10:30 pm, Mauro Carvalho Chehab wrote:
The content of this file is user-faced.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Andrew Donnellan
---
Documentation/{ => userspace-api}/accelerators/ocxl.rst | 2 --
Documentation/userspace-api/index.rst | 1 +
M
On Sat, Jun 29, 2019 at 5:39 PM Aneesh Kumar K.V
wrote:
>
> Allocation from altmap area can fail based on vmemmap page size used. Add
> kernel
> info message to indicate the failure. That allows the user to identify
> whether they
> are really using persistent memory reserved space for per-page
On Thu, 2019-06-20 at 01:46:51 UTC, Suraj Jitindar Singh wrote:
> If we enter an L1 guest with a pending decrementer exception then this
> is cleared on guest exit if the guest has writtien a positive value into
> the decrementer (indicating that it handled the decrementer exception)
> since there
On Thu, 2019-06-20 at 01:46:50 UTC, Suraj Jitindar Singh wrote:
> On POWER9 the decrementer can operate in large decrementer mode where
> the decrementer is 56 bits and signed extended to 64 bits. When not
> operating in this mode the decrementer behaves as a 32 bit decrementer
> which is NOT signe
On Mon, 2019-06-17 at 21:42:14 UTC, Christophe Leroy wrote:
> Previously, only IBAT1 and IBAT2 were used to map kernel linear mem.
> Since commit 63b2bc619565 ("powerpc/mm/32s: Use BATs for
> STRICT_KERNEL_RWX"), we may have all 8 BATs used for mapping
> kernel text. But the suspend/restore functio
On Mon, 2019-06-17 at 21:24:58 UTC, Gustavo Romero wrote:
> In some cases, compiler can allocate the same register for operand 'res'
> and 'vecoutptr', resulting in segfault at 'stxvd2x 40,0,%[vecoutptr]'
> because base register will contain 1, yielding a false-positive.
>
> This is because output
On Mon, 2019-06-17 at 21:22:20 UTC, Andreas Schwab wrote:
> Move a misplaced paren that makes the condition always true.
>
> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
> Signed-off-by: Andreas Schwab
> Reviewed-by: Christophe Leroy
Applied to powerpc next, thanks.
h
On Mon, 2019-06-17 at 09:07:13 UTC, Geert Uytterhoeven wrote:
> Flexible array members should be denoted using [] instead of [0], else
> gcc will not warn when they are no longer at the end of the structure.
>
> Signed-off-by: Geert Uytterhoeven
Applied to powerpc next, thanks.
https://git.kern
On Thu, 2019-06-13 at 03:30:14 UTC, Ravi Bangoria wrote:
> Powerpc hw triggers watchpoint before executing the instruction. To
> make trigger-after-execute behavior, kernel emulates the instruction.
> If the instruction is 'load something into non-volatile register',
> exception handler should rest
On Wed, 2019-06-12 at 15:54:18 UTC, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because there's no need to check, also make
On Mon, 2019-06-10 at 06:32:29 UTC, Anju T Sudhakar wrote:
> Nest and core imc(In-memory Collection counters) assigns a particular
> cpu as the designated target for counter data collection.
> During system boot, the first online cpu in a chip gets assigned as
> the designated cpu for that chip(for
On Mon, 2019-06-10 at 03:08:16 UTC, Nicholas Piggin wrote:
> __ioremap_at error handling is wonky, it requires caller to clean up
> after it. Implement a helper that does the map and error cleanup and
> remove the requirement from the caller.
>
> Signed-off-by: Nicholas Piggin
Series applied to
On Wed, 2019-06-05 at 03:38:14 UTC, Alexey Kardashevskiy wrote:
> When the firmware does PCI BAR resource allocation, it passes the assigned
> addresses and flags (prefetch/64bit/...) via the "reg" property of
> a PCI device device tree node so the kernel does not need to do
> resource allocation.
On Wed, 2019-05-29 at 09:21:51 UTC, Shaokun Zhang wrote:
> pr_info shows SPR and timebase as a decimal value with a '0x'
> prefix, which is somewhat misleading.
>
> Fix it to print hexadecimal, as was intended.
>
> Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
> Cc: Micha
On Tue, 2019-05-28 at 23:28:01 UTC, Nathan Lynch wrote:
> A couple of bugs in queue_hotplug_event():
>
> 1. Unchecked kmalloc result which could lead to an oops.
> 2. Use of GFP_KERNEL allocations in interrupt context (this code's
>only caller is ras_hotplug_interrupt()).
>
> Use kmemdup to a
On Fri, 2019-05-10 at 06:31:28 UTC, Christophe Leroy wrote:
> Otherwise, the following warning is encountered:
>
> WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the
> variable start_here_multiplatform to the function .init.text:.early_setup()
> The function start_here_multi
29 matches
Mail list logo
