I'm doing some work in head.S and entry.S, and I just wanted to make
sure that I had the conventions down.
According to the docs I read, r0 and r3-12 are caller-saves. They seem
to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
ret_from_except() (entry.S). Thus, if I add code in entry.S I should be
able to use any of those registers, without having to worry about
restoring them myself--correct?
Also, I'm a bit confused about the three instances of the following line
in entry.S:
stwcx. r0,0,r1 /* to clear the reservation */
I don't see the corresponding lwarx instruction. What reservation is it
referring to?
Thanks,
Chris
On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
> I'm doing some work in head.S and entry.S, and I just wanted to make
> sure that I had the conventions down.
>
> According to the docs I read, r0 and r3-12 are caller-saves. They seem
> to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
> ret_from_except() (entry.S). Thus, if I add code in entry.S I should be
> able to use any of those registers, without having to worry about
> restoring them myself--correct?
Yes. For interrupts or faults that's right. Syscalls are a bit special
though.
> Also, I'm a bit confused about the three instances of the following line
> in entry.S:
>
> stwcx. r0,0,r1 /* to clear the reservation */
>
> I don't see the corresponding lwarx instruction. What reservation is it
> referring to?
This is to clear any possible pending reservation if any. The problem is
that the reservation mecanism only works accross multiple CPUs. A normal
store at an address covered by a reservation on the same CPU will not break
the reservation. Thus, to protect from that, any interrupt or exception
makes sure to return to the normal code flow with any pending reservation
cleared.
Ben.
On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
> I'm doing some work in head.S and entry.S, and I just wanted to make
> sure that I had the conventions down.
>
> According to the docs I read, r0 and r3-12 are caller-saves. They seem
> to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
> ret_from_except() (entry.S). Thus, if I add code in entry.S I should be
> able to use any of those registers, without having to worry about
> restoring them myself--correct?
Yes. For interrupts or faults that's right. Syscalls are a bit special
though.
> Also, I'm a bit confused about the three instances of the following line
> in entry.S:
>
> stwcx. r0,0,r1 /* to clear the reservation */
>
> I don't see the corresponding lwarx instruction. What reservation is it
> referring to?
This is to clear any possible pending reservation if any. The problem is
that the reservation mecanism only works accross multiple CPUs. A normal
store at an address covered by a reservation on the same CPU will not break
the reservation. Thus, to protect from that, any interrupt or exception
makes sure to return to the normal code flow with any pending reservation
cleared.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Benjamin Herrenschmidt wrote:
> On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
>>According to the docs I read, r0 and r3-12 are caller-saves. They seem
>>to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
>>ret_from_except() (entry.S). Thus, if I add code in entry.S I should be
>>able to use any of those registers, without having to worry about
>>restoring them myself--correct?
>
> Yes. For interrupts or faults that's right. Syscalls are a bit special
> though.
You knew this was coming... What's special about syscalls? There's the
r3 thing, but other than that...
Thanks for your help with this stuff. As I've been slowly wrapping my
head around it I've been continuously wishing for some kind of design
rules document describing the various paths through the assembly code,
along with register conventions and such. I eventually did find the
conventions linked off the penguinppc website, but it was not obvious
from just reading the code or the ppc stuff in the Documentation directory.
Chris
> You knew this was coming... What's special about syscalls? There's the
> r3 thing, but other than that...
The whole codepath is a bit different, there's the syscall trace,
we can avoid saving much more registers are syscalls are function
calls and so can clobber the non volatiles, etc...
> Thanks for your help with this stuff. As I've been slowly wrapping my
> head around it I've been continuously wishing for some kind of design
> rules document describing the various paths through the assembly code,
> along with register conventions and such. I eventually did find the
> conventions linked off the penguinppc website, but it was not obvious
> from just reading the code or the ppc stuff in the Documentation directory.
>
> Chris
--
Benjamin Herrenschmidt <[email protected]>
Benjamin Herrenschmidt wrote:
> On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
>>According to the docs I read, r0 and r3-12 are caller-saves. They seem
>>to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
>>ret_from_except() (entry.S). Thus, if I add code in entry.S I should be
>>able to use any of those registers, without having to worry about
>>restoring them myself--correct?
>
> Yes. For interrupts or faults that's right. Syscalls are a bit special
> though.
You knew this was coming... What's special about syscalls? There's the
r3 thing, but other than that...
Thanks for your help with this stuff. As I've been slowly wrapping my
head around it I've been continuously wishing for some kind of design
rules document describing the various paths through the assembly code,
along with register conventions and such. I eventually did find the
conventions linked off the penguinppc website, but it was not obvious
from just reading the code or the ppc stuff in the Documentation directory.
Chris
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
> You knew this was coming... What's special about syscalls? There's the
> r3 thing, but other than that...
The whole codepath is a bit different, there's the syscall trace,
we can avoid saving much more registers are syscalls are function
calls and so can clobber the non volatiles, etc...
> Thanks for your help with this stuff. As I've been slowly wrapping my
> head around it I've been continuously wishing for some kind of design
> rules document describing the various paths through the assembly code,
> along with register conventions and such. I eventually did find the
> conventions linked off the penguinppc website, but it was not obvious
> from just reading the code or the ppc stuff in the Documentation directory.
>
> Chris
--
Benjamin Herrenschmidt <[email protected]>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Benjamin Herrenschmidt wrote:
>>You knew this was coming... What's special about syscalls? There's the
>>r3 thing, but other than that...
>
> The whole codepath is a bit different, there's the syscall trace,
> we can avoid saving much more registers are syscalls are function
> calls and so can clobber the non volatiles, etc...
It appears that we always enter the kernel via "transfer_to_handler",
and return via "ret_from_except". Is this true? (I'm running on at
least a 74xx chip.)
I want to insert two new bits of code, one that gets called before the
exception handler when we drop from userspace to kernelspace, and one as
late as possible before going back to userspace. I need to catch
syscalls, interrupts, exceptions, everything.
The entry one I planned on putting in "transfer_to_handler", just before
"addi r11,r1,STACK_FRAME_OVERHEAD".
I was planning on putting the exit one just after the "restore_user"
label. Will this catch all possible returns to userspace?
Thanks,
Chris
Benjamin Herrenschmidt wrote:
>>You knew this was coming... What's special about syscalls? There's the
>>r3 thing, but other than that...
>
> The whole codepath is a bit different, there's the syscall trace,
> we can avoid saving much more registers are syscalls are function
> calls and so can clobber the non volatiles, etc...
It appears that we always enter the kernel via "transfer_to_handler",
and return via "ret_from_except". Is this true? (I'm running on at
least a 74xx chip.)
I want to insert two new bits of code, one that gets called before the
exception handler when we drop from userspace to kernelspace, and one as
late as possible before going back to userspace. I need to catch
syscalls, interrupts, exceptions, everything.
The entry one I planned on putting in "transfer_to_handler", just before
"addi r11,r1,STACK_FRAME_OVERHEAD".
I was planning on putting the exit one just after the "restore_user"
label. Will this catch all possible returns to userspace?
Thanks,
Chris
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 2004-04-13 at 00:31, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>You knew this was coming... What's special about syscalls? There's the
> >>r3 thing, but other than that...
> >
> > The whole codepath is a bit different, there's the syscall trace,
> > we can avoid saving much more registers are syscalls are function
> > calls and so can clobber the non volatiles, etc...
>
> It appears that we always enter the kernel via "transfer_to_handler",
> and return via "ret_from_except". Is this true? (I'm running on at
> least a 74xx chip.)
ret_from_syscall for syscalls, hash_page also has a different
return to userland path, and load_up_{fpu,altivec} have their own
retturn path.
On ppc32 currently, the entry is almost always the same except for
hash_page and load_up_{fpu,altivec}
> I want to insert two new bits of code, one that gets called before the
> exception handler when we drop from userspace to kernelspace, and one as
> late as possible before going back to userspace. I need to catch
> syscalls, interrupts, exceptions, everything.
>
> The entry one I planned on putting in "transfer_to_handler", just before
> "addi r11,r1,STACK_FRAME_OVERHEAD".
>
> I was planning on putting the exit one just after the "restore_user"
> label. Will this catch all possible returns to userspace?
No.
Ben.
On Tue, 2004-04-13 at 00:31, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>You knew this was coming... What's special about syscalls? There's the
> >>r3 thing, but other than that...
> >
> > The whole codepath is a bit different, there's the syscall trace,
> > we can avoid saving much more registers are syscalls are function
> > calls and so can clobber the non volatiles, etc...
>
> It appears that we always enter the kernel via "transfer_to_handler",
> and return via "ret_from_except". Is this true? (I'm running on at
> least a 74xx chip.)
ret_from_syscall for syscalls, hash_page also has a different
return to userland path, and load_up_{fpu,altivec} have their own
retturn path.
On ppc32 currently, the entry is almost always the same except for
hash_page and load_up_{fpu,altivec}
> I want to insert two new bits of code, one that gets called before the
> exception handler when we drop from userspace to kernelspace, and one as
> late as possible before going back to userspace. I need to catch
> syscalls, interrupts, exceptions, everything.
>
> The entry one I planned on putting in "transfer_to_handler", just before
> "addi r11,r1,STACK_FRAME_OVERHEAD".
>
> I was planning on putting the exit one just after the "restore_user"
> label. Will this catch all possible returns to userspace?
No.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Benjamin Herrenschmidt wrote:
> ret_from_syscall for syscalls, hash_page also has a different
> return to userland path, and load_up_{fpu,altivec} have their own
> retturn path.
> On ppc32 currently, the entry is almost always the same except for
> hash_page and load_up_{fpu,altivec}
Thanks, that's exactly the information I needed.
Chris
Benjamin Herrenschmidt wrote:
> ret_from_syscall for syscalls, hash_page also has a different
> return to userland path, and load_up_{fpu,altivec} have their own
> retturn path.
> On ppc32 currently, the entry is almost always the same except for
> hash_page and load_up_{fpu,altivec}
Thanks, that's exactly the information I needed.
Chris
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
>> stwcx. r0,0,r1 /* to clear the reservation */
>>
>> I don't see the corresponding lwarx instruction. What reservation is
>> it
>> referring to?
>
> This is to clear any possible pending reservation if any. The problem
> is
> that the reservation mecanism only works accross multiple CPUs. A
> normal
> store at an address covered by a reservation on the same CPU will not
> break
> the reservation. Thus, to protect from that, any interrupt or exception
> makes sure to return to the normal code flow with any pending
> reservation
> cleared.
Worse, it is allowed for a PowerPC implementation to not check if
stwcx. and
stdcx. refer to the same address as the preceding lwarx or ldarx . So,
a store
conditional insn can succeed because the cpu holds some *other*
reservation.
Therefore, the kernel has to clear any reservation that might not have
been
generated by the user code it is returning to.
Segher
>> stwcx. r0,0,r1 /* to clear the reservation */
>>
>> I don't see the corresponding lwarx instruction. What reservation is
>> it
>> referring to?
>
> This is to clear any possible pending reservation if any. The problem
> is
> that the reservation mecanism only works accross multiple CPUs. A
> normal
> store at an address covered by a reservation on the same CPU will not
> break
> the reservation. Thus, to protect from that, any interrupt or exception
> makes sure to return to the normal code flow with any pending
> reservation
> cleared.
Worse, it is allowed for a PowerPC implementation to not check if
stwcx. and
stdcx. refer to the same address as the preceding lwarx or ldarx . So,
a store
conditional insn can succeed because the cpu holds some *other*
reservation.
Therefore, the kernel has to clear any reservation that might not have
been
generated by the user code it is returning to.
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/