On Oct 30, 2007, at 7:51 PM, Rick Strong wrote:
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.
You're right, it's associated with the process. I forgot that.
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?
This might work. You would need to see how much physical memory has
been already allocated (page_ptr in [system] section) in cpt0 and
then allocate the next n pages from cpt1, and copy over the memory.
You would then need to swizzle all the physical addresses adding that
offset (page_ptr * page_size) + old physical address.
Ali
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
