Hi Everyone,
I was just running some experiments on gem5's x86 and ran into a strange
TLB bug. The problem seems to be a strange interaction between microcode
that overrides address sizes and some assumptions in the TLB. In
summary, this is what happened:
* Sets up the 32-bit binary and starts executing it by doing an IRET to
the start address.
* The CPU is now in 32-bit mode.
* The page containing the start address hasn't been loaded yet, so the
CPU page faults.
* One of the microcode helper routines in arch/x86/isa/insts/romutil.py
executes and tries to load the IDT using a load microop with an address
size override.
* The TLB looks up the translation for the IDT location. But, since the
CPU is in compatibility mode, the TLB masks off the high 32-bits of the
address (tlb.cc:332), resulting in an assertion failure on tlb.cc:347.
I don't a good solution for this. Disabling the masking works for my
test case, but is bound to break something something to do with real
mode. Juding from Gabe's comments (97f06a79b6f5) and the change itself,
it /seems/ like moving the masking to the TLB has to do with cases where
the CPU uses a 16-bit offset but has a 32-bit segment base address
(Unreal Mode).
The easiest solution out of this is probably to check for 64-bit address
size overrides and set a magic memory access flag that prevents masking.
It's a bit ugly, but it should solve the issue. A better would be to
revamp the whole address masking thing and move that to the EA
calculation in the microop.
Comments/Ideas anyone?
//Andreas
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
