[m5-dev] X86_FS vtophys implementation
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
Re: [m5-dev] X86_FS vtophys implementation
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
Re: [m5-dev] X86_FS vtophys implementation
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
Re: [m5-dev] X86_FS vtophys implementation
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
