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.)
Maybe this should be a distinguished by read vs. write? Writes
necessarily perterb the system because they change data in it, but
reads can be totally silent. I think generally speaking you'd read
for debugging and write for fake behavior. You'd also read for fake
behavior, but I don't think that changes the argument much.
As a side note, SE avoids this source of complication, namely having
to make sure the simulated OS still works. In my mind this is a major
justification for keeping SE around (as I think most people intend
anyway). This doesn't necessarily preclude making it share more code
with FS, though, which may be a good idea.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
