My opinion is that a prefetch should abort on any fault it encounters. So if a prefetch fails translation it should become a nop at that point. I don't know how the x86 hardware table walker plays into that though. Although it appears as though all of the flags are never checked. Once the request reaches the memory system it doesn't need to be checked anymore, the memory system will return a BadAddr. So it's just a question of the translation and the CPU. My thoughts are if translate() on a request returns a fault and isPrefetch() then ignore and move on, same for the BadAddr on the actual request.
Ali On Oct 18, 2009, at 4:16 PM, Gabe Black wrote: > Thinking about this more, it also seems that NO_FAULT doesn't quite > capture what a prefetch is. If you're doing a load that shouldn't > fault > but still (assuming it worked) return data, that's different from a > prefetch that doesn't return anything. In one case you'd potentially > block execution, and the other you wouldn't. So my question to the > memory guys is, do we care? Which flags do we actually want? How > should > they work within the CPU as far as how far faults get, etc? > > Gabe > > Gabe Black wrote: >> It seems like we have three flags that all look like they should work >> but don't really seem to do anything. There's PREFETCH, PF_EXCLUSIVE, >> and NO_FAULT. The two prefetch flags aren't actually used by anything >> except x86 (I assumed they actually did something) and what looks >> like >> an Alpha floating point instruction. Alpha uses PF_EXCLUSIVE, but >> that >> flag isn't checked by isPrefetch(). They are never checked by >> anything >> outside of the ISAs themselves. The NO_FAULT flag is checked in >> alpha to >> decide whether to latch values into registers inside an invoke >> function >> for a fault, but that's at the point a fault is being serviced. >> Nothing >> prevents the fault from happening, and nothing outside of that >> function >> checks if it's set. >> >> Gabe >> >> Steve Reinhardt wrote: >> >>> 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] >>> <mailto:[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] <mailto:[email protected]> >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] <mailto:[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 >> > > _______________________________________________ > 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
