Re: MIPS simulator is broken

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

On 30 Jan 2016 16:09, Maciej W. Rozycki wrote:
> > > mips-core: 4 byte read to unmapped address 0xffffffff80020004 at 0xffffffff80020004
> > > program stopped with signal 10 (User defined signal 1).
> > 
> > the mips address logic was fundamentally broken.  my changes merely
> > uncovered that braindeadness rather than caused it.  if you look at
> > that commit and the AddressTranslation definition, you'll see:
> >   /* For a simple (flat) memory model, we simply pass virtual
> >      addressess through (mostly) unchanged. */
> >   vAddr &= 0xFFFFFFFF;
> > 
> > this is forcing all addresses to be 32-bit.  when i saw this, i assumed
> > it was just a dummy function someone didn't get around to finishing.
> 
>  Not unreasonable unless you want to simulate gigabytes of memory (or a 
> TLB -- does the MIPS port of sim support it?).  Most programs run under 
> sim won't need that though.  There is a mistake there however, you really 
> want the mask to be 0x1FFFFFFF, to handle the architecture's 512MB KSEG0 
> and KSEG1 unmapped segments and their aliasing correctly -- some programs 
> rely on that.  Beyond that you need some more intelligence.

the sim uses a sparse memory map, so it doesn't need to fill the address
space.  it's pretty common for some arches to allocate maps at the top
(for things like hardware) while the low addresses have the RAM.  i don't
know much this applies to existing mips usage.

for this specific case, i don't see how the mask as implemented could ever
be correct.  it always threw away the top 32-bits, so when you try to use
any address above 0xffffffff, it'd be silently changed to the lower 32-bits.
playing with some n32 programs on a mips64 system shows that it often gets
maps created both above and below that point.  i don't see how chopping the
top bits could possibly yield correct behavior.

let me outline a few general points i think apply here:
i see the simulator core as a bunch of generic building blocks.  the arch port
itself only adds support for the ISA (insns & registers) to the equation.  once
you get beyond that (e.g. the memory or devices), now you're talking about more
building blocks than stuff that should be baked in/architecture defaults.  so
even if today all of the systems that have a mips cpu also wire up the system
mem in a specific way, the mips arch core should not be doing any of that.
this makes it very easy to take just the mips ISA and construct a new cpu from
scratch that has new/different behavior and play around with things.  when you
do want behavior that matches an existing board, that's where the model
framework comes into play.  you can define specific cpu/system combinations
that match existing products and users can pick those via the --model flag.

it is a little difficult currently to reconcile virtual-vs-physical behavior
in the sim as there is only a single physical map and no virt-to-phys trans.
we've just ignored this so far and said virtual==physical.  which is why the
sim throws an error when you try to put a virtual 0xffffffff80000000 address
onto the physical bus.

since 64-bit address aren't actually being used in the 32-bit env, why bother
using them ?  seems like it'd be much easier to just use 32-bit addresses and
be done.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]