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
