want to clarify powerpc assembly conventions in head.S and entry.S

want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

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.

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

> 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 <benh@kernel.crashing.org>

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

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.

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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/

Re: want to clarify powerpc assembly conventions inhead.S and entry.S

[Benjamin Herrenschmidt]

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/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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/

Re: want to clarify powerpc assembly conventions in head.Sand entry.S

[Benjamin Herrenschmidt]

> 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 <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

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/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Segher Boessenkool]

>> 	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

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Segher Boessenkool]

>> 	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/

Re: want to clarify powerpc assembly conventions in head.S andentry.S

[Benjamin Herrenschmidt]

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/