85xx Address space query
Hi, I am a newbie, trying to learn but have a few queries, nice if you could respond For linux on 85xx systems... (a) Kernel code runs in PR=0 AS=0 and PID=0, which user space application run in PR=1 AS=0 and PID 1-255. Is this correct. (b) I am writing a small program where the application code opens invokes a ioctl call and passes a buffer pointer ( say 0x1 in user space) Now the driver code is using copy_from_user. How this works internally ? 1. User code executes ioctl 2. interrupt goes to the kernel 3. ioctl handler in driver gets invoked The buffer pointer still contains 0x1. How kernel code running in PR=0 accesses it and does the copy. I am not able to see a address space switch in the asm code of copy_tofrom_user. Please respond -TRX ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
On Wed, Jun 24, 2009 at 6:45 PM, Kumar Gala wrote: > > On Jun 24, 2009, at 4:44 AM, kernel mailz wrote: > >> Hi, >> >> I am a newbie, trying to learn but have a few queries, nice if you could >> respond >> For linux on 85xx systems... >> >> (a) Kernel code runs in PR=0 AS=0 and PID=0, which user space application >> run in PR=1 AS=0 and PID 1-255. >> Is this correct. > > correct. > >> (b) I am writing a small program where the application code opens invokes >> a ioctl call and passes a buffer pointer ( say 0x1 in user space) >> Now the driver code is using copy_from_user. >> How this works internally ? >> >> 1. User code executes ioctl >> 2. interrupt goes to the kernel > > On the interrupt the PR changes from 0 -> 1 > >> 3. ioctl handler in driver gets invoked >> The buffer pointer still contains 0x1. >> >> How kernel code running in PR=0 accesses it and does the copy. I am not >> able to see a address space switch in the asm code of copy_tofrom_user. > > There isn't a address space switch. But address spaces exist at the same > time. The user app is given 0..0xc000_ and the kernel uses > 0xc000_..0x_. > Ah Ok, I get it Thanks Kumar But If the app was running with PID=1, interrupt occurs, kernel code gets executed in PID=1, how does the kernel handle this ? and goes back to PID=0, since its translations are all in PID=0 > - k > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
So this means when kernel gets interrupted by app which may be in PID=5 (say) kernel translations for PID=0 remain valid ? I am not able to follow Scott -TZ On Thu, Jun 25, 2009 at 4:22 AM, Scott Wood wrote: > kernel mailz wrote: >> >> But If the app was running with PID=1, interrupt occurs, kernel code >> gets executed in PID=1, how does the kernel handle this ? and goes >> back to PID=0, since its translations are all in PID=0 > > PID 0 is special, it's mappings are present regardless of the value of the > PID register. > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
If an aap has to be placed in AS=1 and it issues an ioctl, kernel needs to be modified ? I guess the PID=0 trick will work when AS is same right ? On 6/25/09, Kumar Gala wrote: > That is correct. The PID = 0 translations are always valid. > > - k > > On Jun 25, 2009, at 5:51 AM, kernel mailz wrote: > >> So this means >> when kernel gets interrupted by app which may be in PID=5 (say) >> kernel translations for PID=0 remain valid ? >> I am not able to follow Scott >> >> -TZ >> >> On Thu, Jun 25, 2009 at 4:22 AM, Scott Wood >> wrote: >>> kernel mailz wrote: >>>> >>>> But If the app was running with PID=1, interrupt occurs, kernel code >>>> gets executed in PID=1, how does the kernel handle this ? and goes >>>> back to PID=0, since its translations are all in PID=0 >>> >>> PID 0 is special, it's mappings are present regardless of the value >>> of the >>> PID register. >>> >>> -Scott >>> >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Slowing down the schedular, How?
Hi, I have a SMP linux running on 85xx poweprc. Say on Core 0 and Core 1 two different processes are running and on both the schedular runs. Now for some special case, if one of my process issues a ioctl which gets serviced by a kernel module, I wish to slow the schedular on that core only. Otherwise the performance will get degraded. Should I use highest priority tasklet, will it be sufficient or i need to do something special -TZ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Inline Assembly queries
Hello All the gurus, I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc There are a few queries 1. asm volatile or simply asm produce the same assembly code. Tried with a few examples but didnt find any difference by adding volatile with asm 2. Use of "memory" and clobbered registers. "memory" - a. announce to the compiler that the memory has been modified b. this instruction writes to some memory (other than a listed output) and GCC shouldn’t cache memory values in registers across this asm. I tried with stw and stwcx instruction, adding "memory" has no effect. Is there any example scenerio where gcc would generate different assembly by adding / removing "memory" ? -TZ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inline Assembly queries
Thanks Ian,
For the "memory" clobber
I tried with the a function in linux kernel
--
/*
* Atomic exchange
*
* Changes the memory location '*ptr' to be val and returns
* the previous value stored there.
*/
static inline unsigned long
__xchg_u32(volatile void *p, unsigned long val)
{
unsigned long prev;
__asm__ __volatile__(
"1: lwarx %0,0,%2 \n"
" stwcx. %3,0,%2 \n\
bne-1b"
: "=&r" (prev), "+m" (*(volatile unsigned int *)p)
: "r" (p), "r" (val)
//:"memory","cc");
return prev;
}
#define ADDR 0x1000
int main()
{
__xchg_u32((void*)ADDR, 0x2000);
__xchg_u32((void*)ADDR, 0x3000);
return 0;
}
Got the same asm, when compiled with O1 , with / without "memory" clobber
13fc :
13fc: 39 20 10 00 li r9,4096
1400: 38 00 20 00 li r0,8192
1404: 7d 60 48 28 lwarx r11,0,r9
1408: 7c 00 49 2d stwcx. r0,0,r9
140c: 40 a2 ff f8 bne-1404
1410: 38 00 30 00 li r0,12288
1414: 7d 60 48 28 lwarx r11,0,r9
1418: 7c 00 49 2d stwcx. r0,0,r9
141c: 40 a2 ff f8 bne-1414
1420: 38 60 00 00 li r3,0
1424: 4e 80 00 20 blr
No diff ?
am I choosing the right example ?
-TZ
On Sun, Jun 28, 2009 at 4:50 AM, Ian Lance Taylor wrote:
> kernel mailz writes:
>
>> I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
>> There are a few queries
>>
>> 1. asm volatile or simply asm produce the same assembly code.
>> Tried with a few examples but didnt find any difference by adding
>> volatile with asm
>>
>> 2. Use of "memory" and clobbered registers.
>>
>> "memory" -
>> a. announce to the compiler that the memory has been modified
>> b. this instruction writes to some memory (other than a listed output)
>> and GCC shouldn’t cache memory values in registers across this asm.
>>
>> I tried with stw and stwcx instruction, adding "memory" has no effect.
>>
>> Is there any example scenerio where gcc would generate different
>> assembly by adding / removing "memory" ?
>
> Please never send a message to both g...@gcc.gnu.org and
> gcc-h...@gcc.gnu.org. This message is appropriate for
> gcc-h...@gcc.gnu.org, not for g...@gcc.gnu.org. Thanks.
>
> An asm with no outputs is always considered to be volatile. To see the
> affect of volatile, just try something like
> asm ("# modify %0" : "=r" (i) : /* no inputs */ : /* no clobbers */);
> Try it with and without optimization.
>
> As the documentation says, the effect of adding a "memory" clobber is
> that gcc does not cache values in registers across the asm. So the
> effect will be shown in something like
> int i = *p;
> asm volatile ("# read %0" : : "r" (i));
> return *p;
> The memory clobber will only make a different when optimizing.
>
> Ian
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Inline Assembly queries
I tried a small example
int *p = 0x1000;
int a = *p;
asm("sync":::"memory");
a = *p;
and
volatile int *p = 0x1000;
int a = *p;
asm("sync");
a = *p
Got the same assembly.
Which is right.
So does it mean, if proper use of volatile is done, there is no need
of "memory" ?
But then why below example of __xchg uses both ?
I am confused!
Anyone has a clue?
-TZ
-- Forwarded message --
From: kernel mailz
Date: Sun, Jun 28, 2009 at 10:27 AM
Subject: Re: Inline Assembly queries
To: Ian Lance Taylor
Cc: gcc-h...@gcc.gnu.org, linuxppc-...@ozlabs.org
Thanks Ian,
For the "memory" clobber
I tried with the a function in linux kernel
--
/*
* Atomic exchange
*
* Changes the memory location '*ptr' to be val and returns
* the previous value stored there.
*/
static inline unsigned long
__xchg_u32(volatile void *p, unsigned long val)
{
unsigned long prev;
__asm__ __volatile__(
"1: lwarx %0,0,%2 \n"
" stwcx. %3,0,%2 \n\
bne- 1b"
: "=&r" (prev), "+m" (*(volatile unsigned int *)p)
: "r" (p), "r" (val)
// :"memory","cc");
return prev;
}
#define ADDR 0x1000
int main()
{
__xchg_u32((void*)ADDR, 0x2000);
__xchg_u32((void*)ADDR, 0x3000);
return 0;
}
Got the same asm, when compiled with O1 , with / without "memory" clobber
13fc :
13fc: 39 20 10 00 li r9,4096
1400: 38 00 20 00 li r0,8192
1404: 7d 60 48 28 lwarx r11,0,r9
1408: 7c 00 49 2d stwcx. r0,0,r9
140c: 40 a2 ff f8 bne- 1404
1410: 38 00 30 00 li r0,12288
1414: 7d 60 48 28 lwarx r11,0,r9
1418: 7c 00 49 2d stwcx. r0,0,r9
141c: 40 a2 ff f8 bne- 1414
1420: 38 60 00 00 li r3,0
1424: 4e 80 00 20 blr
No diff ?
am I choosing the right example ?
-TZ
On Sun, Jun 28, 2009 at 4:50 AM, Ian Lance Taylor wrote:
> kernel mailz writes:
>
>> I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
>> There are a few queries
>>
>> 1. asm volatile or simply asm produce the same assembly code.
>> Tried with a few examples but didnt find any difference by adding
>> volatile with asm
>>
>> 2. Use of "memory" and clobbered registers.
>>
>> "memory" -
>> a. announce to the compiler that the memory has been modified
>> b. this instruction writes to some memory (other than a listed output)
>> and GCC shouldn’t cache memory values in registers across this asm.
>>
>> I tried with stw and stwcx instruction, adding "memory" has no effect.
>>
>> Is there any example scenerio where gcc would generate different
>> assembly by adding / removing "memory" ?
>
> Please never send a message to both g...@gcc.gnu.org and
> gcc-h...@gcc.gnu.org. This message is appropriate for
> gcc-h...@gcc.gnu.org, not for g...@gcc.gnu.org. Thanks.
>
> An asm with no outputs is always considered to be volatile. To see the
> affect of volatile, just try something like
> asm ("# modify %0" : "=r" (i) : /* no inputs */ : /* no clobbers */);
> Try it with and without optimization.
>
> As the documentation says, the effect of adding a "memory" clobber is
> that gcc does not cache values in registers across the asm. So the
> effect will be shown in something like
> int i = *p;
> asm volatile ("# read %0" : : "r" (i));
> return *p;
> The memory clobber will only make a different when optimizing.
>
> Ian
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to implement kexec on e500 ?
Did some searching on the archieve Looks like this is a old patch [PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms Dale Farnsworth Thu, 22 Nov 2007 07:51:52 -0800 Is this the patch you were referring to kumar -TZ On Mon, Jun 29, 2009 at 9:06 PM, wilbur.chan wrote: > Excuse me , > > btw,how to search these patches on this maillist? > > through Linuxppc-dev Archives one by one? > > Cheers, > > wilbur > > 2009/6/29, Kumar Gala : >> >> On Jun 29, 2009, at 8:47 AM, wilbur.chan wrote: >> >>> kernel 2.6.21.7 >>> >>> As we know , kexec stores data for new kernel image , in the form >>> of a page list. >>> >>> And kexec uses the physical address of the another page for a >>> "next-page" pointer. >>> >>> However, PowerPC e500 does not allow users to turn off the MMU, so we >>> can not used physical address directly in our code. >>> >>> >>> Someone suggested that changing relocate_kernel.S to add a TLB 1-to-1 >>> mapping of DRAM . >>> >>> What does "mapping" mean ? >>> >>> Any suggestion to implement kexec on e500 ? >> >> Wilbur, kexec has been implemented on e500. There are some patches on >> the list for this and they just need to be respun and reviewed again. >> >> - k >> > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inline Assembly queries
Consider atomic_add and atomic_add_return in kernel code.
On Tue, Jun 30, 2009 at 2:59 AM, Ian Lance Taylor wrote:
> kernel mailz writes:
>
>> I tried a small example
>>
>> int *p = 0x1000;
>> int a = *p;
>> asm("sync":::"memory");
>> a = *p;
>>
>> and
>>
>> volatile int *p = 0x1000;
>> int a = *p;
>> asm("sync");
>> a = *p
>>
>> Got the same assembly.
>> Which is right.
>>
>> So does it mean, if proper use of volatile is done, there is no need
>> of "memory" ?
>
> You have to consider the effects of inlining, which may bring in other
> memory loads and stores through non-volatile pointers.
>
> Ian
>
Consider
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\
bne-1b"
: "=&r" (t), "+m" (v->counter)
: "r" (a), "r" (&v->counter)
: "cc");
}
static __inline__ int atomic_add_return(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
LWSYNC_ON_SMP
"1: lwarx %0,0,%2 # atomic_add_return\n\
add %0,%1,%0\n"
PPC405_ERR77(0,%2)
" stwcx. %0,0,%2 \n\
bne-1b"
ISYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
return t;
}
I am not able to figure out why "memory" is added in latter
-TZ
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inline Assembly queries
Hi Scott,
I agree with you, kind of understand that it is required.
But buddy unless you see some construct work or by adding the
construct a visible difference is there, the concept is just piece of
theory.
I am trying all the kernel code inline assembly to find an example
that works differently with memory.
For instance take atomic_add , atomic_add_return, while the
atomic_add_return has the "memory", atomic_add skips it.
-TZ
On Tue, Jun 30, 2009 at 12:57 AM, Scott Wood wrote:
> On Mon, Jun 29, 2009 at 09:19:57PM +0530, kernel mailz wrote:
>> I tried a small example
>>
>> int *p = 0x1000;
>> int a = *p;
>> asm("sync":::"memory");
>> a = *p;
>>
>> and
>>
>> volatile int *p = 0x1000;
>> int a = *p;
>> asm("sync");
>> a = *p
>>
>> Got the same assembly.
>> Which is right.
>>
>> So does it mean, if proper use of volatile is done, there is no need
>> of "memory" ?
>
> No. As I understand it, volatile concerns deletion of the asm statement
> (if no outputs are used) and reordering with respect to other asm
> statements (not sure whether GCC will actually do this), while the memory
> clobber concerns optimization of non-asm loads/stores around the asm
> statement.
>
>> static inline unsigned long
>> __xchg_u32(volatile void *p, unsigned long val)
>> {
>> unsigned long prev;
>>
>> __asm__ __volatile__(
>>
>> "1: lwarx %0,0,%2 \n"
>>
>> " stwcx. %3,0,%2 \n\
>> bne- 1b"
>>
>> : "=&r" (prev), "+m" (*(volatile unsigned int *)p)
>> : "r" (p), "r" (val)
>> // :"memory","cc");
>>
>> return prev;
>> }
>> #define ADDR 0x1000
>> int main()
>> {
>> __xchg_u32((void*)ADDR, 0x2000);
>> __xchg_u32((void*)ADDR, 0x3000);
>>
>> return 0;
>>
>> }
>>
>> Got the same asm, when compiled with O1 , with / without "memory" clobber
>
> This isn't a good test case, because there's nothing other than inline
> asm going on in that function for GCC to optimize. Plus, it's generally
> not a good idea, when talking about what the compiler is or isn't allowed
> to do, to point to a single test case (or even several) and say that it
> isn't required because you don't notice a difference. Even if there were
> no code at all with which it made a difference with GCC version X, it
> could make a difference with GCC version X+1.
>
> -Scott
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Inline assembly queries [2]
Hi,
Thanks for responding to my previous mail. A few more queries
a. What is the use of adding format specifiers in inline assembly
like
asm volatile("ld%U1%X1 %0,%1":"=r"(ret) : "m"(*ptr) : "memory");
b. using m or Z with a memory address. I tried replacing m/Z but no change
Is there some guideline ?
gcc documentation says Z is obsolete. Is m/Z replaceable ?
- Manish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inline assembly queries [2]
Hi Brad,
Thanks for responding.
My query was more on %U1%X1, I guess it is specifying U and/or X for %1 right ?
what does U/X stand for (is it similar to u - unsigned and x for a hex address)
are there any more literals like U/X/...
-Manish
On Fri, Jul 3, 2009 at 11:10 PM, Brad Boyer wrote:
> On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
>> Thanks for responding to my previous mail. A few more queries
>>
>> a. What is the use of adding format specifiers in inline assembly
>> like
>> asm volatile("ld%U1%X1 %0,%1":"=r"(ret) : "m"(*ptr) : "memory");
>
> The format specifiers limit which registers or addressing modes will
> be chosen to access that parameter. For example, if you're using an
> instruction that treats r0 as a literal 0 value, you can't use the
> "r" specifier for that or you may see problems if it happens to allocate
> r0 for that particular argument. For memory access, the "m" lets you
> use any of the normal load/store patterns (which is why this particular
> choice also requires the "%U1%X1" part to allow changing the instruction).
> The system was setup for an older style chip like x86 or 68k with many
> restrictions on which registers can be used where and large numbers of
> different addressing modes for accessing memory. It's a little clumsy
> for ppc by comparison to most other chips, but it's a fundamental part
> of inline assembly processing in gcc.
>
>> b. using m or Z with a memory address. I tried replacing m/Z but no change
>> Is there some guideline ?
>> gcc documentation says Z is obsolete. Is m/Z replaceable ?
>
> No idea. I don't remember ever seeing 'Z' used in anything. Maybe somebody
> else remembers what it used to mean.
>
> Brad Boyer
> f...@allandria.com
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
