On Sat, 9 May 2020 at 07:52, Nicholas Piggin wrote:
>
> Excerpts from Paul Mackerras's message of May 9, 2020 3:02 pm:
> > This fixes the compile errors we currently get with CONFIG_SMP=n and
> > CONFIG_PPC_RADIX_MMU=y.
>
> Did I already fix this, or does it keep getting broken?! :(
>
> Anyway fin
On Thu, May 14, 2020 at 3:31 PM Christophe Leroy
wrote:
>
>
>
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > A future revision of the ISA will introduce prefixed instructions. A
> > prefixed instruction is composed of a 4-byte prefix followed by a
> > 4-byte suffix.
> >
> > All prefixes have
So far, powerpc Book3S code has been written with an assumption of
only one watchpoint. But Power10[1] is introducing second watchpoint
register (DAWR). Even though this patchset does not enable 2nd DAWR,
it makes the infrastructure ready so that enabling 2nd DAWR should
just be a matter of changin
Power10 is introducing second DAWR. Use real register names from ISA
for current macros:
s/SPRN_DAWR/SPRN_DAWR0/
s/SPRN_DAWRX/SPRN_DAWRX0/
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h | 4 ++--
arch/powerpc/kernel/dawr.c
Power10 is introducing second DAWR. Add SPRN_ macros for the same.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 60a21b6b205
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But Power10 is introducing 2nd DAWR and thus kernel should be able to
dynamically find actual number of watchpoints supported by hw it's
running on. Introduce function for the same. Also convert HBP_NUM macro
to HBP_NUM_MAX, whic
User can ask for num of available watchpoints(dbginfo.num_data_bps)
using ptrace(PPC_PTRACE_GETHWDBGINFO). Return actual number of
available watchpoints on the machine rather than hardcoded 1.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/kernel/ptrace/ptrace-noadv.
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR
should be programed.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 4 ++--
arch/powerpc/kernel/dawr.c | 15 ++-
arch/powerpc/kernel/process
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/debug.h | 2 +-
arch/powerpc/include/asm/hw_breakpoin
Instead of disabling only one watchpoint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --g
Instead of disabling only first watchpoint, disable all available
watchpoints while clearing dawr_force_enable.
Callback function is used only for disabling watchpoint, rename it
to disable_dawrs_cb(). And null_brk parameter is not really required
while disabling watchpoint, remove it.
Signed-off
So far powerpc hw supported only one watchpoint. But Power10 is
introducing 2nd DAWR. Convert thread_struct->hw_brk into an array.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/kernel/process.c | 60
ptrace_bps is already an array of size HBP_NUM_MAX. But we use
hardcoded index 0 while fetching/updating it. Convert such code
to loop over array.
ptrace interface to use multiple watchpoint remains same. eg:
two PPC_PTRACE_SETHWDEBUG calls will create two watchpoint if
underneath hw supports it.
Introduce is_ptrace_bp() function and move the check inside the
function. It will be utilize more in later set of patches.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/kernel/hw_breakpoint.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/
Currently we calculate hw aligned start and end addresses manually.
Replace them with builtin ALIGN_DOWN() and ALIGN() macros.
So far end_addr was inclusive but this patch makes it exclusive (by
avoiding -1) for better readability.
Suggested-by: Christophe Leroy
Signed-off-by: Ravi Bangoria
Rev
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make supporting more watchpoints very easy.
With more than one watchpoint, exception handler needs to know which
DAWR caused the exception, and hw currently do
With Book3s DAWR, ptrace and perf watchpoints on powerpc behaves
differently. Ptrace watchpoint works in one-shot mode and generates
signal before executing instruction. It's ptrace user's job to
single-step the instruction and re-enable the watchpoint. OTOH, in
case of perf watchpoint, kernel emul
Xmon allows overwriting breakpoints because it's supported by only
one DAWR. But with multiple DAWRs, overwriting becomes ambiguous
or unnecessary complicated. So let's not allow it.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 4
1 file changed,
Add support for 2nd DAWR in xmon. With this, we can have two
simultaneous breakpoints from xmon.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 101 ++-
1 file changed, 69 insertions(+), 32 deletions(-)
diff --git a/
On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:
> @@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct
> optimized_kprobe *op, struct kprobe *p)
> > * Fixup the template with instructions to:
> > * 1. load the address of the actual probepoint
> > */
> > - patch_imm64_
On Thursday, 14 May 2020 4:14:12 PM AEST Christophe Leroy wrote:
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > If a prefixed instruction results in an alignment exception, the
> > SRR1_PREFIXED bit is set. The handler attempts to emulate the
> > responsible instruction and then increment the
On Thursday, 14 May 2020 4:15:06 PM AEST Christophe Leroy wrote:
> Shouldn't this patch go before patch 23 ?
Perhaps I am missing something, but it seems reasonable enough to me that you
would introduce the machinery for dealing with prefix instructions prior to
defining them. What would be the
On Thu, May 14, 2020 at 4:12 PM Christophe Leroy
wrote:
>
>
>
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > For powerpc64, redefine the ppc_inst type so both word and prefixed
> > instructions can be represented. On powerpc32 the type will remain the
> > same. Update places which had assum
On Thu, May 14, 2020 at 10:06 PM Alistair Popple wrote:
>
> On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:
> > @@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct
> > optimized_kprobe *op, struct kprobe *p)
> > > * Fixup the template with instructions to:
> > > * 1. load
Le 14/05/2020 à 14:06, Alistair Popple a écrit :
On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:
@@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct
optimized_kprobe *op, struct kprobe *p)
* Fixup the template with instructions to:
* 1. load the address of the actua
Le 14/05/2020 à 14:15, Alistair Popple a écrit :
On Thursday, 14 May 2020 4:14:12 PM AEST Christophe Leroy wrote:
Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
If a prefixed instruction results in an alignment exception, the
SRR1_PREFIXED bit is set. The handler attempts to emulate the
resp
Le 14/05/2020 à 14:19, Alistair Popple a écrit :
On Thursday, 14 May 2020 4:15:06 PM AEST Christophe Leroy wrote:
Shouldn't this patch go before patch 23 ?
Perhaps I am missing something, but it seems reasonable enough to me that you
would introduce the machinery for dealing with prefix ins
On 2020-05-12 00:28, Sam Bobroff wrote:
On Thu, May 07, 2020 at 08:10:37AM -0500, wenxi...@linux.vnet.ibm.com
wrote:
From: Wen Xiong
Several device drivers hit EEH(Extended Error handling) when
triggering
kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
in pci general cod
From: Mike Rapoport
Hi,
The low level page table accessors (pXY_index(), pXY_offset()) are
duplicated across all architectures and sometimes more than once. For
instance, we have 31 definition of pgd_offset() for 25 supported
architectures.
Most of these definitions are actually identical and t
From: Mike Rapoport
The linux/mm.h header includes to allow inlining of the
functions involving page table manipulations, e.g. pte_alloc() and
pmd_alloc(). So, there is no point to explicitly include in
the files that include .
The include statements in such cases are remove with a simple loop
From: Mike Rapoport
The replacement of with made the include
of the latter in the middle of asm includes. Fix this up with the aid of
the below script and manual adjustments here and there.
import sys
import re
if len(sys.argv) is not 3:
print "USAGE: %s "
From: Mike Rapoport
All architectures use pXd_index() to get an entry in the page table page
corresponding to a virtual address.
Align csky with other architectures.
Signed-off-by: Mike Rapoport
---
arch/csky/include/asm/pgtable.h | 5 ++---
arch/csky/mm/fault.c| 2 +-
arch/csky/m
From: Mike Rapoport
The comment about page table allocation functions resides in
include/asm/motorola_pgtable.h while the functions live in
include/asm/motorola_pgaloc.h.
Move the comment close to the code.
Signed-off-by: Mike Rapoport
---
arch/m68k/include/asm/motorola_pgalloc.h | 6 ++
From: Mike Rapoport
The cache_page() and nocache_page() functions are only used by the motorola
MMU variant for setting caching attributes for the page table pages.
Move the definitions of these functions from
arch/m68k/include/asm/motorola_pgtable.h closer to their usage in
arch/m68k/mm/motorol
From: Mike Rapoport
There are three cases for the trampoline initialization:
* 32-bit does nothing
* 64-bit with kaslr disabled simply copies a PGD entry from the direct map
to the trampoline PGD
* 64-bit with kaslr enabled maps the real mode trampoline at PUD level
These cases are currently d
From: Mike Rapoport
The powerpc 32-bit implementation of pgtable has nice shortcuts for
accessing kernel PMD and PTE for a given virtual address.
Make this helpers available for all architectures.
Signed-off-by: Mike Rapoport
---
arch/arc/mm/highmem.c | 10 +---
arch/arm/ma
From: Mike Rapoport
All architectures define pte_index() as
(address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)
and all architectures define pte_offset_kernel() as an entry
in the array of PTEs indexed by the pte_index().
For the most architectures the pte_offset_kernel() implementation relie
From: Mike Rapoport
All architectures define pmd_index() as
(address >> PMD_SHIFT) & (PTRS_PER_PMD - 1)
and all architectures that have at least three-level page tables define
pmd_offset() as an entry in the array of PMDs indexed by the pmd_index().
For the most architectures the pmd_o
From: Mike Rapoport
All architectures that have at least four-level page tables define
pud_offset() as an entry in the array of PUDs indexed by the pud_index(),
where pud_index() is
(address >> PUD_SHIFT) & (PTRS_PER_PUD - 1)
For the most architectures the pud_offset() implementation re
From: Mike Rapoport
All architectures tables define pgd_offset() as an entry in the array of
PGDs indexed by the pgd_index(), where pgd_index() is
(address >> PGD_SHIFT) & (PTRS_PER_PGD - 1)
For the most cases, the pgd_offset() uses mm->pgd as the pointer to the
top-level page directory
On 14/05/20 19:35, Jonathan Adams wrote:
>> In general for statsfs we took a more explicit approach where each
>> addend in a sum is a separate stats_fs_source. In this version of the
>> patches it's also a directory, but we'll take your feedback and add both
>> the ability to hide directories (fi
From: Tyrel Datwyler
[ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ]
While removing an ibmvscsi client adapter a WARN_ON like the following is
seen in the kernel log:
drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1
WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping
From: Juliet Kim
[ Upstream commit f9c6cea0b38518741c8dcf26ac056d26ee2fd61d ]
During MTU change, the following events may happen.
Client-driven CRQ initialization fails due to partner’s CRQ closed,
causing client to enqueue a reset task for FATAL_ERROR. Then passive
(server-driven) CRQ initializ
From: Tyrel Datwyler
[ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ]
While removing an ibmvscsi client adapter a WARN_ON like the following is
seen in the kernel log:
drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1
WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping
From: Juliet Kim
[ Upstream commit f9c6cea0b38518741c8dcf26ac056d26ee2fd61d ]
During MTU change, the following events may happen.
Client-driven CRQ initialization fails due to partner’s CRQ closed,
causing client to enqueue a reset task for FATAL_ERROR. Then passive
(server-driven) CRQ initializ
From: Tyrel Datwyler
[ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ]
While removing an ibmvscsi client adapter a WARN_ON like the following is
seen in the kernel log:
drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1
WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping
From: Tyrel Datwyler
[ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ]
While removing an ibmvscsi client adapter a WARN_ON like the following is
seen in the kernel log:
drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1
WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping
Hi,
Leonardo Bras writes:
> +/**
> + * rtas_call_reentrant() - Used for reentrant rtas calls
> + * @token: Token for desired reentrant RTAS call
> + * @nargs: Number of Input Parameters
> + * @nret:Number of Output Parameters
> + * @outputs: Array of outputs
> + * @...: Inputs for des
Hi Leonardo,
Leonardo Bras writes:
> Hello Nathan, thanks for the feedback!
>
> On Fri, 2020-04-10 at 14:28 -0500, Nathan Lynch wrote:
>> Leonardo Bras writes:
>> > Implement rtas_call_reentrant() for reentrant rtas-calls:
>> > "ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
>> >
On Thu, 2020-05-14 at 14:04 -0500, Nathan Lynch wrote:
> I checked with partition firmware development and these calls can be
> used concurrently with arbitrary other RTAS calls, which confirms your
> interpretation. Thanks for bearing with me.
I was not aware of how I could get this information.
On 2020-05-13 00:04, Greg KH wrote:
On Tue, May 12, 2020 at 02:39:50PM -0700, rana...@codeaurora.org wrote:
On 2020-05-12 01:25, Greg KH wrote:
> On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
> > On 11. 05. 20, 9:39, Greg KH wrote:
> > > On Mon, May 11, 2020 at 12:23:58AM -0700, ra
Hello Nathan,
On Thu, 2020-05-14 at 13:58 -0500, Nathan Lynch wrote:
> Hi,
>
> Leonardo Bras writes:
> > +/**
> > + * rtas_call_reentrant() - Used for reentrant rtas calls
> > + * @token: Token for desired reentrant RTAS call
> > + * @nargs: Number of Input Parameters
> > + * @nret: Number of O
Patch 2 implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive",
according to LoPAPR Version 1.1 (March 24, 2016).
For that, it's necessary that every call uses a different
rtas buffer (rtas_args). Paul Mackerras suggested using the P
In order to get any rtas* struct into other headers, including rtas.h
may cause a lot of errors, regarding include dependency needed for
inline functions.
Create rtas-types.h and move there all type/struct definitions
from rtas.h, then include rtas-types.h into rtas.h.
Also, as suggested by check
Implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
items 2 and 3 say:
2 - For the PowerPC External Interrupt option: The * call must be
reentrant to the number
On Thu, 2020-05-14 at 20:28 -0300, Leonardo Bras wrote:
> Yes, you are right.
> I will also add preempt_{dis,en}able, which in most kernels will
> compile out, but it will be kind of 'ready' if we ever decide to
> support PREEMPT.
>
> Thanks for the feedback!
v4:
http://patchwork.ozlabs.org/proje
Christophe Leroy writes:
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
>> For powerpc64, redefine the ppc_inst type so both word and prefixed
>> instructions can be represented. On powerpc32 the type will remain the
>> same. Update places which had assumed instructions to be 4 bytes long.
...
Hi Geoff,
Geoff Levand writes:
> The ps3's otheros flash loader has a size limit of 16 MiB for the
> uncompressed image. If that limit will be reached output the
> flash image file as 'otheros-too-big.bld'.
>
> Signed-off-by: Geoff Levand
> ---
> arch/powerpc/boot/wrapper | 17 +++-
On Thu, May 14, 2020 at 3:46 PM Christophe Leroy
wrote:
>
>
>
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > Introduce a probe_user_read_inst() function to use in cases where
> > probe_user_read() is used for getting an instruction. This will be more
> > useful for prefixed instructions.
> >
59 matches
Mail list logo