Quoting Steve Reinhardt <[email protected]>:
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. 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?
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.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
