I've looked into this more, and there are several problems. First, the X86 TLB wasn't considering whether an access was a prefetch before panicing on a fault. Second, it's error message would always indicate an instruction translation even if it wasn't. Third, the CPUs make no attempt to handle prefetches any differently than any other access. In the atomic CPU, any resulting fault from translation is passed back to the instruction. X86's microop knows to ignore faults on prefetches. In the timing CPU, the fault is handled by the CPU directly since it gets passed around by callbacks, so it isn't ignored like it should be. An alternative to faulting and the fault being ignored is to always return NoFault on prefetches, but apparently something else is surprised by an address neither faulting nor being translated and segfaults.
In order to get this to work, I could either completely ignore prefetches, or I could go fix them in the CPUs. The first seems like a step backwards, but the later might be a pain in the more complicated models. Also, what is our model going to be for misbehaving prefetches? Do they just return like nothing happened, complicating logic downstream? Do they return a fault that gets squelched if the access was a prefetch? I think the later has a better chance of avoiding subtle issues. Gabe Vince Weaver wrote: > On Fri, 16 Oct 2009, Gabe Black wrote: > > >> This problem is likely either that prefetches don't mark themselves as >> such, or that they do and it gets lost somewhere. >> > > It is marked as such in > arch/x86/isa/insts/general_purpose/cache_and_memory_management.py > But I can't see how > build/X86_SE/arch/x86/insts/microldstop.hh > handles it (that might not be the best place to look, but I'm relying on > grep). > > >> I'll look at this >> tonight. Could you throw together a simple program that demonstrates the >> problem quickly? >> > > There should have been one attached the previous e-mail. Attaching it > again. If it isn't getting through, I can post in on a website. > > Vince > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
