From: Naveen N. Rao <hidden> Date: 2017-06-13 18:42:27
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
@@ -1411,10 +1411,8 @@ USE_TEXT_SECTION().balignIFETCH_ALIGN_BYTESdo_hash_page:#ifdef CONFIG_PPC_STD_MMU_64-andis.r0,r4,0xa410/*weirderror?*/+andis.r0,r4,0xa450/*weirderror?*/bne-handle_page_fault/*ifnot,trytoinsertaHPTE*/-andis.r0,r4,DSISR_DABRMATCH@h-bne-handle_dabr_faultCURRENT_THREAD_INFO(r11,r1)lwzr0,TI_PREEMPT(r11)/*Ifwe're in an "NMI" */andis.r0,r0,NMI_MASK@h/*(i.e.anirqwhensoft-disabled)*/
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
bne- handle_page_fault /* if not, try to insert a HPTE */
- andis. r0,r4,DSISR_DABRMATCH@h
- bne- handle_dabr_fault
CURRENT_THREAD_INFO(r11, r1)
lwz r0,TI_PREEMPT(r11) /* If we're in an "NMI" */
andis. r0,r0,NMI_MASK@h /* (i.e. an irq when soft-disabled) */
@@ -1442,7 +1440,9 @@ do_hash_page: /* Here we have a page fault that hash_page can't handle. */ handle_page_fault:-11: ld r4,_DAR(r1)+ andis. r0,r4,DSISR_DABRMATCH@h+ bne- handle_dabr_fault+ ld r4,_DAR(r1) ld r5,_DSISR(r1) addi r3,r1,STACK_FRAME_OVERHEAD bl do_page_fault
From: Naveen N. Rao <hidden> Date: 2017-06-14 05:11:20
Hi Aneesh,
On 2017/06/14 08:38AM, Aneesh Kumar K.V wrote:
"Naveen N. Rao" [off-list ref] writes:
quoted
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Hmm... I feel it will be good to do that as part of Ram's series since
he has already coded it up :)
Ram's patches will anyway require a rebase and the change I do here for
detecting DAWR already has a #define, so it should be a simple matter of
including DSISR_DABRMATCH in DSISR_PAGE_FAULT_MASK.
But, if you really feel that I should make that change here, please do
let me know and I will re-spin with those changes.
Thanks for the review!
- Naveen
On Wednesday 14 June 2017 10:41 AM, Naveen N. Rao wrote:
Hi Aneesh,
On 2017/06/14 08:38AM, Aneesh Kumar K.V wrote:
quoted
"Naveen N. Rao" [off-list ref] writes:
quoted
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Hmm... I feel it will be good to do that as part of Ram's series since
he has already coded it up :)
Ram's patches will anyway require a rebase and the change I do here for
detecting DAWR already has a #define, so it should be a simple matter of
including DSISR_DABRMATCH in DSISR_PAGE_FAULT_MASK.
But, if you really feel that I should make that change here, please do
let me know and I will re-spin with those changes.
The thing is that change from 0xa410 to 0xa450 is not clear at all. And
it needs proper documentation. IMHO the best way to do that is switch to
#define name for that constant.
-aneesh
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
Why cant we check for DSISR inside do_hash_page() on P9 ?
Hmm... I feel it will be good to do that as part of Ram's series since
he has already coded it up :)
Ram's patches will anyway require a rebase and the change I do here for
detecting DAWR already has a #define, so it should be a simple matter of
including DSISR_DABRMATCH in DSISR_PAGE_FAULT_MASK.
But, if you really feel that I should make that change here, please do
let me know and I will re-spin with those changes.
The thing is that change from 0xa410 to 0xa450 is not clear at all. And
it needs proper documentation. IMHO the best way to do that is switch to
#define name for that constant.
Not in this patch. It needs to be backported, so it should be as minimal
as possible.
The change from 0xa410 to 0xa450 does need a mention in the changelog,
I'll add that.
cheers
On Wed, Jun 14, 2017 at 10:43:30AM +0530, Aneesh Kumar K.V wrote:
On Wednesday 14 June 2017 10:41 AM, Naveen N. Rao wrote:
quoted
Hi Aneesh,
On 2017/06/14 08:38AM, Aneesh Kumar K.V wrote:
quoted
"Naveen N. Rao" [off-list ref] writes:
quoted
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Hmm... I feel it will be good to do that as part of Ram's series since
he has already coded it up :)
Ram's patches will anyway require a rebase and the change I do here for
detecting DAWR already has a #define, so it should be a simple matter of
including DSISR_DABRMATCH in DSISR_PAGE_FAULT_MASK.
But, if you really feel that I should make that change here, please do
let me know and I will re-spin with those changes.
The thing is that change from 0xa410 to 0xa450 is not clear at all.
And it needs proper documentation. IMHO the best way to do that is
switch to #define name for that constant.
Naveen,
Feel free to take the macro from my patch. I think the magic
number is a little ugly. The earlier it goes the better.
My patch set will probably go through a couple of iterations. So I will
rebase it on top of your changes anyway.
RP
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-06-14 09:27:00
Anshuman Khandual [off-list ref] writes:
On 06/14/2017 12:12 AM, Naveen N. Rao wrote:
quoted
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
Why cant we check for DSISR inside do_hash_page() on P9 ?
We can.
But we also need to check inside handle_page_fault(), because when we're
in Radix mode we don't go via do_hash_page().
So rather than doing it in two places, the patch changes the logic so we
check in handle_page_fault(), and teaches the do_hash_page() code to go
there if DSISR_DABRMATCH is set.
cheers
Hmm... I feel it will be good to do that as part of Ram's series since
he has already coded it up :)
Ram's patches will anyway require a rebase and the change I do here for
detecting DAWR already has a #define, so it should be a simple matter of
including DSISR_DABRMATCH in DSISR_PAGE_FAULT_MASK.
But, if you really feel that I should make that change here, please do
let me know and I will re-spin with those changes.
The thing is that change from 0xa410 to 0xa450 is not clear at all. And
it needs proper documentation. IMHO the best way to do that is switch to
#define name for that constant.
Not in this patch. It needs to be backported, so it should be as minimal
as possible.
Ok.
The change from 0xa410 to 0xa450 does need a mention in the changelog,
I'll add that.
Thanks, Michael!
(emails just started flowing again...)
- Naveen
@@ -1438,11 +1436,16 @@ do_hash_page: /* Error */ blt- 13f++ /* Reload DSISR into r4 for the DABR check below */+ ld r4,_DSISR(r1) #endif /* CONFIG_PPC_STD_MMU_64 */ /* Here we have a page fault that hash_page can't handle. */ handle_page_fault:
Gah! :double-face-palm:
I don't know how I missed this... (yes, I do)
quoted hunk
I added:
@@ -1438,11 +1436,16 @@ do_hash_page: /* Error */ blt- 13f++ /* Reload DSISR into r4 for the DABR check below */+ ld r4,_DSISR(r1) #endif /* CONFIG_PPC_STD_MMU_64 */ /* Here we have a page fault that hash_page can't handle. */ handle_page_fault:
As always, thanks Michael!
I think we can optimize this a bit more to eliminate the loads in
handle_page_fault. Here's an incremental patch above your changes for
-next, this time boot-tested with radix and disable_radix.
- Naveen
-----
[PATCH] powerpc64/exceptions64s: Eliminate a few un-necessary memory loads
In do_hash_page(), we re-load DSISR from stack though it is still present
in register r4. Eliminate the memory load by preserving this register.
Furthermore, handler_page_fault() reloads DAR and DSISR from memory and
this is only required if we fall through from do_hash_page().
Otherwise, r3 and r4 already have DAR and DSISR loaded. Re-use those
and have do_hash_page() reload those registers when falling-through.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Gah! :double-face-palm:
I don't know how I missed this... (yes, I do)
quoted
I added:
@@ -1438,11 +1436,16 @@ do_hash_page: /* Error */ blt- 13f++ /* Reload DSISR into r4 for the DABR check below */+ ld r4,_DSISR(r1) #endif /* CONFIG_PPC_STD_MMU_64 */ /* Here we have a page fault that hash_page can't handle. */ handle_page_fault:
As always, thanks Michael!
I think we can optimize this a bit more to eliminate the loads in
handle_page_fault. Here's an incremental patch above your changes for
-next, this time boot-tested with radix and disable_radix.
- Naveen
-----
[PATCH] powerpc64/exceptions64s: Eliminate a few un-necessary memory loads
In do_hash_page(), we re-load DSISR from stack though it is still present
in register r4. Eliminate the memory load by preserving this register.
Furthermore, handler_page_fault() reloads DAR and DSISR from memory and
this is only required if we fall through from do_hash_page().
Otherwise, r3 and r4 already have DAR and DSISR loaded. Re-use those
and have do_hash_page() reload those registers when falling-through.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Gah! :double-face-palm:
I don't know how I missed this... (yes, I do)
quoted
I added:
@@ -1438,11 +1436,16 @@ do_hash_page: /* Error */ blt- 13f++ /* Reload DSISR into r4 for the DABR check below */+ ld r4,_DSISR(r1) #endif /* CONFIG_PPC_STD_MMU_64 */ /* Here we have a page fault that hash_page can't handle. */ handle_page_fault:
As always, thanks Michael!
I think we can optimize this a bit more to eliminate the loads in
handle_page_fault. Here's an incremental patch above your changes for
-next, this time boot-tested with radix and disable_radix.
- Naveen
-----
[PATCH] powerpc64/exceptions64s: Eliminate a few un-necessary memory loads
In do_hash_page(), we re-load DSISR from stack though it is still present
in register r4. Eliminate the memory load by preserving this register.
Furthermore, handler_page_fault() reloads DAR and DSISR from memory and
this is only required if we fall through from do_hash_page().
Otherwise, r3 and r4 already have DAR and DSISR loaded. Re-use those
and have do_hash_page() reload those registers when falling-through.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Can we avoid that if we rearrange args of other functions calls, so that
we can use r3 and r4 as it is ?
I looked at changing do_page_fault(), but it is called from other places
(booke, entry_32, ..) so, re-arranging the arguments will need more
intrusive changes there potentially slowing those down.
However, I do think we can change the exception vectors to load things
up differently for do_page_fault() and handle_page_fault(). I will
check.
Thanks for the review,
- Naveen
From: Michael Ellerman <hidden> Date: 2017-06-19 12:22:41
On Tue, 2017-06-13 at 18:42:00 UTC, "Naveen N. Rao" wrote:
On P9, trying to use data breakpoints throws the splat shown below (*).
This is because the check for a data breakpoint in DSISR is in
do_hash_page(). Move this check to handle_page_fault() so as to catch
data breakpoints in both hash and radix MMU modes.
While at it, also remove the label '11' that was made redundant by
commit a546498f3bf9aa ("powerpc: Call do_page_fault() with interrupts
off")
(*)
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
pc: c0000000001155e8: find_pid_ns+0x48/0xe0
lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
sp: c0000000ef1e7da0
msr: 9000000000009033
dar: c000000000e19218
dsisr: 400000
current = 0xc0000000f1f59700
paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
pid = 1192, comm = sh
Linux version 4.12.0-rc3-nnr (root@ea605ec2993c) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) ) #74 SMP Tue Jun 13 16:52:49 UTC 2017
enter ? for help
[c0000000ef1e7dc0] c000000000116ac4 find_task_by_vpid+0x44/0x90
[c0000000ef1e7de0] c000000000108800 SyS_setpgid+0x80/0x220
[c0000000ef1e7e30] c00000000000ba6c system_call+0x38/0xfc
--- Exception: c01 (System Call) at 00007fff94480890
SP (7fffd91e7260) is in userspace
Fixes: caca285e5ab4a ("powerpc/mm/radix: Use STD_MMU_64 to properly
isolate hash related code")
Reported-by: Shriya R. Kulkarni <redacted>
Signed-off-by: Naveen N. Rao <redacted>
Can we avoid that if we rearrange args of other functions calls, so that
we can use r3 and r4 as it is ?
Here's a version that does that. Again, boot tested with radix and
disable_radix.
Thanks,
Naveen
-
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
@@ -1474,7 +1474,7 @@ USE_TEXT_SECTION().balignIFETCH_ALIGN_BYTESdo_hash_page:#ifdef CONFIG_PPC_STD_MMU_64-andis.r0,r4,0xa450/*weirderror?*/+andis.r0,r5,0xa450/*weirderror?*/bne-handle_page_fault/*ifnot,trytoinsertaHPTE*/CURRENT_THREAD_INFO(r11,r1)lwzr0,TI_PREEMPT(r11)/*Ifwe're in an "NMI" */
Can we avoid that if we rearrange args of other functions calls, so that
we can use r3 and r4 as it is ?
Here's a version that does that. Again, boot tested with radix and
disable_radix.
Thanks,
Naveen
-
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
Sorry I missed this and now it doesn't apply. Do you mind rebasing.
cheers
Can we avoid that if we rearrange args of other functions calls, so that
we can use r3 and r4 as it is ?
Here's a version that does that. Again, boot tested with radix and
disable_radix.
Thanks,
Naveen
-
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
Sorry I missed this and now it doesn't apply. Do you mind rebasing.
No problem - this is just a small refactoring after all :).
Here's a rebased version. Boot tested on mambo with/without radix.
Thanks,
Naveen
--
[PATCH v3] powerpc/exceptions64s: Eliminate a few un-necessary memory
loads
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
@@ -1523,7 +1523,7 @@ do_hash_page:#ifdef CONFIG_PPC_BOOK3S_64lisr0,DSISR_BAD_FAULT_64S@horir0,r0,DSISR_BAD_FAULT_64S@l-and.r0,r4,r0/*weirderror?*/+and.r0,r5,r0/*weirderror?*/bne-handle_page_fault/*ifnot,trytoinsertaHPTE*/CURRENT_THREAD_INFO(r11,r1)lwzr0,TI_PREEMPT(r11)/*Ifwe're in an "NMI" */
Can we avoid that if we rearrange args of other functions calls, so that
we can use r3 and r4 as it is ?
Here's a version that does that. Again, boot tested with radix and
disable_radix.
Thanks,
Naveen
-
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
Sorry I missed this and now it doesn't apply. Do you mind rebasing.
No problem - this is just a small refactoring after all :).
Here's a rebased version. Boot tested on mambo with/without radix.
Thanks,
Naveen
--
[PATCH v3] powerpc/exceptions64s: Eliminate a few un-necessary memory
loads
Change data_access_common() and instruction_access_common() to load the
trap number in r3, DAR in r4 and DSISR in r5 (rather than in r5, r3 and
r4 respectively). This change allows us to eliminate a few un-necessary
memory loads and register move operations in handle_page_fault(),
handle_dabr_fault() and label '77'.
Signed-off-by: Naveen N. Rao <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 38 +++++++++++++++++-------------------
1 file changed, 18 insertions(+), 20 deletions(-)
@@ -1523,7 +1523,7 @@ do_hash_page:#ifdef CONFIG_PPC_BOOK3S_64lisr0,DSISR_BAD_FAULT_64S@horir0,r0,DSISR_BAD_FAULT_64S@l-and.r0,r4,r0/*weirderror?*/+and.r0,r5,r0/*weirderror?*/bne-handle_page_fault/*ifnot,trytoinsertaHPTE*/CURRENT_THREAD_INFO(r11,r1)lwzr0,TI_PREEMPT(r11)/*Ifwe're in an "NMI" */