> So wouldn't a functional table walker be basically be the same as an > atomic-mode one?
I guess I was envisioning a single walker that can handle each type of access. Walker::start handles both timing and atomic accesses currently, but the way it updates state could be trouble for atomic (and functional) accesses that are interleaved with timing accesses: For example, the state assertion at the entrance would fail in the (extremely unlikely) corner case where the MemoryMode was switched from timing to atomic (or functional) while a timing access was in flight (i.e. state != Ready). The ability to interleave timing and functional accesses is going to be necessary eventually, so sorting it out here would make sense. > Also, note that in functional mode you don't want to change visible > system state, so you don't want to update the access bits. For the readfile problem, I hacked vtophys to just do a lookup in the TLBs, and it solved the address translation problem (quick solution so I can continue with further tests). The TLB lookup function supports accesses that don't update LRU bits, so I was thinking the same principle could be applied to the walker state. (I haven't dug into a lot of the code, so I'm not sure if thats a common or agreed upon convention) On Thu, Jul 1, 2010 at 11:43 AM, Steve Reinhardt <ste...@gmail.com> wrote: > So wouldn't a functional table walker be basically be the same as an > atomic-mode one? I'd think it's only the timing-mode version that > really needs all the explicit state. That is, if you were going to > have two versions, I'd think you'd have a functional/atomic one and a > timing one, not a functional one and an atomic/timing one (which is I > believe what you're advocating, since the current one seems to already > handle both atomic and timing modes). > > Also, note that in functional mode you don't want to change visible > system state, so you don't want to update the access bits. I believe > that also means it's OK to bypass the TLB as well, right? (You still > might want to check the TLB if you think there's a good chance you'll > get a hit there, but the question is whether it's necessary for > correctness.) > > Steve > > On Thu, Jul 1, 2010 at 11:19 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: > > Yeah, I skipped implementing that so far. The reason the table walker is > > the way it is is that it needs to actually cooperate with the memory > > system and do real loads/stores, honor timing, etc. For functional > > accesses you should be able to write a simpler implementation that just > > uses its own functional accesses to read from the page tables in memory > > (and write to update the access bits, etc.). You should be careful, > > though, since the TLB acts like a cache and you'll need to check there > > first and not just always go straight to the in memory tables. There'll > > be a little duplication (which might be factored out into utility > > functions) but the page table walker sim object isn't really the right > > tool for this job. > > > > Gabe > > > > Joel Hestness wrote: > >> Hi, > >> It turns out that the readfile bug I posted previously (see below) > >> is a result of an unimplemented vtophys function: CopyIn reads the > >> file in, but the virtual address where it should be placed is not > >> translated to a physical address before sendFunctional is called. > >> This results in a BadAddressError and the packets are dropped. > >> > >> So, I've started looking at the vtophys function. It looks like it > >> will be trickier to implement than it was for prior architectures > >> because of the page table hardware organization and walker. I think > >> vtophys should be implemented by making a functional access to the > >> page table walker. The only problem is that the state machine > >> controlling the walker is updated in each of the access functions. I > >> see a couple possible solutions: > >> > >> 1. vtophys uses a separate walker to look up the entry. The walker > >> could be dynamically instantiated when needed, or it could be saved as > >> a system object specifically for functional accesses. This option > >> seems pretty hacky. > >> > >> 2. vtophys uses the ITB or DTB walker to look up the entry. This > >> would require functional access to the walker so as to not upset its > >> current state. Walker::start would need to take the desired memory > >> mode, and in the case of a functional access, it would need to make > >> sure that it doesn't perturb the current state. This looks like a > >> much better solution to me. > >> > >> I am wondering if anyone has feedback on a choice here, or if there is > >> maybe a better solution. I'd be willing to take a stab at the updates. > >> > >> Thanks, > >> Joel > >> > >> > >> On Mon, Jun 28, 2010 at 4:19 PM, nathan binkert <n...@binkert.org > >> <mailto:n...@binkert.org>> wrote: > >> > >> > This is probably a question for Nate, Gabe or Ali: > >> > I have built the m5 util application for x86 and I have been > >> testing it > >> > under X86_FS simulation. It looks like /sbin/m5 readfile is > >> failing to > >> > print the script to the console of the simulated system. I have > >> been able > >> > to verify that the pseudo instruction executes correctly, and the > >> > appropriate function (PseudoInst::readfile) in the simulator is > >> called with > >> > the correct parameters. There, the file is read into M5s > >> memory, but it > >> > isn't ever printed to the terminal in the simulated system. > >> > Call graph: PseudoInst::readfile -> VirtualPort::CopyIn > >> > -> VirtualPort::writeBlob -> Port::writeBlob -> Port::blobHelper > >> > At that point, blobHelper calls sendFunctional, to transfer > >> the contents > >> > of the file into the simulated system, but I'm having trouble > >> tracing where > >> > the packets end up. > >> > Any ideas on whats going on or how I can debug? > >> There is a mechanism for tracing packets through the system. > >> Basically, if you attach PrintReqState to the object, the system > will > >> print out info about the object moving through the memory system. > >> (Search old e-mails and perhaps the history to find out how it > really > >> works. I've never used it, Steve wrote it.) > >> > >> As for checking things. Did you try firing this up in the debugger > >> and then stepping over the CopyIn call to find out if it succeeded? > >> I'd try that to find out if there is something else wrong before you > >> dig through the memory system. > >> > >> Nate > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > >> > >> > >> > >> -- > >> Joel Hestness > >> PhD Student, Computer Architecture > >> Dept. of Computer Science, University of Texas - Austin > >> http://www.cs.utexas.edu/~hestness < > http://www.cs.utexas.edu/%7Ehestness> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
