Hello Milkymisters,
I am about to implement the "page fault" part of the MMU which consists
in doing permission checking on page accesses.
Basically MMU should raise an exception if the CPU does a memory write
(resp. memory read) to a virtual address if the page is "read only"
(resp. "write only").
This allows things like Copy on Write, very useful for fork()
implementations using lazy physical page allocation.
This allows protection on memory sections as well (don't allow writing
to code section if there is no need to for instance, don't allow writing
to rodata sections as well)
In order not to jump in the wrong direction, I have a few design
questions to ask.
I would appreciate if one (or more :)) could comment on the questions I
ask in this e-mail.
For some questions I have put a few answer items when I had some idea on
how to do things, please comment those as well to tell me if it sounds
OK/OK but not efficient/Wrong.
Sorry in advance for the length of this email!
Here it is:
MMU exception vectors & handlers ideas :
Q1 - 1 or 2 exception vectors for TLB miss?
- if 1 we need a small hack in .restore_all_and_eret routine in order to
do EA -= 4 before eret if the miss source is DTLB
- if 2 no hack needed
Does this matter? I guess 1°) optimizes cache use...
Q2 - What about TLB faults?
How to give permissions on a page:
- giving a page the execution rights in the page tables =>
+ if the page generates an ITLB miss then we refill the ITLB with the
page frame number and let the program continue its execution. No need
for an "executable" bit in the ITLB, the simple fact of being in the
ITLB means it can be executed... If not, ITLB will generate a miss
exception which will allow us (the miss handler) to check if the PTE
(page table entry in the page table) has the execution right bit.
- giving a page the read rights in the page tables =>
+ we should update the DTLB line for this mapping with the correct
"read right bit" set (or doing it lazyly accepting that a page fault
could be a faulse positive because DTLB is out of sync with page table?)
+ if the page generates a DTLB miss for a READ operation we should
refill the DTLB line with the page frame number and the read/write right
bits according to the PTE (page table entry) content.
- giving a page the write rights in the page tables =>
+ we should update the DTLB line for this mapping with the correct
"write right bit" set (or doing it lazyly accepting that a page fault
could be a faulse positive because DTLB is out of sync with page table?)
+ if the page generates a DTLB miss for a WRITE operation we should
then refill the DTLB line with the page frame number and the read/write
right bits according to the PTE (page table entry) content.
Q3 - What could trigger a page fault?
- DTLB would generate a page fault exception for 2 reasons:
+ CPU does a READ operation on a page present in the DTLB but without
the "read permission bit" set
+ CPU does a WRITE operation on a page present in the DTLB but without
the "write permission bit" set
+ If the page is not in the TLB there is no page fault but a TLB miss.
Q4 - How to handle the page fault?
- Only 1 exception vector needed (only 1 source of exception: DTLB)
something like:
_page_fault_handler:
sw (sp+0), ra
addi ea, ea, -4
calli .save_all
calli page_fault_handler
bi .restore_all_and_eret
nop
nop
nop
- Check in the page tables of the Operating System if corresponding
memory access is allowed
+ if it is: then update DTLB line and we are done (this could happen
if we change the PTE right bits but do not update the DTLB)
+ if it is not: then this is a real page fault => kill process/Oops/etc
So we need to know in the page fault handler what was the memory
operation (at least read or write):
- Do it via the software?
+ reading the opcode at the address contained in the EA register?
- Do it via the hardware?
+ Using lower bits of BADADDR CSR register?
+ Using a new dedicated CSR register (that would waste an entire CSR
for just 2 bits)?
+ Using PSW CSR register?
Thank you for reading this far :)
Cheers,
--
Yann Sionneau
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
