Setting NO_FAULT in the mem flags should be all you need to do for a prefetch. This is how software prefetch instructions work on Alpha (or at least worked at some point in the past). If something in a CPU model is not handling NO_FAULT properly, then I'd say that's your bug.
Steve On Fri, Oct 16, 2009 at 11:47 PM, Gabe Black <[email protected]> wrote: > 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 >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
