On Thu, Jul 1, 2010 at 2:07 PM, Gabriel Michael Black <gbl...@eecs.umich.edu> wrote: > Quoting Steve Reinhardt <ste...@gmail.com>: > >> 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.) > > I expect a functional one would be simpler than the atomic one, but maybe > not.
I agree that functional would be even simpler than atomic... just that in terms of commonality, if you were going to combine two implementations but not all three, functional and atomic would be the most similar because the accesses are function calls and not split transactions. > Joel thinks there could be some issues too, although I'd need to look > into it more carefully. Would a functional one need to check access > permissions? Actually, what happens if, say, a page is cow-ed and we try to > write to it? A real write would work but we'd have to let the simulation run > to fix it up. > > As far as updating access bits, dirty bits, etc. It seems dangerous not to > do that as well. What happens if we write to a page but the OS doesn't know > it and doesn't update disk when the page is swapped out? I think we need to distinguish to uses of functional accesses: as substitutes for real accesses when we implement some magic functionality in the simulator, and for things like debugging where you want to get additional visibility into or control over the simulated system without perturbing it. I think you're right that in the former case it might be desirable to do the same PTE updates that the real accesses would do. However, I think that (1) that shouldn't be bundled into sendFunctional(), since that would unnecessarily complicate the latter case, and (2) even in the former case we can almost certainly get away without it. For example, in the current situation of readfile, I expect that the readfile program that runs in the simulator allocates some temporary buffer, calls the magic opcode to get the data, then writes the data to a file (or stdout?). So the only danger is if that tiny buffer gets swapped out during the very short runtime of the readfile program, something which I'd say is virtually impossible. And even if it is a concern, I'd say a better approach would be to add store instructions to the readfile program to touch the buffer and mark the pages dirty in the app before executing the magic opcode. (OK, there'd still be a microscopic race condition there, but in all practicality that just won't be a problem.) > And then finally as far as checking the TLB, I expect most of the time you > should be ok since it should reflect the underlying page tables, but the > fact that they might be different and it might be on purpose makes me > nervous. Then again, I think when there'd be a fault because of what's in > the TLB, the mapping is supposed to be pulled in from the page tables again > just to be sure. I'm pretty sure we don't model that behavior. I can't think of a legitimate situation where the TLB would differ from the page tables with the possible exception of permissions (which I just argued shouldn't matter) or perhaps the unlucky situation of doing a functional access in the middle of a TLB shootdown (though even there, I think the shootdown has to happen before the page table change, so you're probably OK). Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
