From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-21 16:21:55
On Thu, Apr 21, 2005 at 01:36:54PM +0200, Gábor Lénárt wrote:
> > With the 65816 this is another story; here we have the ABORT input that
> > breaks off the momentary instruction.
>
> But this NMI generation scheme is enough to stop the execution
> of the "bad guy" process at least. OS then kill the process. Handling
> the problem like installing signal handler for segmenation fault is not
> a possible solution because hardware can't give information about the
> fault itself (where? why?) just the fact that there was SOME fault.
I've just discovered the following problem. Let's inmagine you have
the following instruction:
STA $C023
Let's inmagine that opcode of STA is at address $67FF, while $23 (low byte
of address $C023) is at $6800 and $C0 is at $6801. Now, we have per page
protection machanism with page size of 256. If page $67 is readable by the
given process, but page $68 is NOT, we have a serious problem. Let me
explain. CPU will fetch STA opcode from $67FF, no prob, but it continue at
$6800 and $6801 which are on page $68! This is not readble, so fault is
emitted by requesting NMI. However CPU can't be interrupted till the end of
the insruction. As we've discussed before, in case of READ protection,
memory is not read and eg some dummy value (like always zero) is read. So
CPU will get "STA $0000" to execute! CPU *WILL* take NMI as fault, but only
after doing an operation which is NEVER wanted by the programmer!
It can be solved anyway. In case of fault, a FlipFlop (FF for short) should
be set. Any further memory operation (either read/write) should be ignore
by the MMU if that FF is set! In this way, we isolates CPU from the memory
after a fault, to be sure that it will not corrupt a bogus memory locaton.
The only task left is to clear that FF after the opcode when the NMI taken,
as fault handler.
This sounds quite complex but I've found a solution for this: as we have
several possible mappings in MMU (well, mapping 6502 "pages" to physical ones,
and page protection should be stored as well!) and we have select a given
table to use, we can have a mapping just for 'after fault' and another for
'fault handler'. After fault, mmu set itself to use the 'after fault' table,
which would map everything to a non-existent physical location for example (so
we won't overwrite some locations like I've described a situation for this
as an exmple before). However, since NMI is taken after executing the opcode,
this should alter mmu pagetable selection again, to use the mapping suitable
get NMI vector then executing the code for it and such. Also, the fault
handler SHOULD know the table selection which was in use when page fault
occured.
Errrrrrrrrrrrr, what a mess at the end ;-) I think I've started to really
overcomplicate the whole design :)
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.