Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Hartvig Ekner]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

From pgtable-bits.h:

#if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)

#define _PAGE_PRESENT               (1<<6)  /* implemented in software */
#define _PAGE_READ                  (1<<7)  /* implemented in software */
#define _PAGE_WRITE                 (1<<8)  /* implemented in software */
#define _PAGE_ACCESSED              (1<<9)  /* implemented in software */
#define _PAGE_MODIFIED              (1<<10) /* implemented in software */

#define _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug  */
#define _PAGE_GLOBAL                (1<<0)

Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?

/Hartvig


[-- Attachment #2: Type: text/html, Size: 1807 bytes --]

Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Hartvig Ekner]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]

Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Juan Quintela]

>>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:

hartvig> From pgtable-bits.h:
hartvig> #if defined(CONFIG_CPU_MIPS32) && defined(CONFIG_64BIT_PHYS_ADDR)

hartvig> #define _PAGE_PRESENT               (1<<6)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_READ                  (1<<7)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_WRITE                 (1<<8)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_ACCESSED              (1<<9)  /* implemented in software
hartvig> */
hartvig> #define _PAGE_MODIFIED              (1<<10) /* implemented in software
hartvig> */

hartvig> #define  _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug
hartvig> */
hartvig> #define _PAGE_GLOBAL                (1<<0)

hartvig> Is  the aliasing between R4KBUG & GLOBAL intentional? This is the only
hartvig> CONFIG case where it
hartvig> is  done. Superficially, I can't see R4KBUG used anywhere, so maybe it
hartvig> doesn't matter. But
hartvig> if R4KBUG truly isn't used, why not consider removing it entirely from
hartvig> all PTE layouts?

I will bet that this is related to the comment in
arch/mips/mm/tlb-r4k.c workaround that is unimplemented:

/* We will need multiple versions of update_mmu_cache(), one that just
 * updates the TLB with the new pte(s), and another which also checks
 * for the R4k "end of page" hardware bug and does the needy.
 */

Anyways, it appears that affected CPUS are only r4k and r4400 or so,
no big deal for rest of CPU's.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Ralf Baechle]

On Tue, Apr 08, 2003 at 12:32:50PM +0200, Juan Quintela wrote:

> I will bet that this is related to the comment in
> arch/mips/mm/tlb-r4k.c workaround that is unimplemented:

Correct.

  Ralf

Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Ralf Baechle]

On Tue, Apr 08, 2003 at 09:06:24AM +0200, Hartvig Ekner wrote:

> #define _PAGE_R4KBUG                (1<<0)  /* workaround for r4k bug  */
> #define _PAGE_GLOBAL                (1<<0)
> 
> Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
> is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
> if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?

It's there for a R4000 bug workaround waiting to be finally written by
somebody ...

  Ralf

Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)

[Maciej W. Rozycki]

On Tue, 8 Apr 2003, Ralf Baechle wrote:

> > Is the aliasing between R4KBUG & GLOBAL intentional? This is the only CONFIG case where it
> > is done. Superficially, I can't see R4KBUG used anywhere, so maybe it doesn't matter. But
> > if R4KBUG truly isn't used, why not consider removing it entirely from all PTE layouts?
> 
> It's there for a R4000 bug workaround waiting to be finally written by
> somebody ...

 Possibly doing that in the toolchain may be a reasonable alternative. 
Actually wasting say 4 last words for nops on every page unconditionally
when building for the affected processors may be a good approximation of a
workaround for a start. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +