This is v5 of the patches posted at:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=37250
This series has been tested using mambo for p8 (hash) and p9 (radix),
and also on Power8 host.
In v5, the patch for KVM has been re-worked and is now [6/10], instead
of [2/10]. This now wor
Re-arrange the last #ifdef section in preparation for a subsequent
change.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/ftrace.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index 9
Add some helpers to enable/disable ftrace through paca->ftrace_enabled.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/ftrace.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index ebfc0b846
On the boot cpu, though we enable paca->ftrace_enabled in early_setup()
(via cpu_ready_for_interrupts()), we don't start tracing until much
later since ftrace is not initialized yet and since we only support
DYNAMIC_FTRACE on powerpc. However, it is possible that ftrace has been
initialized by the
We have some C code that we call into from real mode where we cannot
take any exceptions. Though the C functions themselves are mostly safe,
if these functions are traced, there is a possibility that we may take
an exception. For instance, in certain conditions, the ftrace code uses
WARN(), which u
During guest entry/exit, we switch over to/from the guest MMU context
and we cannot take exceptions in the hypervisor code.
Since ftrace may be enabled and since it can result in us taking a trap,
disable ftrace by setting paca->ftrace_enabled to zero. There are two
paths through which we enter/ex
If function_graph tracer is enabled during kexec, we see the below
exception in the simulator:
root@(none):/# kexec -e
kvm: exiting hardware virtualization
kexec_core: Starting new kernel
[ 19.262020070,5] OPAL: Switch to big-endian OS
kexec: Starting switc
For R_PPC64_REL24 relocations, we suppress emitting instructions for TOC
load/restore in the relocation stub if the relocation is for _mcount()
call when using -mprofile-kernel ABI.
To detect this, we check if the preceding instructions are per the
standard set of instructions emitted by gcc: eith
With -mprofile-kernel, we always save the full register state in
ftrace_caller(). While this works, this is inefficient if we're not
interested in the register state, such as when we're using the function
tracer.
Rename the existing ftrace_caller() as ftrace_regs_caller() and provide
a simpler imp
Our implementation matches that of the generic version, which also
handles FTRACE_UPDATE_MODIFY_CALL. So, remove our implementation in
favor of the generic version.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/trace/ftrace.c | 36 --
1 file changed, 36 deletio
Disable ftrace when a cpu is about to go offline. When the cpu is woken
up, ftrace will get enabled in start_secondary().
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/smp.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
i
On Wed, Apr 18, 2018 at 09:22:09AM -0500, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote:
[...]
> >> My intention is to leave 0 instances of clear_siginfo in the
> >> architecture specific code. Ideally struct siginfo will
On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote:
[...]
> The other thing we should do is to get rid of the stupid padding.
> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
> completely insane, when it's always just zero in the kernel.
Agreed, inside the ker
When running KVM guests on Power8 we can see a lockup where one CPU
stops responding. This often leads to a message such as:
watchdog: CPU 136 detected hard LOCKUP on other CPUs 72
Task dump for CPU 72:
qemu-system-ppc R running task10560 20917 20908 0x00040004
And then backtraces on
On Wed, 2018-04-11 at 03:37:58 UTC, Michael Neuling wrote:
> On boot we save the configuration space of PCIe bridges. We do this so
> when we get an EEH event and everything gets reset that we can restore
> them.
>
> Unfortunately we save this state before we've enabled the MMIO space
> on the bri
On Wed, 2018-04-11 at 05:17:59 UTC, Benjamin Herrenschmidt wrote:
> When setting up a CPU, we "push" (activate) a pool VP for it.
>
> However it's an error to do so if it already has an active
> pool VP.
>
> This happens when doing soft CPU hotplug on powernv since we
> don't tear down the CPU on
On Thu, 2018-04-19 at 13:29:50 UTC, Michael Ellerman wrote:
> When running KVM guests on Power8 we can see a lockup where one CPU
> stops responding. This often leads to a message such as:
>
> watchdog: CPU 136 detected hard LOCKUP on other CPUs 72
> Task dump for CPU 72:
> qemu-system-ppc R
The s390 msgbuf/sembuf/shmbuf header files are all identical to the
version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements, to avoid having to modify each copy when we extend sysvipc
to deal with 64-bit time_t in 32-bit user space.
Note that unlike al
The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 changes. While ia64 no longer has
a compat mode and doesn't need the file any more, it seem nicer
to
parisc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, parisc actually succeeded in
defining this right for big-endian CPUs, but as ev
The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended
to contain extra fields for storing the upper bits of the time stamps,
this patch does the other half of the job and and fills the new fields on
32-bit architectures as well as 32-bit tasks running on a 64-bit kernel
in compat
Both 32-bit amd 64-bit ARM use the asm-generic header files for their
sysvipc data structures, so no special care is needed to make those
work beyond y2038, with the one exception of compat mode: Since there
is no asm-generic definition of the compat mode IPC structures, ARM64
provides its own copy
The architectures that support 32-bit compat mode define a number
of simple types for use in compat handlers. About half of those
are identical between architectures, and some of those are also
required now by handlers shared with CONFIG_COMPAT_32BIT_TIME
functions on 32-bit architectures.
Let's m
MIPS is the weirdest case for sysvipc, because each of the
three data structures is done differently:
* msqid64_ds has padding in the right place so we could in theory
extend this one to just have 64-bit values instead of time_t.
As this does not work for most of the other combinations,
we j
The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 series. Since there is no 32-bit
syscall support for alpha, we don't need the other changes, but
it'
This extends the x86 copy of the sysvipc data structures to deal with
32-bit user space that has 64-bit time_t and wants to see timestamps
beyond 2038.
Fortunately, x86 has padding for this purpose in all the data structures,
so we can just add extra fields. With msgid64_ds and shmid64_ds, the
dat
powerpc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
powerpc has the same definition as parisc and sparc, but now also
supports little-endian mode, which is n
This is a preparatation for changing over __kernel_timespec to 64-bit
times, which involves assigning new system call numbers for mq_timedsend(),
mq_timedreceive() and semtimedop() for compatibility with future y2038
proof user space.
The existing ABIs will remain available through compat code.
S
Dave Martin writes:
> On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote:
>
> [...]
>
>> The other thing we should do is to get rid of the stupid padding.
>> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
>> completely insane, when it's always just zero in the
This is an update of a series I posted a long time ago [1], updating
the IPC subsystem to pass down 64-bit time stamps to user space.
In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not
introduce a completely new set of replacement system calls, but instead
extend the existing ones
In some places, we still used get_seconds() instead of
ktime_get_real_seconds(), and I'm changing the remaining ones now to
all use ktime_get_real_seconds() so we use the full available range for
timestamps instead of overflowing the 'unsigned long' return value in
year 2106 on 32-bit kernels.
Sig
xtensa, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
xtensa tries hard to define the structures so they work
in both big-endian and little-endian systems with
32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME
need to have the traditional semtimedop() behavior with 32-bit timestamps
for sys_ipc() by calling compat_ksys_semtimedop(), while those that
are not yet converted need to keep using ksys_semtimedop() like
64-bit architectures do.
sparc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, sparc actually succeeded in
defining this right for big-endian CPUs, but as ever
Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop)
take a timespec argument. After we move 32-bit architectures over to
useing 64-bit time_t based syscalls, we need seperate entry points for
the old 32-bit based interfaces.
This changes the #ifdef guards for the existing 32-bit
Most architectures now use the asm-generic copy of the sysvipc data
structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
__kernel_time_t on 32-bit architectures but have padding behind them to
allow extending the type to 64-bit.
Unfortunately, that fails on all big-endian architecture
Arnd Bergmann writes:
> Most architectures now use the asm-generic copy of the sysvipc data
> structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
> __kernel_time_t on 32-bit architectures but have padding behind them to
> allow extending the type to 64-bit.
>
> Unfortunately, that f
On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
wrote:
> Arnd Bergmann writes:
>>
>> struct msqid64_ds {
>> struct ipc64_perm msg_perm;
>> +#if __BITS_PER_LONG == 64
>> __kernel_time_t msg_stime; /* last msgsnd time */
>> -#if __BITS_PER_LONG != 64
>> - unsigned long __
On Thu, 19 Apr 2018 00:49:58 +0530
Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> co
On Thu, 19 Apr 2018 12:33:59 +0530
"Naveen N. Rao" wrote:
> This is v5 of the patches posted at:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=37250
>
> This series has been tested using mambo for p8 (hash) and p9 (radix),
> and also on Power8 host.
>
> In v5, the patch for
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ s
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/at_hdmac.c | 9 +++--
drivers/dma/at_xdmac.c | 9 +++--
driv
On Thu, 19 Apr 2018 12:34:05 +0530
"Naveen N. Rao" wrote:
> 2. If we are a secondary thread in Power8, then we would be in nap due
> to SMT being disabled. We are woken up by an IPI to enter the guest. In
> this scenario, we enter the guest through kvm_start_guest(). We disable
> ftrace at this p
On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote:
> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
> wrote:
>> I suspect you want to use __kernel_ulong_t here instead of a raw
>> unsigned long. If nothing else it seems inconsistent to use typedefs
>> in one half of the structure and no
Arnd Bergmann writes:
> On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote:
>> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
>> wrote:
>>> I suspect you want to use __kernel_ulong_t here instead of a raw
>>> unsigned long. If nothing else it seems inconsistent to use typedefs
>>> in on
Using an si_code of 0 that aliases with SI_USER is clearly the wrong
thing todo, and causes problems in interesting ways.
For use in unknown_exception the recently defined TRAP_UNK
semantically is a perfect fit. For use in RunModeException it looks
like something more specific than TRAP_UNK could
Using an si_code of 0 that aliases with SI_USER is clearly the
wrong thing todo, and causes problems in interesting ways.
The newly defined FPE_FLTUNK semantically appears to fit the
bill so use it instead.
Cc: Paul Mackerras
Cc: Kumar Gala
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc:
Both powerpc and alpha have cases where they wronly set si_code to 0
in combination with SIGTRAP and don't mean SI_USER.
About half the time this is because the architecture can not report
accurately what kind of trap exception triggered the trap exception.
The other half the time it looks like no
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Wednesday, 11 April 2018 4:38:54 PM AEST Alistair Popple wrote:
> The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are
> used to allocate/free cont
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Wednesday, 11 April 2018 4:38:55 PM AEST Alistair Popple wrote:
> There is a single npu context per set of callback parameters. Callers
> should be prevented from over
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Tuesday, 17 April 2018 7:11:28 PM AEST Alistair Popple wrote:
> The NPU has a limited number of address translation shootdown (ATSD)
> registers and the GPU has limite
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. This reserved
memory is used for saving the contents of old crashed kernel's memory before
fadump capture kernel uses old kernel's memory area to boot. However, This
res
From: Mahesh Salgaonkar
Currently the metadata region that holds crash info structure and ELF core
header is placed towards the end of reserved memory area. This patch places
it at the beginning of the reserved memory area. It also introduces
additional dump section called metadata section to com
From: Mahesh Salgaonkar
Metadata region that holds fadump header and ELF header is now placed at
the start of reserved memory area. Update the documentation accordingly
Signed-off-by: Mahesh Salgaonkar
---
Documentation/powerpc/firmware-assisted-dump.txt | 33 ++
1 file c
From: Mahesh Salgaonkar
otherwise the fadump registration in new kexec-ed kernel complains that
fadump is already registered. This makes new kernel to continue using
fadump registered by previous kernel which may lead to invalid vmcore
generation. Hence this patch fixes this issue by un-registeri
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is in
From: Mahesh Salgaonkar
fadump fails to register when there are holes in reserved memory area.
This can happen if user has hot-removed a memory that falls in the fadump
reserved memory area. Throw a meaningful error message to the user in
such case.
Signed-off-by: Mahesh Salgaonkar
---
arch/po
From: Mahesh Salgaonkar
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. But this memory area is currently not
protected from hot-remove operations. Hence, fadump ser
From: Mahesh Salgaonkar
Signed-off-by: Mahesh Salgaonkar
---
Documentation/powerpc/firmware-assisted-dump.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt
b/Documentation/powerpc/firmware-assisted-dump.txt
inde
Steven Rostedt wrote:
On Thu, 19 Apr 2018 12:34:05 +0530
"Naveen N. Rao" wrote:
2. If we are a secondary thread in Power8, then we would be in nap due
to SMT being disabled. We are woken up by an IPI to enter the guest. In
this scenario, we enter the guest through kvm_start_guest(). We disable
60 matches
Mail list logo
