Yes it has a thread id, but that isn't the problem I'm referring to.
In the case that you're taking two workloads from separate checkpoints
they will almost certainly have the same virtual addresses mapped to
some physical memory (their text and data sections, stack, heap, etc).
Right now the syscall emulation page table doesn't distinguish one
thread id from another as far as mapping virtual->physical addresses
goes.
Ali
How could this be possible? The SMT O3CPU on SE mode is able to run two
separate binaries, which could have the same virtual address. Isn't the
page table associated with each thread context? I am confused about how
this all working together.
I have been looking at the checkpoint information and it dawned on me
that maybe an outside script (perhaps in python), can go through the
page table entries, and associate each virtual address with a a unique
physical address. One might do this by first adding thread 1 cp0 state
to a new checkpoint file, then one adds thread 2's state, being careful
about the page table entry section. It should make sure that none of the
virtual addresses map to a physical address being used by thread 1.
Thus, I just have the script pick new unused physical address. I would
also need to rewrite the physmem file to have the right physical memory
locations. Does this sound like crazy talk or might this work?
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
