|Re: [hatari-devel] 030 exceptions on auto-increment instructions|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 4/13/19 4:13 PM, Toni Wilen wrote:
While mailing about some issue I was hitting with m68k Linux, it
was noticed that Linux fault handler gives different register
values under Hatari than under real 030.
Faulting instruction is:
$00249f5a : 0e98 2000 moves.l (a0)+,d2
A0 reg content is struct member offset address, but struct was NULL.
Under Hatari Falcon emulation, Linux fault handler reg dump showed A0
value to be 0x04, whereas with under real 030 Mac it showed 0x08.
I guess this means CPU does increment (and pre-decrement, possibly even
flags are partially set at this point depending on instruction) before
MMU detects the fault and because MMU is not fully integrated to CPU
(like in 68040+. 68030 is basically 68020+68851+data cache integrated in
single package with reduced 68851 instruction set), it is MMU's task to
handle the exception logic which means there is only fault address that
needs to be known (source of address is irrelevant at this point) and
CPU only needs to know where to continue execution after RTE. 68030
continues after MMU fault, 68040+ restarts.
Current emulation can't handle this because whole instruction is retried
(with already executed memory writes skipped and already executed reads
returning "cached" values to simulate continuation). Most likely new
"68030 MMU continuation" CPU core would be needed to fully emulate this
Fortunately this is undocumented behavior so no "normal" program should
care except perhaps some debugger like programs.
Linux seems to rely in some kernel functions on page fault ignoring,
for example in kernel_probe_read(). E.g. in SysRq task list and when
accessing content coming from user-space to kernel side.
Unfortunately this issue is encountered pretty often, because both
user-space data transfer and probe reads operate on multiple bytes
(where it's natural to use auto-increment instructions), and for some
reason they often access unmapped memory.
I'm currently suspecting that it's not just issue with emulated kernel
Oops debug output, but a cause of some of those oopses when user-space
<-> kernel transition is done.
Haven't you encountered this issue when you tested Linux with WinUAE?