Re: [f-cpu] tlb last ! (secure bit, lib ring)

["Christophe Avoinne" <christophe.avoinne@laposte.net>]

Hi,

I'm confused.

Sometimes I wonder if we are not mixing hardware and software TLB notions
when speaking.

Software TLB :

It has very few valid entries. In fact it doesn't contain all the valid
mapping of a space address. So I don't understand why we need user or extra
bits since entries in TLB cannot be obviously persistent !!! it doesn't make
sense for TLB to have invalid entries or of other kind, because it is not up
to the TLB to handle the rest of entries but to a software dedicated to
virtual memory [dixit Cédric ]. So my oppinion is that user or extra bits
has no interest to be in TLB entries since they should be in fact handled by
the software, not by the TLB.

If I take the example of SH3, it has two TLBs, one for ICACHE, another for
DCACHE. A valid entry in TLB associated with ICACHE has only X bit
(equivalent to R bit for data) because the instruction fetcher never writes
data. A valid entry in TLB associated with DCACHE has R and W bits, but not
X bit because the data fetcher never executes an instruction. So if you
intend to have a seperate TLB for ICACHE and DCACHE, it makes no sense to
have a different bit for X and R IN THE TLB ENTRY.

You want a general R,W,X with U/S pairing. Okay, but I still don't
understand because it is up to the software to handle them and not to TLB.

Take this example :

One instruction raises a page fault exception. Ok, we know it is for a code
page and not a data page, so we must deal with TLB for ICACHE (ITLB). Now
our software dedicated to virtual memory tells us this faulty address is
associated with a physical address and has UX bit set to 1 and SX to 0. Okay
set UX to 1 and SX to 0 in the new ITLB entry, regardless with UR,UW,SR,SW
since they are no interest for ITLB.

One data read access raises a page fault exception. Ok, we know it is for a
data page and not a code page, so we must deal with TLB for DCACHE (DTLB).
Now our software dedicated to virtual memory tells us this faulty address is
associated with a physical address and has UR,UW,SR and SW set to 1,0,1 and
1. okay, set UR,UW,SR and SW to 1,0,1 and 1  in the new DTLB entry,
regardless with UX and SX.

So my opinion is that :
- from the viewpoint of software dedicated to virtual memory we have 6 bits
to handle : ur,uw,ux,sr,sw,sx. But the programmer can choose the way to
represent them since it is not a hardware point.
- from the viewpoint of ITLB (TLB for ICACHE) we have only 2 bits to handle
: ux,sx. They can be fix at the same bit position than ur,sr for DTLB
entries, since ur,sr,sr,sw are absent for ITLB.
- from the viewpoint of DTLB (TLB for DCACHE) we have only 4 bits to handle
: ur,uw,sr,sw.




*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/