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> 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 > 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
