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.