[parisc-linux] pgtable.h:acc_rights()

[parisc-linux] pgtable.h:acc_rights()

[Matthew Wilcox]

Why is acc_rights written like this?

#define acc_rights(pte)       \
        (((pte) & _PAGE_EXEC) ? \
                (((pte) & _PAGE_RW) ? \
                        acc_r(3,acc_pl(pte),acc_pl(pte)) : \
                        acc_r(3,acc_pl(pte),acc_pl(pte))) : \
                (((pte) & _PAGE_RW) ? \
                        acc_r(1,acc_pl(pte),acc_pl(pte)) : \
                        acc_r(1,acc_pl(pte),acc_pl(pte))))

According to the PA-1.1 Architecture manual I have here, if the page isn't
writable, the MSB should be clear, like so:

#define acc_rights(pte)       \
        (((pte) & _PAGE_EXEC) ? \
                (((pte) & _PAGE_RW) ? \
                        acc_r(3,acc_pl(pte),acc_pl(pte)) : \
                        acc_r(2,acc_pl(pte),acc_pl(pte))) : \
                (((pte) & _PAGE_RW) ? \
                        acc_r(1,acc_pl(pte),acc_pl(pte)) : \
                        acc_r(0,acc_pl(pte),acc_pl(pte))))

of course, it should be rewritten to look much cleaner.  In fact,
by renumbering the bits, we could get that for free (as long as we put
a big fat warning above the #defines of _PAGE_* to warn that the
constants are in that order for hardware efficiency).
              
Anyway, I'm after a spare bit in the pte for _PAGE_GATEWAY.  As I
understand it (from the mk_pte() macro), there are 12 bits available,
only 8 of which are used, so I can nobble one of them to mark a page
as being a gateway, right?

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] pgtable.h:acc_rights()

[Philipp Rumpf]

> Why is acc_rights written like this?

See my commit message.  Basically that works around the "pages mapped read-only
when they should be read-write" problem Thomas reported.

> of course, it should be rewritten to look much cleaner.  In fact,
> by renumbering the bits, we could get that for free (as long as we put
> a big fat warning above the #defines of _PAGE_* to warn that the
> constants are in that order for hardware efficiency).

We are still looking for the optimal layout of the 12 _PAGE_* bits we have.
The word we need to translate to looks like this:

0  1  2  3  4  5  ... 11 12 13 ... 31
X  X  T  D  B  \__ ____/  U \_______/
             access rights  access id

X - don't care (it looks like)
T - page reference trap
D - dirty
B - break
U - uncacheable

access rights is

 5  6  7  8  9 10 11
\______/ \___/ \___/
type      PL1   PL2

000: read-only
001: read-write
010: read-execute
011: read-write-execute
100: promote to PL 0.
101: promote to PL 1.
110: promote to PL 2.
111: remain at PL 3.

we don't need the B and T bits.  We don't need access types 101, 110, 111.  We only
need one bit for bits 8 .. 11 (they are either all 1 or all 0, so we can do an extrs).

We do need a "referenced" bit (not sure whether the dirty bit can do that for us more
efficiently) and a "valid" bit in addition to what the hardware gets to see.

So, I am just thinking of what the reason was we cannot just store bits 1 .. 12 in the
12 LSBs of the PTE, use bit 1 as a valid bit and be happy.  I am pretty sure there was
one.

> Anyway, I'm after a spare bit in the pte for _PAGE_GATEWAY.  As I
> understand it (from the mk_pte() macro), there are 12 bits available,
> only 8 of which are used, so I can nobble one of them to mark a page
> as being a gateway, right?

I would rather see a completely rewritten TLB insertion handler and either saving a
7-bit access rights field or a "I am special" bit / bit pattern.  The idea behind that
is it is used to re-insert BTLB entries / large mappings so we don't fault for every
single page and gateway pages would fit nicely into that.

	Philipp Rumpf

Re: [parisc-linux] pgtable.h:acc_rights()

[Thomas Bogendoerfer]

On Sat, Nov 06, 1999 at 08:51:25PM +0100, Philipp Rumpf wrote:
> > Why is acc_rights written like this?
> 
> See my commit message.  Basically that works around the "pages mapped
>  read-only when they should be read-write" problem Thomas reported.

the real problem is, that we don't have a working copy on write at the 
moment. So whenever the first access to COW page is a read access, every
write access afterwards will lead to an unhandled page fault (which causes
a panic at the moment). 

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: [parisc-linux] pgtable.h:acc_rights()

[Philipp Rumpf]

> the real problem is, that we don't have a working copy on write at the 
> moment. So whenever the first access to COW page is a read access, every
> write access afterwards will lead to an unhandled page fault (which causes
> a panic at the moment). 

Actually, there is some code there to explain this.  I never realized we did 
differentiate between read/write accesses and thought we were still hardcoding
a write access.  This shouldn't be too difficult to work around.

	Philipp Rumpf