* [PATCH 3/5] arm64: early ISB at exit from extended quiescent state
From: Yury Norov @ 2018-04-05 17:17 UTC (permalink / raw)
To: Paul E. McKenney, Mark Rutland, Will Deacon, Chris Metcalf,
Christopher Lameter, Russell King - ARM Linux, Steven Rostedt,
Mathieu Desnoyers, Catalin Marinas, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Alexey Klimov
Cc: Yury Norov, linux-arm-kernel, linuxppc-dev, kvm-ppc, linux-mm,
linux-kernel
In-Reply-To: <20180405171800.5648-1-ynorov@caviumnetworks.com>
This series enables delaying of kernel memory synchronization
for CPUs running in extended quiescent state (EQS) till the exit
of that state.
ARM64 uses IPI mechanism to notify all cores in SMP system that
kernel text is changed; and IPI handler calls isb() to synchronize.
If we don't deliver IPI to EQS CPUs anymore, we should add ISB early
in EQS exit path.
There are 2 such paths. One starts in do_idle() loop, and other
in el0_svc entry. For do_idle(), isb() is added in
arch_cpu_idle_exit() hook. And for SVC handler, isb is called in
el0_svc_naked.
Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
arch/arm64/kernel/entry.S | 16 +++++++++++++++-
arch/arm64/kernel/process.c | 7 +++++++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index c8d9ec363ddd..b1e1c19b4432 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -48,7 +48,7 @@
.endm
.macro el0_svc_restore_syscall_args
-#if defined(CONFIG_CONTEXT_TRACKING)
+#if !defined(CONFIG_TINY_RCU) || defined(CONFIG_CONTEXT_TRACKING)
restore_syscall_args
#endif
.endm
@@ -483,6 +483,19 @@ __bad_stack:
ASM_BUG()
.endm
+/*
+ * If CPU is in extended quiescent state we need isb to ensure that
+ * possible change of kernel text is visible by the core.
+ */
+ .macro isb_if_eqs
+#ifndef CONFIG_TINY_RCU
+ bl rcu_is_watching
+ cbnz x0, 1f
+ isb // pairs with aarch64_insn_patch_text
+1:
+#endif
+ .endm
+
el0_sync_invalid:
inv_entry 0, BAD_SYNC
ENDPROC(el0_sync_invalid)
@@ -949,6 +962,7 @@ alternative_else_nop_endif
el0_svc_naked: // compat entry point
stp x0, xscno, [sp, #S_ORIG_X0] // save the original x0 and syscall number
+ isb_if_eqs
enable_daif
ct_user_exit
el0_svc_restore_syscall_args
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f08a2ed9db0d..74cad496b07b 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -88,6 +88,13 @@ void arch_cpu_idle(void)
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
+void arch_cpu_idle_exit(void)
+{
+ /* Pairs with aarch64_insn_patch_text() for EQS CPUs. */
+ if (!rcu_is_watching())
+ isb();
+}
+
#ifdef CONFIG_HOTPLUG_CPU
void arch_cpu_idle_dead(void)
{
--
2.14.1
^ permalink raw reply related
* [PATCH 2/5] arm64: entry: introduce restore_syscall_args macro
From: Yury Norov @ 2018-04-05 17:17 UTC (permalink / raw)
To: Paul E. McKenney, Mark Rutland, Will Deacon, Chris Metcalf,
Christopher Lameter, Russell King - ARM Linux, Steven Rostedt,
Mathieu Desnoyers, Catalin Marinas, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Alexey Klimov
Cc: Yury Norov, linux-arm-kernel, linuxppc-dev, kvm-ppc, linux-mm,
linux-kernel
In-Reply-To: <20180405171800.5648-1-ynorov@caviumnetworks.com>
Syscall arguments are passed in registers x0..x7. If assembler
code has to call C functions before passing control to syscall
handler, it should restore original state of that registers
after the call.
Currently, syscall arguments restoring is opencoded in el0_svc_naked
and __sys_trace. This patch introduces restore_syscall_args macro to
use it there.
Also, parameter 'syscall = 0' is removed from ct_user_exit to make
el0_svc_naked call restore_syscall_args explicitly. This is needed
because the following patch of the series adds another call to C
function in el0_svc_naked, and restoring of syscall args becomes not
only a matter of ct_user_exit.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
arch/arm64/kernel/entry.S | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 9c06b4b80060..c8d9ec363ddd 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -37,22 +37,29 @@
#include <asm/unistd.h>
/*
- * Context tracking subsystem. Used to instrument transitions
- * between user and kernel mode.
+ * Save/restore needed during syscalls. Restore syscall arguments from
+ * the values already saved on stack during kernel_entry.
*/
- .macro ct_user_exit, syscall = 0
-#ifdef CONFIG_CONTEXT_TRACKING
- bl context_tracking_user_exit
- .if \syscall == 1
- /*
- * Save/restore needed during syscalls. Restore syscall arguments from
- * the values already saved on stack during kernel_entry.
- */
+ .macro restore_syscall_args
ldp x0, x1, [sp]
ldp x2, x3, [sp, #S_X2]
ldp x4, x5, [sp, #S_X4]
ldp x6, x7, [sp, #S_X6]
- .endif
+ .endm
+
+ .macro el0_svc_restore_syscall_args
+#if defined(CONFIG_CONTEXT_TRACKING)
+ restore_syscall_args
+#endif
+ .endm
+
+/*
+ * Context tracking subsystem. Used to instrument transitions
+ * between user and kernel mode.
+ */
+ .macro ct_user_exit
+#ifdef CONFIG_CONTEXT_TRACKING
+ bl context_tracking_user_exit
#endif
.endm
@@ -943,7 +950,8 @@ alternative_else_nop_endif
el0_svc_naked: // compat entry point
stp x0, xscno, [sp, #S_ORIG_X0] // save the original x0 and syscall number
enable_daif
- ct_user_exit 1
+ ct_user_exit
+ el0_svc_restore_syscall_args
tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
b.ne __sys_trace
@@ -976,10 +984,7 @@ __sys_trace:
mov x1, sp // pointer to regs
cmp wscno, wsc_nr // check upper syscall limit
b.hs __ni_sys_trace
- ldp x0, x1, [sp] // restore the syscall args
- ldp x2, x3, [sp, #S_X2]
- ldp x4, x5, [sp, #S_X4]
- ldp x6, x7, [sp, #S_X6]
+ restore_syscall_args
ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
blr x16 // call sys_* routine
--
2.14.1
^ permalink raw reply related
* [PATCH 1/5] arm64: entry: isb in el1_irq
From: Yury Norov @ 2018-04-05 17:17 UTC (permalink / raw)
To: Paul E. McKenney, Mark Rutland, Will Deacon, Chris Metcalf,
Christopher Lameter, Russell King - ARM Linux, Steven Rostedt,
Mathieu Desnoyers, Catalin Marinas, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Alexey Klimov
Cc: Yury Norov, linux-arm-kernel, linuxppc-dev, kvm-ppc, linux-mm,
linux-kernel
In-Reply-To: <20180405171800.5648-1-ynorov@caviumnetworks.com>
Kernel text patching framework relies on IPI to ensure that other
SMP cores observe the change. Target core calls isb() in IPI handler
path, but not at the beginning of el1_irq entry. There's a chance
that modified instruction will appear prior isb(), and so will not be
observed.
This patch inserts isb early at el1_irq entry to avoid that chance.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
arch/arm64/kernel/entry.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index ec2ee720e33e..9c06b4b80060 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -593,6 +593,7 @@ ENDPROC(el1_sync)
.align 6
el1_irq:
+ isb // pairs with aarch64_insn_patch_text
kernel_entry 1
enable_da_f
#ifdef CONFIG_TRACE_IRQFLAGS
--
2.14.1
^ permalink raw reply related
* [PATCH v2 0/2] smp: don't kick CPUs running idle or nohz_full tasks
From: Yury Norov @ 2018-04-05 17:17 UTC (permalink / raw)
To: Paul E. McKenney, Mark Rutland, Will Deacon, Chris Metcalf,
Christopher Lameter, Russell King - ARM Linux, Steven Rostedt,
Mathieu Desnoyers, Catalin Marinas, Pekka Enberg, David Rientjes,
Joonsoo Kim, Andrew Morton, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Alexey Klimov
Cc: Yury Norov, linux-arm-kernel, linuxppc-dev, kvm-ppc, linux-mm,
linux-kernel
kick_all_cpus_sync() is used to broadcast IPIs to all online CPUs to force
them synchronize caches, TLB etc. It is called only 3 times - from mm/slab
arm64 and powerpc code.
We can delay synchronization work for CPUs in extended quiescent state
(idle or nohz_full userspace).
As Paul E. McKenney wrote:
--
Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change. This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings. It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to do the flush, first to avoid
interrupting usemode tasks and second to handle multiple flush requests
with a single flush in the case of a long-running user task.
--
v2 is big rework to address comments in v1:
- rcu_eqs_special() declaration in public header is dropped, it is not
used in new implementation. Though, I hope Paul will pick it in his
tree;
- for arm64, few isb() added to ensure kernel text synchronization
(patches 1-4);
- rcu_get_eqs_cpus() introduced and used to mask EQS CPUs before
generating broadcast IPIs;
- RCU_DYNTICK_CTRL_MASK is not touched because memory barrier is
implicitly issued in EQS exit path;
- powerpc is not an exception anymore. I think it's safe to delay
synchronization for it as well, and I didn't get comments from ppc
community.
v1:
https://lkml.org/lkml/2018/3/25/109
Based on next-20180405
Yury Norov (5):
arm64: entry: isb in el1_irq
arm64: entry: introduce restore_syscall_args macro
arm64: ISB early at exit from extended quiescent state
rcu: arm64: add rcu_dynticks_eqs_exit_sync()
smp: Lazy synchronization for EQS CPUs in kick_all_cpus_sync()
arch/arm64/kernel/Makefile | 2 ++
arch/arm64/kernel/entry.S | 52 +++++++++++++++++++++++++++++++--------------
arch/arm64/kernel/process.c | 7 ++++++
arch/arm64/kernel/rcu.c | 8 +++++++
include/linux/rcutiny.h | 2 ++
include/linux/rcutree.h | 1 +
kernel/rcu/tiny.c | 9 ++++++++
kernel/rcu/tree.c | 27 +++++++++++++++++++++++
kernel/smp.c | 21 +++++++++++-------
9 files changed, 105 insertions(+), 24 deletions(-)
create mode 100644 arch/arm64/kernel/rcu.c
--
2.14.1
^ permalink raw reply
* Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key
From: Laurent Dufour @ 2018-04-05 16:55 UTC (permalink / raw)
To: David Rientjes
Cc: kernel test robot, paulmck, peterz, akpm, kirill, ak, mhocko,
dave, jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
sergey.senozhatsky.work, Daniel Jordan, linux-kernel, linux-mm,
haren, khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev,
x86, lkp
In-Reply-To: <alpine.DEB.2.20.1804041451220.152749@chino.kir.corp.google.com>
On 04/04/2018 23:53, David Rientjes wrote:
> On Wed, 4 Apr 2018, Laurent Dufour wrote:
>
>>> I also think the following is needed:
>>>
>>> diff --git a/fs/exec.c b/fs/exec.c
>>> --- a/fs/exec.c
>>> +++ b/fs/exec.c
>>> @@ -312,6 +312,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
>>> vma->vm_flags = VM_SOFTDIRTY | VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP;
>>> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>>> INIT_LIST_HEAD(&vma->anon_vma_chain);
>>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>>> + seqcount_init(&vma->vm_sequence);
>>> + atomic_set(&vma->vm_ref_count, 0);
>>> +#endif
>>>
>>> err = insert_vm_struct(mm, vma);
>>> if (err)
>>
>> No, this not needed because the vma is allocated with kmem_cache_zalloc() so
>> vm_ref_count is 0, and insert_vm_struc() will later call
>> __vma_link_rb() which will call seqcount_init().
>>
>> Furhtermore, in case of error, the vma structure is freed without calling
>> get_vma() so there is risk of lockdep warning.
>>
>
> Perhaps you're working from a different tree than I am, or you fixed the
> lockdep warning differently when adding to dup_mmap() and mmap_region().
>
> I got the following two lockdep errors.
>
> I fixed it locally by doing the seqcount_init() and atomic_set()
> everywhere a vma could be initialized.
That's weird, I don't get that on my side with lockdep activated.
There is a call to seqcount_init() in dup_mmap(), in mmap_region() and
__vma_link_rb() and that's enough to cover all the case.
That's being said, it'll be better call seqcount_init each time as soon as a
vma structure is allocated. For the vm_ref_count value, as most of the time the
vma is zero allocated, I don't think this is needed.
I just have to check when new_vma = *old_vma is done, but this often just
follow a vma allocation.
>
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 12 PID: 1 Comm: init Not tainted
> Call Trace:
> [<ffffffff8b12026f>] dump_stack+0x67/0x98
> [<ffffffff8a92b616>] register_lock_class+0x1e6/0x4e0
> [<ffffffff8a92cfe9>] __lock_acquire+0xb9/0x1710
> [<ffffffff8a92ef3a>] lock_acquire+0xba/0x200
> [<ffffffff8aa827df>] mprotect_fixup+0x10f/0x310
> [<ffffffff8aade3fd>] setup_arg_pages+0x12d/0x230
> [<ffffffff8ab4564a>] load_elf_binary+0x44a/0x1740
> [<ffffffff8aadde9b>] search_binary_handler+0x9b/0x1e0
> [<ffffffff8ab44e96>] load_script+0x206/0x270
> [<ffffffff8aadde9b>] search_binary_handler+0x9b/0x1e0
> [<ffffffff8aae0355>] do_execveat_common.isra.32+0x6b5/0x9d0
> [<ffffffff8aae069c>] do_execve+0x2c/0x30
> [<ffffffff8a80047b>] run_init_process+0x2b/0x30
> [<ffffffff8b1358d4>] kernel_init+0x54/0x110
> [<ffffffff8b2001ca>] ret_from_fork+0x3a/0x50
>
> and
>
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 21 PID: 1926 Comm: mkdir Not tainted
> Call Trace:
> [<ffffffff985202af>] dump_stack+0x67/0x98
> [<ffffffff97d2b616>] register_lock_class+0x1e6/0x4e0
> [<ffffffff97d2cfe9>] __lock_acquire+0xb9/0x1710
> [<ffffffff97d2ef3a>] lock_acquire+0xba/0x200
> [<ffffffff97e73c09>] unmap_page_range+0x89/0xaa0
> [<ffffffff97e746af>] unmap_single_vma+0x8f/0x100
> [<ffffffff97e74a1b>] unmap_vmas+0x4b/0x90
> [<ffffffff97e7f833>] exit_mmap+0xa3/0x1c0
> [<ffffffff97cc1b23>] mmput+0x73/0x120
> [<ffffffff97ccbacd>] do_exit+0x2bd/0xd60
> [<ffffffff97ccc5b7>] SyS_exit+0x17/0x20
> [<ffffffff97c01f1d>] do_syscall_64+0x6d/0x1a0
> [<ffffffff9860005a>] entry_SYSCALL_64_after_hwframe+0x26/0x9b
>
> I think it would just be better to generalize vma allocation to initialize
> certain fields and init both spf fields properly for
> CONFIG_SPECULATIVE_PAGE_FAULT. It's obviously too delicate as is.
>
^ permalink raw reply
* Re: [RFC 1/2] powerpc/swiotlb: Dont free up allocated SWIOTLB slab on POWER
From: Ram Pai @ 2018-04-05 16:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Anshuman Khandual, linuxppc-dev
In-Reply-To: <87fu4bcf34.fsf@concordia.ellerman.id.au>
On Wed, Apr 04, 2018 at 10:48:31PM +1000, Michael Ellerman wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> > Even though SWIOTLB slab gets allocated and initialized on powerpc with
> > swiotlb_init() called during mem_init(), it gets released away again on
> > POWER platform because 'ppc_swiotlb_enable' never gets set. The function
> > swiotlb_detect_4g() checks for 4GB memory and then sets the variable
> > 'ppc_swiotlb_enable' which prevents freeing up the SWIOTLB slab. Lets
> > make POWER platform call swiotlb_detect_4g() during setup_arch() which
> > will keep the SWIOTLB slab through out the runtime.
> >
> > A previous commit cf5621032f ("powerpc/64: Limit ZONE_DMA32 to 4GiB in
> > swiotlb_detect_4g()") enforced 4GB limit on ZONE_DMA32 which is is not
> > applicable on POWER (CONFIG_PPC_BOOK3S_64) platform. Lets remove this
> > unnecessary restriction.
>
> You're using "POWER" to mean Book3S 64-bit, but "POWER" is something
> else (the ISA for POWER1/POWER2).
>
> So please just say "Book3S 64-bit" or talk about a specific CPU, eg.
> Power9.
>
> > After the patch, SWIOTLB slab does not get released.
> >
> > [0.410992] software IO TLB [mem 0xfbff0000-0xffff0000] (64MB) mapped
> > at [00000000767f6cb3-000000004a10114f]
>
> But we don't want SWIOTLB on any existing Book3S 64-bit platforms, so
> leaving it enabled is just wasting memory.
>
> > diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> > index d73ec518ef80..c4db844e0b0d 100644
> > --- a/arch/powerpc/kernel/setup-common.c
> > +++ b/arch/powerpc/kernel/setup-common.c
> > @@ -944,6 +944,7 @@ void __init setup_arch(char **cmdline_p)
> > /* Initialize the MMU context management stuff. */
> > mmu_context_init();
> >
> > + swiotlb_detect_4g();
>
> You shouldn't be calling this, your use case has nothing to do with 4GB.
>
> Instead when you detect that you're running under the ultravisor then
> you should set ppc_swiotlb_enable = 1.
Please assume that you will have a interface to detect if you are
running in a protected-environment(AKA secure-environment).
So maybe you can rename swiotlb_detect_4g() to swiotlb_detect()
and modify that function to enable or disable ppc_swiotlb_enable
depending on the availability of 4g or availability of
protected-environment?
RP
^ permalink raw reply
* [PATCH v3] powerpc/64: Fix section mismatch warnings for early boot symbols
From: Mauricio Faria de Oliveira @ 2018-04-05 15:50 UTC (permalink / raw)
To: linux-kernel, jeyu; +Cc: jeyu, akpm, mpe, npiggin, linuxppc-dev
Some of the boot code located at the start of kernel text is "init"
class, in that it only runs at boot time, however marking it as normal
init code is problematic because that puts it into a different section
located at the very end of kernel text.
e.g., in case the TOC is not set up, we may not be able to tolerate a
branch trampoline to reach the init function.
Credits: code and message are based on 2016 patch by Nicholas Piggin,
and slightly modified so not to rename the powerpc code/symbol names.
Subject: [PATCH] powerpc/64: quieten section mismatch warnings
From: Nicholas Piggin <npiggin at gmail.com>
Date: Fri Dec 23 00:14:19 AEDT 2016
This resolves the following section mismatch warnings:
WARNING: vmlinux.o(.text+0x2fa8): Section mismatch in reference from the variable __boot_from_prom to the function .init.text:prom_init()
The function __boot_from_prom() references
the function __init prom_init().
This is often because __boot_from_prom lacks a __init
annotation or the annotation of prom_init is wrong.
WARNING: vmlinux.o(.text+0x3238): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:early_setup()
The function start_here_multiplatform() references
the function __init early_setup().
This is often because start_here_multiplatform lacks a __init
annotation or the annotation of early_setup is wrong.
WARNING: vmlinux.o(.text+0x326c): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel()
The function start_here_common() references
the function __init start_kernel().
This is often because start_here_common lacks a __init
annotation or the annotation of start_kernel is wrong.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
---
v3: reword some comments and include errors in commit message
v2: fix build error due to missing parenthesis
scripts/mod/modpost.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 4ff08a0..d10c9d8 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1173,8 +1173,15 @@ static const struct sectioncheck *section_mismatch(
* fromsec = text section
* refsymname = *.constprop.*
*
+ * Pattern 6:
+ * powerpc64 has boot functions that reference init, but must remain in text.
+ * This pattern is identified by
+ * tosec = init section
+ * fromsym = __boot_from_prom, start_here_common, start_here_multiplatform
+ *
**/
-static int secref_whitelist(const struct sectioncheck *mismatch,
+static int secref_whitelist(const struct elf_info *elf,
+ const struct sectioncheck *mismatch,
const char *fromsec, const char *fromsym,
const char *tosec, const char *tosym)
{
@@ -1211,6 +1218,17 @@ static int secref_whitelist(const struct sectioncheck *mismatch,
match(fromsym, optim_symbols))
return 0;
+ /* Check for pattern 6 */
+ if (elf->hdr->e_machine == EM_PPC64)
+ if (match(tosec, init_sections) &&
+ (!strncmp(fromsym, "__boot_from_prom",
+ strlen("__boot_from_prom")) ||
+ !strncmp(fromsym, "start_here_common",
+ strlen("start_here_common")) ||
+ !strncmp(fromsym, "start_here_multiplatform",
+ strlen("start_here_multiplatform"))))
+ return 0;
+
return 1;
}
@@ -1551,7 +1569,7 @@ static void default_mismatch_handler(const char *modname, struct elf_info *elf,
tosym = sym_name(elf, to);
/* check whitelist - we may ignore it */
- if (secref_whitelist(mismatch,
+ if (secref_whitelist(elf, mismatch,
fromsec, fromsym, tosec, tosym)) {
report_sec_mismatch(modname, mismatch,
fromsec, r->r_offset, fromsym,
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU
From: Benjamin Herrenschmidt @ 2018-04-05 15:09 UTC (permalink / raw)
To: Michael S. Tsirkin, Anshuman Khandual
Cc: virtualization, linux-kernel, robh, aik, jasowang, joe,
linuxppc-dev, elfring, david
In-Reply-To: <20180405175326-mutt-send-email-mst@kernel.org>
On Thu, 2018-04-05 at 17:54 +0300, Michael S. Tsirkin wrote:
> On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote:
> > On 04/05/2018 04:26 PM, Anshuman Khandual wrote:
> > > There are certian platforms which would like to use SWIOTLB based DMA API
> > > for bouncing purpose without actually requiring an IOMMU back end. But the
> > > virtio core does not allow such mechanism. Right now DMA MAP API is only
> > > selected for devices which have an IOMMU and then the QEMU/host back end
> > > will process all incoming SG buffer addresses as IOVA instead of simple
> > > GPA which is the case for simple bounce buffers after being processed with
> > > SWIOTLB API. To enable this usage, it introduces an architecture specific
> > > function which will just make virtio core front end select DMA operations
> > > structure.
> > >
> > > Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> >
> > + "Michael S. Tsirkin" <mst@redhat.com>
>
> I'm confused by this.
>
> static bool vring_use_dma_api(struct virtio_device *vdev)
> {
> if (!virtio_has_iommu_quirk(vdev))
> return true;
>
>
> Why doesn't setting VIRTIO_F_IOMMU_PLATFORM on the
> hypervisor side sufficient?
In this specific case, because that would make qemu expect an iommu,
and there isn't one.
Anshuman, you need to provide more background here. I don't have time
right now it's late, but explain about the fact that this is for a
specific type of secure VM which has only a limited pool of (insecure)
memory that can be shared with qemu, so all IOs need to bounce via that
pool, which can be achieved by using swiotlb.
Note: this isn't urgent, we can discuss alternative approaches, this is
just to start the conversation.
Cheers,
Ben.
^ permalink raw reply
* Re: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem
From: Dan Williams @ 2018-04-05 15:00 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Balbir Singh, Michael Ellerman, linuxppc-dev, linux-nvdimm,
Christoph Hellwig, Matthew Wilcox, Luck, Tony
In-Reply-To: <20180405164508.7a15a770@roar.ozlabs.ibm.com>
On Wed, Apr 4, 2018 at 11:45 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Thu, 5 Apr 2018 15:53:07 +1000
> Balbir Singh <bsingharora@gmail.com> wrote:
>
>> On Thu, 5 Apr 2018 15:04:05 +1000
>> Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> > On Wed, 4 Apr 2018 20:00:52 -0700
>> > Dan Williams <dan.j.williams@intel.com> wrote:
>> >
>> > > [ adding Matthew, Christoph, and Tony ]
>> > >
>> > > On Wed, Apr 4, 2018 at 4:57 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>> > > > On Thu, 5 Apr 2018 09:19:42 +1000
>> > > > Balbir Singh <bsingharora@gmail.com> wrote:
>> > > >
>> > > >> The pmem infrastructure uses memcpy_mcsafe in the pmem
>> > > >> layer so as to convert machine check excpetions into
>> > > >> a return value on failure in case a machine check
>> > > >> exception is encoutered during the memcpy.
>> > > >>
>> > > >> 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.
>> > > >
>> > > > So memcpy_mcsafe doesn't return number of bytes copied?
>> > > > Huh, well that makes it simple.
>> > >
>> > > Well, not in current kernels, but we need to add that support or
>> > > remove the direct call to copy_to_iter() in fs/dax.c. I'm looking
>> > > right now to add "bytes remaining" support to the x86 memcpy_mcsafe(),
>> > > but for copy_to_user we also need to handle bytes remaining for write
>> > > faults. That fix is hopefully something that can land in an early
>> > > 4.17-rc, but it won't be ready for -rc1.
>> >
>> > I wonder if the powerpc implementation should just go straight to
>> > counting bytes. Backporting to this interface would be trivial, but
>> > it would just mean there's only one variant of the code to support.
>> > That's up to Balbir though.
>> >
>>
>> I'm thinking about it, I wonder what "bytes remaining" mean in pmem context
>> in the context of a machine check exception. Also, do we want to be byte
>> accurate or cache-line accurate for the bytes remaining? The former is much
>> easier than the latter :)
>
> The ideal would be a linear measure of how much of your copy reached
> (or can reach) non-volatile storage with nothing further copied. You
> may have to allow for some relaxing of the semantics depending on
> what the architecture can support.
>
> What's the problem with just counting bytes copied like usercopy --
> why is that harder than cacheline accuracy?
>
>> I'd rather implement the existing interface and port/support the new interface
>> as it becomes available
>
> Fair enough.
I have patches already in progress to change the interface. My
preference is to hold off on adding a new implementation that will
need to be immediately reworked. When I say "immediate" I mean that
should be able to post what I have for review within the next few
days.
Whether this is all too late for 4.17 is another question...
^ permalink raw reply
* Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU
From: Michael S. Tsirkin @ 2018-04-05 14:54 UTC (permalink / raw)
To: Anshuman Khandual
Cc: virtualization, linux-kernel, robh, aik, jasowang, joe,
linuxppc-dev, elfring, david
In-Reply-To: <3e1b113b-79ca-b700-5be9-10c66d74aabe@linux.vnet.ibm.com>
On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote:
> On 04/05/2018 04:26 PM, Anshuman Khandual wrote:
> > There are certian platforms which would like to use SWIOTLB based DMA API
> > for bouncing purpose without actually requiring an IOMMU back end. But the
> > virtio core does not allow such mechanism. Right now DMA MAP API is only
> > selected for devices which have an IOMMU and then the QEMU/host back end
> > will process all incoming SG buffer addresses as IOVA instead of simple
> > GPA which is the case for simple bounce buffers after being processed with
> > SWIOTLB API. To enable this usage, it introduces an architecture specific
> > function which will just make virtio core front end select DMA operations
> > structure.
> >
> > Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>
> + "Michael S. Tsirkin" <mst@redhat.com>
I'm confused by this.
static bool vring_use_dma_api(struct virtio_device *vdev)
{
if (!virtio_has_iommu_quirk(vdev))
return true;
Why doesn't setting VIRTIO_F_IOMMU_PLATFORM on the
hypervisor side sufficient?
^ permalink raw reply
* [PATCH] powerpc/powernv: do not process OPAL events from hard interrupt context
From: Nicholas Piggin @ 2018-04-05 14:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Using irq_work for processing batches of OPAL events can cause latency
spikes. irq_work is typically used just to schedule work from NMI
context or for work that specifically needs to execute in interrupt
context. If we are to remain with this approach to OPAL events,
softirqs would be a better fit.
But they are not required either. OPAL events are not particularly
performance or latency critical, and we already have kopald to poll
and run events, so have kopald run them all. Rather than scheduling
them as irq_work, just run them directly from kopald. Enable and
disable interrupts between processing each event.
Event handlers themselves should still use threaded handlers,
workqueues, etc. as necessary to avoid high interrupts-off latencies
within any single interrupt.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/opal-irqchip.c | 85 ++++++++++++---------------
arch/powerpc/platforms/powernv/opal.c | 23 ++++----
arch/powerpc/platforms/powernv/powernv.h | 3 +-
3 files changed, 51 insertions(+), 60 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
index 9d1b8c0aaf93..646bfac8e3f5 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -22,7 +22,6 @@
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/irq_work.h>
#include <asm/machdep.h>
#include <asm/opal.h>
@@ -38,37 +37,47 @@ struct opal_event_irqchip {
unsigned long mask;
};
static struct opal_event_irqchip opal_event_irqchip;
-
+static u64 last_outstanding_events;
static unsigned int opal_irq_count;
static unsigned int *opal_irqs;
-static void opal_handle_irq_work(struct irq_work *work);
-static u64 last_outstanding_events;
-static struct irq_work opal_event_irq_work = {
- .func = opal_handle_irq_work,
-};
-
-void opal_handle_events(uint64_t events)
+void opal_handle_events(void)
{
- int virq, hwirq = 0;
- u64 mask = opal_event_irqchip.mask;
+ __be64 events = 0;
+ u64 e;
+
+ e = last_outstanding_events & opal_event_irqchip.mask;
+again:
+ while (e) {
+ int virq, hwirq;
+
+ hwirq = fls64(e) - 1;
+ e &= ~BIT_ULL(hwirq);
+
+ local_irq_disable();
+ virq = irq_find_mapping(opal_event_irqchip.domain, hwirq);
+ if (virq) {
+ irq_enter();
+ generic_handle_irq(virq);
+ irq_exit();
+ }
+ local_irq_enable();
- if (!in_irq() && (events & mask)) {
- last_outstanding_events = events;
- irq_work_queue(&opal_event_irq_work);
- return;
+ cond_resched();
}
+ last_outstanding_events = 0;
+ if (opal_poll_events(&events) != OPAL_SUCCESS)
+ return;
+ e = be64_to_cpu(events) & opal_event_irqchip.mask;
+ if (e)
+ goto again;
+}
- while (events & mask) {
- hwirq = fls64(events) - 1;
- if (BIT_ULL(hwirq) & mask) {
- virq = irq_find_mapping(opal_event_irqchip.domain,
- hwirq);
- if (virq)
- generic_handle_irq(virq);
- }
- events &= ~BIT_ULL(hwirq);
- }
+bool opal_recheck_events(void)
+{
+ if (last_outstanding_events & opal_event_irqchip.mask)
+ return true;
+ return false;
}
static void opal_event_mask(struct irq_data *d)
@@ -78,24 +87,9 @@ static void opal_event_mask(struct irq_data *d)
static void opal_event_unmask(struct irq_data *d)
{
- __be64 events;
-
set_bit(d->hwirq, &opal_event_irqchip.mask);
-
- opal_poll_events(&events);
- last_outstanding_events = be64_to_cpu(events);
-
- /*
- * We can't just handle the events now with opal_handle_events().
- * If we did we would deadlock when opal_event_unmask() is called from
- * handle_level_irq() with the irq descriptor lock held, because
- * calling opal_handle_events() would call generic_handle_irq() and
- * then handle_level_irq() which would try to take the descriptor lock
- * again. Instead queue the events for later.
- */
if (last_outstanding_events & opal_event_irqchip.mask)
- /* Need to retrigger the interrupt */
- irq_work_queue(&opal_event_irq_work);
+ opal_wake_poller();
}
static int opal_event_set_type(struct irq_data *d, unsigned int flow_type)
@@ -136,16 +130,13 @@ static irqreturn_t opal_interrupt(int irq, void *data)
__be64 events;
opal_handle_interrupt(virq_to_hw(irq), &events);
- opal_handle_events(be64_to_cpu(events));
+ last_outstanding_events = be64_to_cpu(events);
+ if (last_outstanding_events & opal_event_irqchip.mask)
+ opal_wake_poller();
return IRQ_HANDLED;
}
-static void opal_handle_irq_work(struct irq_work *work)
-{
- opal_handle_events(last_outstanding_events);
-}
-
static int opal_event_match(struct irq_domain *h, struct device_node *node,
enum irq_domain_bus_token bus_token)
{
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index fb13bcabe609..f7c7546e4145 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -537,21 +537,15 @@ int opal_hmi_exception_early(struct pt_regs *regs)
/* HMI exception handler called in virtual mode during check_irq_replay. */
int opal_handle_hmi_exception(struct pt_regs *regs)
{
- s64 rc;
- __be64 evt = 0;
-
/*
* Check if HMI event is available.
- * if Yes, then call opal_poll_events to pull opal messages and
- * process them.
+ * if Yes, then call opal_handle_events to process them.
*/
if (!local_paca->hmi_event_available)
return 0;
local_paca->hmi_event_available = 0;
- rc = opal_poll_events(&evt);
- if (rc == OPAL_SUCCESS && evt)
- opal_handle_events(be64_to_cpu(evt));
+ opal_wake_poller();
return 1;
}
@@ -754,14 +748,19 @@ static void __init opal_imc_init_dev(void)
static int kopald(void *unused)
{
unsigned long timeout = msecs_to_jiffies(opal_heartbeat) + 1;
- __be64 events;
set_freezable();
do {
try_to_freeze();
- opal_poll_events(&events);
- opal_handle_events(be64_to_cpu(events));
- schedule_timeout_interruptible(timeout);
+
+ opal_handle_events();
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (opal_recheck_events())
+ __set_current_state(TASK_RUNNING);
+ else
+ schedule_timeout(timeout);
+
} while (!kthread_should_stop());
return 0;
diff --git a/arch/powerpc/platforms/powernv/powernv.h b/arch/powerpc/platforms/powernv/powernv.h
index 94f17ab1374b..31cf221092df 100644
--- a/arch/powerpc/platforms/powernv/powernv.h
+++ b/arch/powerpc/platforms/powernv/powernv.h
@@ -24,7 +24,8 @@ extern u32 pnv_get_supported_cpuidle_states(void);
extern void pnv_lpc_init(void);
-extern void opal_handle_events(uint64_t events);
+extern void opal_handle_events(void);
+extern bool opal_recheck_events(void);
extern void opal_event_shutdown(void);
bool cpu_core_split_required(void);
--
2.16.3
^ permalink raw reply related
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Dan Williams @ 2018-04-05 14:43 UTC (permalink / raw)
To: Oliver; +Cc: Michael Ellerman, Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <CAOSf1CEUnucUhW_pXG=7h5QBHvaH2-ENPKjGD42_0WEvbU6-Wg@mail.gmail.com>
On Thu, Apr 5, 2018 at 5:43 AM, Oliver <oohall@gmail.com> wrote:
> On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Oliver <oohall@gmail.com> writes:
>> ...
>>>
>>> For context Balbir is working with me on some of the pmem stuff. You
>>> probably want an Ack from Rob rather than one of us.
>>
>> I'll ack it if you make all the niggly nit picky trivial annoying
>> changes I asked for :D
>
> *groan*
>
> Fine, I'll respin it tomorrow. If anyone else has comments now would
> be the time to make them.
Please also include my niggly nit picky trivial annoying bike shed
color for the driver name to *not* use the "nd_region" suffix for a
driver registering "nvdimm_bus" objects. "of_pmem_range" or
"of_pmem_bus" or almost anything else would be fine.
^ permalink raw reply
* Re: powerpc/64s/idle: POWER9 restore AMOR after deep sleep
From: Michael Ellerman @ 2018-04-05 14:42 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180405061000.30513-1-npiggin@gmail.com>
On Thu, 2018-04-05 at 06:10:00 UTC, Nicholas Piggin wrote:
> POWER8 restores AMOR when waking from deep sleep, but POWER9 does not,
> because it does not go through the subcore restore.
>
> Have POWER9 restore it in core restore.
>
> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c1b25a17d24925b0961c319cfc3fd7
cheers
^ permalink raw reply
* Re: [1/2] powerpc/64s: Fix pkey support in dt_cpu_ftrs, add CPU_FTR_PKEY bit
From: Michael Ellerman @ 2018-04-05 14:42 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Ram Pai, Nicholas Piggin
In-Reply-To: <20180405055755.30090-2-npiggin@gmail.com>
On Thu, 2018-04-05 at 05:57:54 UTC, Nicholas Piggin wrote:
> The pkey code added a CPU_FTR_PKEY bit, but did not add it to the
> dt_cpu_ftrs feature set. Although capability is supported by all
> processors in the base dt_cpu_ftrs set for 64s, it's a significant
> and sufficiently well defined feature to make it optional. So add
> it as a quirk for now, which can be versioned out then controlled
> by the firmware (once dt_cpu_ftrs gains versioning support).
>
> Fixes: cf43d3b264 ("powerpc: Enable pkey subsystem ")
> Cc: Ram Pai <linuxram@us.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c130153e453cba0f37ad10fa18a1aa
cheers
^ permalink raw reply
* Re: powerpc/64s: Fix dt_cpu_ftrs to have restore_cpu clear unwanted LPCR bits
From: Michael Ellerman @ 2018-04-05 14:42 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: stable, Nicholas Piggin
In-Reply-To: <20180405055049.21883-1-npiggin@gmail.com>
On Thu, 2018-04-05 at 05:50:49 UTC, Nicholas Piggin wrote:
> Presently the dt_cpu_ftrs restore_cpu will only add bits to the LPCR
> for secondaries, but some bits must be removed (e.g., UPRT for HPT).
> Not clearing these bits on secondaries causes checkstops when booting
> with disable_radix.
>
> restore_cpu can not just set LPCR, because it is also called by the
> idle wakeup code which relies on opal_slw_set_reg to restore the value
> of LPCR, at least on P8 which does not save LPCR to stack in the idle
> code.
>
> Fix this by including a mask of bits to clear from LPCR as well, which
> is used by restore_cpu.
>
> This is a little messy now, but it's a minimal fix that can be
> backported. Longer term, the idle SPR save/restore code can be
> reworked to completely avoid calls to restore_cpu, then restore_cpu
> would be able to unconditionally set LPCR to match boot processor
> environment.
>
> Fixes: 5a61ef74f269f ("powerpc/64s: Support new device tree binding for discovering CPU features")
> Cc: stable@vger.kernel.org # v4.12+
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a57ac411832384eb93df4bfed2bf64
cheers
^ permalink raw reply
* Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU
From: Anshuman Khandual @ 2018-04-05 14:39 UTC (permalink / raw)
To: virtualization, linux-kernel
Cc: robh, aik, jasowang, joe, linuxppc-dev, elfring, david,
Michael S. Tsirkin
In-Reply-To: <20180405105631.9514-1-khandual@linux.vnet.ibm.com>
On 04/05/2018 04:26 PM, Anshuman Khandual wrote:
> There are certian platforms which would like to use SWIOTLB based DMA API
> for bouncing purpose without actually requiring an IOMMU back end. But the
> virtio core does not allow such mechanism. Right now DMA MAP API is only
> selected for devices which have an IOMMU and then the QEMU/host back end
> will process all incoming SG buffer addresses as IOVA instead of simple
> GPA which is the case for simple bounce buffers after being processed with
> SWIOTLB API. To enable this usage, it introduces an architecture specific
> function which will just make virtio core front end select DMA operations
> structure.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ "Michael S. Tsirkin" <mst@redhat.com>
^ permalink raw reply
* [PATCH] powerpc/64: irq_work avoid immediate interrupt when raised with hard irqs enabled
From: Nicholas Piggin @ 2018-04-05 14:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
irq_work_raise should not schedule the hardware decrementer interrupt
unless it is called from NMI context. Doing so often just results in an
immediate masked decrementer interrupt:
<...>-550 90d... 4us : update_curr_rt <-dequeue_task_rt
<...>-550 90d... 5us : dbs_update_util_handler <-update_curr_rt
<...>-550 90d... 6us : arch_irq_work_raise <-irq_work_queue
<...>-550 90d... 7us : soft_nmi_interrupt <-soft_nmi_common
<...>-550 90d... 7us : printk_nmi_enter <-soft_nmi_interrupt
<...>-550 90d.Z. 8us : rcu_nmi_enter <-soft_nmi_interrupt
<...>-550 90d.Z. 9us : rcu_nmi_exit <-soft_nmi_interrupt
<...>-550 90d... 9us : printk_nmi_exit <-soft_nmi_interrupt
<...>-550 90d... 10us : cpuacct_charge <-update_curr_rt
Set the decrementer pending in the irq_happened mask directly, rather
than having the masked decrementer handler do it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/time.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index a32823dcd9a4..9d1cc183c974 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -510,6 +510,35 @@ static inline void clear_irq_work_pending(void)
"i" (offsetof(struct paca_struct, irq_work_pending)));
}
+void arch_irq_work_raise(void)
+{
+ WARN_ON(!irqs_disabled());
+
+ preempt_disable();
+ set_irq_work_pending_flag();
+ /*
+ * Regular iterrupts will check pending irq_happened as they return,
+ * or process context when it next enables interrupts, so the
+ * decrementer can be scheduled there.
+ *
+ * NMI interrupts do not, so setting the decrementer hardware
+ * interrupt to fire ensures the work runs upon RI (if it's to a
+ * MSR[EE]=1 context). We do not want to do this in other contexts
+ * because if interrupts are hard enabled, the decrementer will
+ * fire immediately here and just go to the masked handler to be
+ * recorded in irq_happened.
+ *
+ * BookE does not support this yet, it must audit all NMI
+ * interrupt handlers call nmi_enter().
+ */
+ if (IS_ENABLED(CONFIG_BOOKE) || in_nmi()) {
+ set_dec(1);
+ } else {
+ local_paca->irq_happened |= PACA_IRQ_DEC;
+ }
+ preempt_enable();
+}
+
#else /* 32-bit */
DEFINE_PER_CPU(u8, irq_work_pending);
@@ -518,16 +547,18 @@ DEFINE_PER_CPU(u8, irq_work_pending);
#define test_irq_work_pending() __this_cpu_read(irq_work_pending)
#define clear_irq_work_pending() __this_cpu_write(irq_work_pending, 0)
-#endif /* 32 vs 64 bit */
-
void arch_irq_work_raise(void)
{
+ WARN_ON(!irqs_disabled());
+
preempt_disable();
set_irq_work_pending_flag();
set_dec(1);
preempt_enable();
}
+#endif /* 32 vs 64 bit */
+
#else /* CONFIG_IRQ_WORK */
#define test_irq_work_pending() 0
--
2.16.3
^ permalink raw reply related
* Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()
From: Laurent Dufour @ 2018-04-05 12:53 UTC (permalink / raw)
To: Jerome Glisse
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180404215916.GC3331@redhat.com>
On 04/04/2018 23:59, Jerome Glisse wrote:
> On Wed, Apr 04, 2018 at 06:26:44PM +0200, Laurent Dufour wrote:
>>
>>
>> On 03/04/2018 21:39, Jerome Glisse wrote:
>>> On Tue, Mar 13, 2018 at 06:59:45PM +0100, Laurent Dufour wrote:
>>>> When dealing with the speculative fault path we should use the VMA's field
>>>> cached value stored in the vm_fault structure.
>>>>
>>>> Currently vm_normal_page() is using the pointer to the VMA to fetch the
>>>> vm_flags value. This patch provides a new __vm_normal_page() which is
>>>> receiving the vm_flags flags value as parameter.
>>>>
>>>> Note: The speculative path is turned on for architecture providing support
>>>> for special PTE flag. So only the first block of vm_normal_page is used
>>>> during the speculative path.
>>>
>>> Might be a good idea to explicitly have SPECULATIVE Kconfig option depends
>>> on ARCH_PTE_SPECIAL and a comment for !HAVE_PTE_SPECIAL in the function
>>> explaining that speculative page fault should never reach that point.
>>
>> Unfortunately there is no ARCH_PTE_SPECIAL in the config file, it is defined in
>> the per architecture header files.
>> So I can't do anything in the Kconfig file
>
> Maybe adding a new Kconfig symbol for ARCH_PTE_SPECIAL very much like
> others ARCH_HAS_
>
>>
>> However, I can check that at build time, and doing such a check in
>> __vm_normal_page sounds to be a good place, like that:
>>
>> @@ -869,6 +870,14 @@ struct page *__vm_normal_page(struct vm_area_struct *vma,
>> unsigned long addr,
>>
>> /* !HAVE_PTE_SPECIAL case follows: */
>>
>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> + /* This part should never get called when the speculative page fault
>> + * handler is turned on. This is mainly because we can't rely on
>> + * vm_start.
>> + */
>> +#error CONFIG_SPECULATIVE_PAGE_FAULT requires HAVE_PTE_SPECIAL
>> +#endif
>> +
>> if (unlikely(vma_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
>> if (vma_flags & VM_MIXEDMAP) {
>> if (!pfn_valid(pfn))
>>
>
> I am not a fan of #if/#else/#endif in code. But that's a taste thing.
> I honnestly think that adding a Kconfig for special pte is the cleanest
> solution.
I do agree, but this should be done in a separate series.
I'll see how this could be done but there are some arch (like powerpc) where
this is a bit obfuscated for unknown reason.
For the time being, I'll remove the check and just let the comment in place.
^ permalink raw reply
* [PATCH] powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
From: Michael Ellerman @ 2018-04-05 12:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mauricfo, leitao, linuxram
The recent LPM changes to setup_rfi_flush() are causing some section
mismatch warnings because we removed the __init annotation on
setup_rfi_flush():
The function setup_rfi_flush() references
the function __init ppc64_bolted_size().
the function __init memblock_alloc_base().
The references are actually in init_fallback_flush(), but that is
inlined into setup_rfi_flush().
These references are safe because:
- only pseries calls setup_rfi_flush() at runtime
- pseries always passes L1D_FLUSH_FALLBACK at boot
- so the fallback flush area will always be allocated
- so the check in init_fallback_flush() will always return early:
/* Only allocate the fallback flush area once (at boot time). */
if (l1d_flush_fallback_area)
return;
- and therefore we won't actually call the freed init routines.
We should rework the code to make it safer by default rather than
relying on the above, but for now as a quick-fix just add a __ref
annotation to squash the warning.
Fixes: abf110f3e1ce ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 66f2b6299c40..44c30dd38067 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -880,7 +880,7 @@ void rfi_flush_enable(bool enable)
rfi_flush = enable;
}
-static void init_fallback_flush(void)
+static void __ref init_fallback_flush(void)
{
u64 l1d_size, limit;
int cpu;
--
2.14.1
^ permalink raw reply related
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Oliver @ 2018-04-05 12:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Dan Williams, Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <87bmexua3s.fsf@concordia.ellerman.id.au>
On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Oliver <oohall@gmail.com> writes:
> ...
>>
>> For context Balbir is working with me on some of the pmem stuff. You
>> probably want an Ack from Rob rather than one of us.
>
> I'll ack it if you make all the niggly nit picky trivial annoying
> changes I asked for :D
*groan*
Fine, I'll respin it tomorrow. If anyone else has comments now would
be the time to make them.
>
> cheers
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem
From: Balbir Singh @ 2018-04-05 12:24 UTC (permalink / raw)
To: Oliver
Cc: linuxppc-dev, linux-nvdimm@lists.01.org, Nicholas Piggin,
Michael Ellerman
In-Reply-To: <CAOSf1CFy0im+H368Krr2QVteAumq58CRF_Kfatyv7wvj1n4AGw@mail.gmail.com>
On Thu, Apr 5, 2018 at 9:26 PM, Oliver <oohall@gmail.com> wrote:
> On Thu, Apr 5, 2018 at 5:14 PM, Balbir Singh <bsingharora@gmail.com> wrote:
>> The pmem infrastructure uses memcpy_mcsafe in the pmem
>> layer so as to convert machine check excpetions into
>> a return value on failure in case a machine check
>> exception is encoutered during the memcpy.
>>
>
> Would it be possible to move the bulk of the copyuser code into a
> seperate file which can be #included once the these err macros are
> defined? Anton's memcpy is pretty hairy and I don't think anyone wants
> to have multiple copies of it in the tree, even in a cut down form.
>
I've split it out for now, in the future that might be a good thing to do.
The copy_tofrom_user_power7 falls backs on __copy_tofrom_user_base
to track exactly how much is left over. Adding these changes there would
create a larger churn and need way more testing. I've taken this short-cut
for now with a promise to fix that as the semantics of memcpy_mcsafe()
change to do more accurate tracking of how much was copied over.
Balbir Singh.
^ permalink raw reply
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Michael Ellerman @ 2018-04-05 12:11 UTC (permalink / raw)
To: Oliver, Dan Williams; +Cc: Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <CAOSf1CHu4R-t8q-8fL6Dyk7myFR0gTfd6-0cxqtBVGZgYZWGAw@mail.gmail.com>
Oliver <oohall@gmail.com> writes:
...
>
> For context Balbir is working with me on some of the pmem stuff. You
> probably want an Ack from Rob rather than one of us.
I'll ack it if you make all the niggly nit picky trivial annoying
changes I asked for :D
cheers
^ permalink raw reply
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Oliver @ 2018-04-05 11:34 UTC (permalink / raw)
To: Dan Williams; +Cc: Balbir Singh, Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <CAPcyv4if4un9mgFon4ttjKDYEtHC_GP6VoxUENp7YNS50T3afA@mail.gmail.com>
On Thu, Apr 5, 2018 at 12:21 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Wed, Apr 4, 2018 at 7:04 AM, Oliver <oohall@gmail.com> wrote:
>> On Wed, Apr 4, 2018 at 10:07 PM, Balbir Singh <bsingharora@gmail.com> wrote:
>>> On Tue, 3 Apr 2018 10:37:51 -0700
>>> Dan Williams <dan.j.williams@intel.com> wrote:
>>>
>>>> On Tue, Apr 3, 2018 at 7:24 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>>>> > Add device-tree binding documentation for the nvdimm region driver.
>>>> >
>>>> > Cc: devicetree@vger.kernel.org
>>>> > Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>>>> > ---
>>>> > v2: Changed name from nvdimm-region to pmem-region.
>>>> > Cleaned up the example binding and fixed the overlapping regions.
>>>> > Added support for multiple regions in a single reg.
>>>> > ---
>>>> > .../devicetree/bindings/pmem/pmem-region.txt | 80 ++++++++++++++++++++++
>>>> > MAINTAINERS | 1 +
>>>> > 2 files changed, 81 insertions(+)
>>>> > create mode 100644 Documentation/devicetree/bindings/pmem/pmem-region.txt
>>>>
>>>> Device-tree folks, does this look, ok?
>>>>
>>>> Oliver, is there any concept of a management interface to the
>>>> device(s) backing these regions? libnvdimm calls these "nmem" devices
>>>> and support operations like health status and namespace label
>>>> management.
>>
>> It's something I'm planning on implementing as soon as someone gives
>> me some hardware that isn't hacked up lab crap. I'm posting this
>> version with just regions since people have been asking for something
>> in upstream even if it's not fully featured.
>>
>> Grumbling aside, the plan is to have separate drivers for the DIMM
>> type. Discovering DIMM devices happens via the normal discovery
>> mechanisms (e.g. an NVDIMM supporting the JEDEC interface is an I2C
>> device) and when binding to a specific DIMM device it registers a DIMM
>> descriptor structure and a ndctl implementation for that DIMM type
>> with of_pmem. When of_pmem binds to a region it can plug everything
>> into the region specific bus. There's a few details to work out, but I
>> think it's a reasonable approach.
>
> Yeah, that sounds reasonable. It would mean that your management
> interface would need to understand that nmems on different buses could
> potentially move to another bus after a reconfiguration, but that's
> not too much different than the ACPI case where nmems can join and
> leave regions after a reset / reconfig.
>
>>> We would need a way to have nmem and pmem-regions find each other. Since we
>>> don't have the ACPI abstractions, the nmem region would need to add the
>>> ability for a driver to have a phandle to the interleaving and nmem properties.
>>>
>>> I guess that would be a separate driver, that would manage the nmem devices
>>> and there would be a way to relate the pmem and nmems. Oliver?
>>
>> Yes, that's the plan.
>
> So Balbir, is that enough for an Acked-by for this device-tree proposal?
For context Balbir is working with me on some of the pmem stuff. You
probably want an Ack from Rob rather than one of us.
^ permalink raw reply
* Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU
From: Anshuman Khandual @ 2018-04-05 11:28 UTC (permalink / raw)
To: Balbir Singh
Cc: robh, linux-kernel@vger.kernel.org, virtualization, Joe Perches,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Markus Elfring,
David Gibson
In-Reply-To: <CAKTCnz=3b56bGKrqCcZOwBsu0yngS_Rw-9TieNLyHgix4eZrAQ@mail.gmail.com>
On 04/05/2018 04:44 PM, Balbir Singh wrote:
> On Thu, Apr 5, 2018 at 8:56 PM, Anshuman Khandual
> <khandual@linux.vnet.ibm.com> wrote:
>> There are certian platforms which would like to use SWIOTLB based DMA API
>> for bouncing purpose without actually requiring an IOMMU back end. But the
>> virtio core does not allow such mechanism. Right now DMA MAP API is only
>> selected for devices which have an IOMMU and then the QEMU/host back end
>> will process all incoming SG buffer addresses as IOVA instead of simple
>> GPA which is the case for simple bounce buffers after being processed with
>> SWIOTLB API. To enable this usage, it introduces an architecture specific
>> function which will just make virtio core front end select DMA operations
>> structure.
>>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> ---
>> This RFC is just to get some feedback. Please ignore the function call
>> back into the architecture. It can be worked out properly later on. But
>> the question is can we have virtio devices in the guest which would like
>> to use SWIOTLB based (or any custom DMA API based) bounce buffering with
>> out actually being an IOMMU devices emulated by QEMU/host as been with
>> the current VIRTIO_F_IOMMU_PLATFORM virtio flag ?
>>
>> arch/powerpc/platforms/pseries/iommu.c | 6 ++++++
>> drivers/virtio/virtio_ring.c | 4 ++++
>> include/linux/virtio.h | 2 ++
>> 3 files changed, 12 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
>> index 06f02960b439..dd15fbddbe89 100644
>> --- a/arch/powerpc/platforms/pseries/iommu.c
>> +++ b/arch/powerpc/platforms/pseries/iommu.c
>> @@ -1396,3 +1396,9 @@ static int __init disable_multitce(char *str)
>> __setup("multitce=", disable_multitce);
>>
>> machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init);
>> +
>> +bool is_virtio_dma_platform(void)
>> +{
>> + return true;
>> +}
>> +EXPORT_SYMBOL(is_virtio_dma_platform);
>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>> index 71458f493cf8..9f205a79d378 100644
>> --- a/drivers/virtio/virtio_ring.c
>> +++ b/drivers/virtio/virtio_ring.c
>> @@ -144,6 +144,10 @@ struct vring_virtqueue {
>>
>> static bool vring_use_dma_api(struct virtio_device *vdev)
>> {
>> + /* Use DMA API even for virtio devices without an IOMMU */
>> + if (is_virtio_dma_platform())
>> + return true;
>> +
>> if (!virtio_has_iommu_quirk(vdev))
>> return true;
>>
>> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
>> index 988c7355bc22..d8bb83d753ea 100644
>> --- a/include/linux/virtio.h
>> +++ b/include/linux/virtio.h
>> @@ -200,6 +200,8 @@ static inline struct virtio_driver *drv_to_virtio(struct device_driver *drv)
>> int register_virtio_driver(struct virtio_driver *drv);
>> void unregister_virtio_driver(struct virtio_driver *drv);
>>
>> +extern bool is_virtio_dma_platform(void);
>> +
>
> Where is the default implementation for non-pseries platforms? Will they compile
> after these changes?
No they wont. This is just a RFC asking for suggestion/feedback on a
particular direction, will clean up the code later on once we agree
on this.
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem
From: Oliver @ 2018-04-05 11:26 UTC (permalink / raw)
To: Balbir Singh
Cc: linuxppc-dev, linux-nvdimm@lists.01.org, Nicholas Piggin,
Michael Ellerman
In-Reply-To: <20180405071500.22320-3-bsingharora@gmail.com>
On Thu, Apr 5, 2018 at 5:14 PM, Balbir Singh <bsingharora@gmail.com> wrote:
> The pmem infrastructure uses memcpy_mcsafe in the pmem
> layer so as to convert machine check excpetions into
> a return value on failure in case a machine check
> exception is encoutered during the memcpy.
>
> 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>
> Acked-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/string.h | 2 +
> arch/powerpc/lib/Makefile | 2 +-
> arch/powerpc/lib/memcpy_mcsafe_64.S | 212 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 215 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 9b8cedf618f4..b7e872a64726 100644
> --- a/arch/powerpc/include/asm/string.h
> +++ b/arch/powerpc/include/asm/string.h
> @@ -30,7 +30,9 @@ extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
> #ifdef CONFIG_PPC64
> #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 3c29c9009bbf..048afee9f518 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -24,7 +24,7 @@ endif
>
> obj64-y += copypage_64.o copyuser_64.o mem_64.o hweight_64.o \
> copyuser_power7.o string_64.o copypage_power7.o memcpy_power7.o \
> - memcpy_64.o memcmp_64.o pmem.o
> + memcpy_64.o memcmp_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..e7eaa9b6cded
> --- /dev/null
> +++ b/arch/powerpc/lib/memcpy_mcsafe_64.S
> @@ -0,0 +1,212 @@
> +/* 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>
> +
> + .macro err1
> +100:
> + EX_TABLE(100b,.Ldo_err1)
> + .endm
> +
> + .macro err2
> +200:
> + EX_TABLE(200b,.Ldo_err2)
> + .endm
Would it be possible to move the bulk of the copyuser code into a
seperate file which can be #included once the these err macros are
defined? Anton's memcpy is pretty hairy and I don't think anyone wants
to have multiple copies of it in the tree, even in a cut down form.
> +
> +.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:
> + li r3,-EFAULT
> + blr
> +
> +
> +_GLOBAL(memcpy_mcsafe)
> + 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
> +
> +1: bf cr7*4+2,2f
> +err1; lhz r0,0(r4)
> + addi r4,r4,2
> +err1; sth r0,0(r3)
> + addi r3,r3,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
> +
> +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 r7,16(r4)
> +err2; ld r8,24(r4)
> +err2; ld r9,32(r4)
> +err2; ld r10,40(r4)
> +err2; ld r11,48(r4)
> +err2; ld r12,56(r4)
> +err2; ld r14,64(r4)
> +err2; ld r15,72(r4)
> +err2; ld r16,80(r4)
> +err2; ld r17,88(r4)
> +err2; ld r18,96(r4)
> +err2; ld r19,104(r4)
> +err2; ld r20,112(r4)
> +err2; ld r21,120(r4)
> + addi r4,r4,128
> +err2; std r0,0(r3)
> +err2; std r6,8(r3)
> +err2; std r7,16(r3)
> +err2; std r8,24(r3)
> +err2; std r9,32(r3)
> +err2; std r10,40(r3)
> +err2; std r11,48(r3)
> +err2; std r12,56(r3)
> +err2; std r14,64(r3)
> +err2; std r15,72(r3)
> +err2; std r16,80(r3)
> +err2; std r17,88(r3)
> +err2; std r18,96(r3)
> +err2; std r19,104(r3)
> +err2; std r20,112(r3)
> +err2; std r21,120(r3)
> + addi r3,r3,128
> + bdnz 4b
> +
> + clrldi r5,r5,(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 127B to go */
> +5: srdi r6,r5,4
> + mtocrf 0x01,r6
> +
> +6: bf cr7*4+1,7f
> +err1; ld r0,0(r4)
> +err1; ld r6,8(r4)
> +err1; ld r7,16(r4)
> +err1; ld r8,24(r4)
> +err1; ld r9,32(r4)
> +err1; ld r10,40(r4)
> +err1; ld r11,48(r4)
> +err1; ld r12,56(r4)
> + addi r4,r4,64
> +err1; std r0,0(r3)
> +err1; std r6,8(r3)
> +err1; std r7,16(r3)
> +err1; std r8,24(r3)
> +err1; std r9,32(r3)
> +err1; std r10,40(r3)
> +err1; std r11,48(r3)
> +err1; std r12,56(r3)
> + addi r3,r3,64
> +
> + /* Up to 63B to go */
> +7: bf cr7*4+2,8f
> +err1; ld r0,0(r4)
> +err1; ld r6,8(r4)
> +err1; ld r7,16(r4)
> +err1; ld r8,24(r4)
> + addi r4,r4,32
> +err1; std r0,0(r3)
> +err1; std r6,8(r3)
> +err1; std r7,16(r3)
> +err1; std r8,24(r3)
> + addi r3,r3,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
> +
> +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
> +
> +12: bf cr7*4+1,13f
> +err1; lwz r0,0(r4)
> + addi r4,r4,4
> +err1; stw r0,0(r3)
> + addi r3,r3,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
> +
> +14: bf cr7*4+3,15f
> +err1; lbz r0,0(r4)
> +err1; stb r0,0(r3)
> +
> +15: li r3,0
> + blr
> --
> 2.13.6
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox