* Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
@ 2003-04-08 7:06 ` Hartvig Ekner
0 siblings, 0 replies; 6+ messages in thread
From: Hartvig Ekner @ 2003-04-08 7:06 UTC (permalink / raw)
To: Linux MIPS mailing list
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
@ 2003-04-08 7:06 ` Hartvig Ekner
0 siblings, 0 replies; 6+ messages in thread
From: Hartvig Ekner @ 2003-04-08 7:06 UTC (permalink / raw)
To: Linux MIPS mailing list
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
2003-04-08 7:06 ` Hartvig Ekner
(?)
@ 2003-04-08 10:32 ` Juan Quintela
2003-04-08 21:48 ` Ralf Baechle
-1 siblings, 1 reply; 6+ messages in thread
From: Juan Quintela @ 2003-04-08 10:32 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
>>>>> "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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
2003-04-08 7:06 ` Hartvig Ekner
(?)
(?)
@ 2003-04-08 21:47 ` Ralf Baechle
2003-04-09 10:12 ` Maciej W. Rozycki
-1 siblings, 1 reply; 6+ messages in thread
From: Ralf Baechle @ 2003-04-08 21:47 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR)
2003-04-08 21:47 ` Ralf Baechle
@ 2003-04-09 10:12 ` Maciej W. Rozycki
0 siblings, 0 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2003-04-09 10:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Hartvig Ekner, Linux MIPS mailing list
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 +
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-04-09 10:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-08 7:06 Aliasing in pgtable-bits.h (CONFIG_64BIT_PHYS_ADDR) Hartvig Ekner
2003-04-08 7:06 ` Hartvig Ekner
2003-04-08 10:32 ` Juan Quintela
2003-04-08 21:48 ` Ralf Baechle
2003-04-08 21:47 ` Ralf Baechle
2003-04-09 10:12 ` Maciej W. Rozycki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.