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
