Re: [hatari-devel] 030 exceptions on auto-increment instructions

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Toni,

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
> behavior.
>
> 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?


	- Eero