[m5-dev] encumbered: these changes go with the changes I just pushed to m...
changeset 25ae7c9393d9 in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=25ae7c9393d9
summary: these changes go with the changes I just pushed to m5 re: registering
a context
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
eio/eio.cc |2 +-
diffs (21 lines):
diff -r e79d42d3f05e -r 25ae7c9393d9 eio/eio.cc
--- a/eio/eio.ccWed Nov 14 04:32:09 2007 -0800
+++ b/eio/eio.ccTue Nov 04 11:40:05 2008 -0500
@@ -633,14 +633,15 @@
Process::startup();
/* load initial state checkpoint */
-if (read_chkpt(threadContexts[0], eio_fd) != -1)
+if (read_chkpt(system-getThreadContext(contextIds[0]), eio_fd) != -1)
fatal(bad initial checkpoint in EIO file);
/* load checkpoint? */
if (chkpt_fd) {
Counter restore_icnt;
/* load the state image */
- restore_icnt = read_chkpt(threadContexts[0], chkpt_fd);
+ restore_icnt = read_chkpt(system-getThreadContext(contextIds[0]),
+chkpt_fd);
/* fast forward the baseline EIO trace to checkpoint location */
cprintf(sim: fast forwarding to instruction %d\n, restore_icnt);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: decouple eviction from insertion in the cache.
changeset 6ed48cba2217 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6ed48cba2217
description:
decouple eviction from insertion in the cache.
diffstat:
4 files changed, 6 insertions(+), 6 deletions(-)
src/mem/cache/tags/fa_lru.hh |2 +-
src/mem/cache/tags/iic.hh|2 +-
src/mem/cache/tags/lru.cc|2 +-
src/mem/cache/tags/lru.hh|6 +++---
diffs (196 lines):
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/cache_impl.hh Tue Nov 04 11:35:58 2008 -0500
@@ -319,6 +319,7 @@
incMissCount(pkt);
return false;
}
+tags-insertBlock(pkt-getAddr(), blk);
blk-status = BlkValid | BlkReadable;
}
std::memcpy(blk-data, pkt-getPtruint8_t(), blkSize);
@@ -879,7 +880,7 @@
typename CacheTagStore::BlkType*
CacheTagStore::allocateBlock(Addr addr, PacketList writebacks)
{
-BlkType *blk = tags-findReplacement(addr, writebacks);
+BlkType *blk = tags-findVictim(addr, writebacks);
if (blk-isValid()) {
Addr repl_addr = tags-regenerateBlkAddr(blk-tag, blk-set);
@@ -890,6 +891,7 @@
assert(!blk-isWritable());
assert(repl_mshr-needsExclusive());
// too hard to replace block with transient state
+// allocation failed, block not inserted
return NULL;
} else {
DPRINTF(Cache, replacement: replacing %x with %x: %s\n,
@@ -903,8 +905,6 @@
}
}
-// Set tag for new block. Caller is responsible for setting status.
-blk-tag = tags-extractTag(addr);
return blk;
}
@@ -937,6 +937,8 @@
tempBlock-set = tags-extractSet(addr);
tempBlock-tag = tags-extractTag(addr);
DPRINTF(Cache, using temp block for %x\n, addr);
+} else {
+tags-insertBlock(addr, blk);
}
} else {
// existing block... probably an upgrade
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/tags/fa_lru.cc
--- a/src/mem/cache/tags/fa_lru.cc Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/tags/fa_lru.cc Tue Nov 04 11:35:58 2008 -0500
@@ -207,7 +207,7 @@
}
FALRUBlk*
-FALRU::findReplacement(Addr addr, PacketList writebacks)
+FALRU::findVictim(Addr addr, PacketList writebacks)
{
FALRUBlk * blk = tail;
assert(blk-inCache == 0);
@@ -226,6 +226,11 @@
}
//assert(check());
return blk;
+}
+
+void
+FALRU::insertBlock(Addr addr, FALRU::BlkType *blk)
+{
}
void
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/tags/fa_lru.hh
--- a/src/mem/cache/tags/fa_lru.hh Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/tags/fa_lru.hh Tue Nov 04 11:35:58 2008 -0500
@@ -197,7 +197,9 @@
* @param writebacks List for any writebacks to be performed.
* @return The block to place the replacement in.
*/
-FALRUBlk* findReplacement(Addr addr, PacketList writebacks);
+FALRUBlk* findVictim(Addr addr, PacketList writebacks);
+
+void insertBlock(Addr addr, BlkType *blk);
/**
* Return the hit latency of this cache.
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/tags/iic.cc
--- a/src/mem/cache/tags/iic.cc Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/tags/iic.cc Tue Nov 04 11:35:58 2008 -0500
@@ -297,7 +297,7 @@
IICTag*
-IIC::findReplacement(Addr addr, PacketList writebacks)
+IIC::findVictim(Addr addr, PacketList writebacks)
{
DPRINTF(IIC, Finding Replacement for %x\n, addr);
unsigned set = hash(addr);
@@ -337,6 +337,11 @@
tag_ptr-re = (void*)repl-add(tag_ptr-tagStore);
return tag_ptr;
+}
+
+void
+IIC::insertBlock(Addr addr, BlkType* blk)
+{
}
void
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/tags/iic.hh
--- a/src/mem/cache/tags/iic.hh Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/tags/iic.hh Tue Nov 04 11:35:58 2008 -0500
@@ -435,7 +435,9 @@
* @param writebacks List for any writebacks to be performed.
* @return The block to place the replacement in.
*/
-IICTag* findReplacement(Addr addr, PacketList writebacks);
+IICTag* findVictim(Addr addr, PacketList writebacks);
+
+void insertBlock(Addr addr, BlkType *blk);
/**
* Read the data from the internal storage of the given cache block.
diff -r ee56bb539212 -r 6ed48cba2217 src/mem/cache/tags/lru.cc
--- a/src/mem/cache/tags/lru.cc Tue Nov 04 11:35:57 2008 -0500
+++ b/src/mem/cache/tags/lru.cc Tue Nov 04 11:35:58 2008 -0500
@@ -183,12 +183,11 @@
}
LRUBlk*
-LRU::findReplacement(Addr addr, PacketList writebacks)
+LRU::findVictim(Addr addr, PacketList writebacks)
{
unsigned set = extractSet(addr);
// grab a replacement candidate
LRUBlk *blk = sets[set].blks[assoc-1];
-sets[set].moveToHead(blk);
if (blk-isValid()) {
replacements[0]++;
totalRefs += blk-refCount;
@@ -197,7 +196,14 @@
[m5-dev] changeset in m5: Add in Context IDs to the simulator. From now ...
changeset 76abee886def in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=76abee886def
description:
Add in Context IDs to the simulator. From now on, cpuId is almost
never used,
the primary identifier for a hardware context should be contextId().
The
concept of threads within a CPU remains, in the form of threadId()
because
sometimes you need to know which context within a cpu to manipulate.
diffstat:
23 files changed, 29 insertions(+), 24 deletions(-)
src/arch/alpha/locked_mem.hh |2 +-
src/arch/mips/locked_mem.hh |2 +-
src/arch/sparc/ua2005.cc |2 +-
src/cpu/base.cc |2 +-
src/cpu/base_dyn_inst.hh |1 +
src/cpu/checker/cpu_impl.hh |1 -
src/cpu/o3/cpu.cc|1 -
src/cpu/o3/thread_context.hh |2 ++
src/cpu/simple_thread.cc |1 +
src/cpu/thread_context.cc|2 ++
src/cpu/thread_context.hh|3 +++
src/cpu/thread_state.hh |2 ++
src/dev/alpha/tsunami_cchip.cc |4 +++-
src/mem/cache/blk.hh |3 +--
src/mem/cache/prefetch/base.cc |1 -
src/mem/cache/prefetch/ghb.cc|4 ++--
src/mem/cache/prefetch/ghb.hh|2 +-
src/mem/cache/prefetch/stride.cc |4 ++--
src/mem/cache/prefetch/stride.hh |2 +-
src/mem/physical.cc |4 ++--
src/mem/physical.hh |3 +--
src/mem/request.hh |3 ---
src/sim/system.hh|2 +-
diffs (truncated from 848 to 300 lines):
diff -r 993c7952b930 -r 76abee886def src/arch/alpha/locked_mem.hh
--- a/src/arch/alpha/locked_mem.hh Sun Nov 02 21:57:06 2008 -0500
+++ b/src/arch/alpha/locked_mem.hh Sun Nov 02 21:57:07 2008 -0500
@@ -85,9 +85,9 @@
stCondFailures++;
xc-setStCondFailures(stCondFailures);
if (stCondFailures % 10 == 0) {
-warn(cpu %d: %d consecutive
+warn(context %d: %d consecutive
store conditional failures\n,
- xc-cpuId(), stCondFailures);
+ xc-contextId(), stCondFailures);
}
// store conditional failed already, so don't issue it to mem
diff -r 993c7952b930 -r 76abee886def src/arch/mips/locked_mem.hh
--- a/src/arch/mips/locked_mem.hh Sun Nov 02 21:57:06 2008 -0500
+++ b/src/arch/mips/locked_mem.hh Sun Nov 02 21:57:07 2008 -0500
@@ -83,9 +83,9 @@
stCondFailures++;
xc-setStCondFailures(stCondFailures);
if (stCondFailures % 10 == 0) {
-warn(%i: cpu %d: %d consecutive
+warn(%i: context %d: %d consecutive
store conditional failures\n,
- curTick, xc-cpuId(), stCondFailures);
+ curTick, xc-contextId(), stCondFailures);
}
if (stCondFailures == 5000) {
diff -r 993c7952b930 -r 76abee886def src/arch/sparc/ua2005.cc
--- a/src/arch/sparc/ua2005.cc Sun Nov 02 21:57:06 2008 -0500
+++ b/src/arch/sparc/ua2005.cc Sun Nov 02 21:57:07 2008 -0500
@@ -257,11 +257,11 @@
temp = readRegNoEffect(miscReg) (STS::active | STS::speculative);
// Check that the CPU array is fully populated
// (by calling getNumCPus())
-assert(sys-getNumCPUs() tc-cpuId());
+assert(sys-getNumContexts() tc-contextId());
-temp |= tc-cpuId() STS::shft_id;
+temp |= tc-contextId() STS::shft_id;
-for (x = tc-cpuId() ~3; x sys-threadContexts.size(); x++) {
+for (x = tc-contextId() ~3; x sys-threadContexts.size(); x++) {
switch (sys-threadContexts[x]-status()) {
case ThreadContext::Active:
temp |= STS::st_run (STS::shft_fsm0 -
diff -r 993c7952b930 -r 76abee886def src/arch/x86/tlb.cc
--- a/src/arch/x86/tlb.cc Sun Nov 02 21:57:06 2008 -0500
+++ b/src/arch/x86/tlb.cc Sun Nov 02 21:57:07 2008 -0500
@@ -654,7 +654,7 @@
*/
// Force the access to be uncacheable.
req-setFlags(req-getFlags() | UNCACHEABLE);
-req-setPaddr(x86LocalAPICAddress(tc-cpuId(), paddr - baseAddr));
+req-setPaddr(x86LocalAPICAddress(tc-contextId(), paddr - baseAddr));
}
#endif
return NoFault;
diff -r 993c7952b930 -r 76abee886def src/cpu/base.cc
--- a/src/cpu/base.cc Sun Nov 02 21:57:06 2008 -0500
+++ b/src/cpu/base.cc Sun Nov 02 21:57:07 2008 -0500
@@ -285,9 +285,9 @@
for (int i = 0; i threadContexts.size(); ++i) {
ThreadContext *tc = threadContexts[i];
-system-registerThreadContext(tc);
+tc-setContextId(system-registerThreadContext(tc));
#if !FULL_SYSTEM
-tc-getProcessPtr()-assignThreadContext(tc-cpuId());
+tc-getProcessPtr()-assignThreadContext(tc-contextId());
#endif
}
}
@@ -328,8 +328,8 @@
CpuEvent::replaceThreadContext(oldTC, newTC);
-assert(newTC-cpuId() ==
[m5-dev] changeset in m5: get rid of all instances of readTid() and getTh...
changeset e8c1d4e669a7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e8c1d4e669a7
description:
get rid of all instances of readTid() and getThreadNum(). Unify and
eliminate
redundancies with threadId() as their replacement.
diffstat:
5 files changed, 5 insertions(+), 4 deletions(-)
src/cpu/o3/thread_context.hh |2 ++
src/cpu/simple_thread.hh |1 -
src/cpu/thread_context.hh|2 +-
src/cpu/thread_state.cc |2 +-
src/cpu/thread_state.hh |2 +-
diffs (truncated from 924 to 300 lines):
diff -r 76abee886def -r e8c1d4e669a7 src/arch/mips/isa/formats/mt.isa
--- a/src/arch/mips/isa/formats/mt.isa Sun Nov 02 21:57:07 2008 -0500
+++ b/src/arch/mips/isa/formats/mt.isa Tue Nov 04 11:35:42 2008 -0500
@@ -196,7 +196,7 @@
def format MT_MFTR(code, *flags) {{
flags += ('IsNonSpeculative', )
-#code = 'std::cerr curTick \: T\
xc-tcBase()-getThreadNum() \: Executing MT INST: ' + name + '\
endl;\n' + code
+#code = 'std::cerr curTick \: T\ xc-tcBase()-threadId()
\: Executing MT INST: ' + name + '\ endl;\n' + code
code += 'if (MT_H == 1) {\n'
code += 'data = bits(data, top_bit, bottom_bit);\n'
@@ -212,7 +212,7 @@
def format MT_MTTR(code, *flags) {{
flags += ('IsNonSpeculative', )
-#code = 'std::cerr curTick \: T\
xc-tcBase()-getThreadNum() \: Executing MT INST: ' + name + '\
endl;\n' + code
+#code = 'std::cerr curTick \: T\ xc-tcBase()-threadId()
\: Executing MT INST: ' + name + '\ endl;\n' + code
iop = InstObjParams(name, Name, 'MTOp', code, flags)
header_output = BasicDeclare.subst(iop)
decoder_output = BasicConstructor.subst(iop)
diff -r 76abee886def -r e8c1d4e669a7 src/arch/mips/locked_mem.hh
--- a/src/arch/mips/locked_mem.hh Sun Nov 02 21:57:07 2008 -0500
+++ b/src/arch/mips/locked_mem.hh Tue Nov 04 11:35:42 2008 -0500
@@ -52,7 +52,7 @@
xc-setMiscRegNoEffect(LLAddr, req-getPaddr() ~0xf);
xc-setMiscRegNoEffect(LLFlag, true);
DPRINTF(LLSC, [tid:%i]: Load-Link Flag Set Load-Link Address set to
%x.\n,
-req-getThreadNum(), req-getPaddr() ~0xf);
+req-threadId(), req-getPaddr() ~0xf);
}
@@ -94,10 +94,10 @@
if (!lock_flag){
DPRINTF(LLSC, [tid:%i]: Lock Flag Set, Store Conditional
Failed.\n,
-req-getThreadNum());
+req-threadId());
} else if ((req-getPaddr() ~0xf) != lock_addr) {
DPRINTF(LLSC, [tid:%i]: Load-Link Address Mismatch, Store
Conditional Failed.\n,
-req-getThreadNum());
+req-threadId());
}
// store conditional failed already, so don't issue it to mem
return false;
diff -r 76abee886def -r e8c1d4e669a7 src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Sun Nov 02 21:57:07 2008 -0500
+++ b/src/arch/mips/mt.hh Tue Nov 04 11:35:42 2008 -0500
@@ -78,7 +78,7 @@
// @TODO: Needs to check if this is a branch and if so, take previous
instruction
tc-setMiscReg(TCRestart, tc-readNextPC());
-warn(%i: Halting thread %i in %s @ PC %x, setting restart PC to %x,
curTick, tc-getThreadNum(), tc-getCpuPtr()-name(),
+warn(%i: Halting thread %i in %s @ PC %x, setting restart PC to %x,
curTick, tc-threadId(), tc-getCpuPtr()-name(),
tc-readPC(), tc-readNextPC());
}
}
@@ -98,7 +98,7 @@
tc-setNextNPC(pc + 8);
tc-activate(0);
-warn(%i: Restoring thread %i in %s @ PC %x, curTick,
tc-getThreadNum(), tc-getCpuPtr()-name(),
+warn(%i: Restoring thread %i in %s @ PC %x, curTick, tc-threadId(),
tc-getCpuPtr()-name(),
tc-readPC());
}
}
@@ -217,7 +217,7 @@
if (ok == 1) {
unsigned tcstatus = tc-readMiscRegNoEffect(TCStatus);
tc-setMiscReg(TCStatus, insertBits(tcstatus, TCS_A, TCS_A, 0));
-warn(%i: Deactivating Hardware Thread Context #%i, curTick,
tc-getThreadNum());
+warn(%i: Deactivating Hardware Thread Context #%i, curTick,
tc-threadId());
}
} else if (src_reg 0) {
if (src_reg !yield_mask != 0) {
@@ -238,7 +238,7 @@
fault = new ThreadFault();
} else {
//tc-ScheduleOtherThreads();
-//std::cerr T tc-getThreadNum() YIELD: Schedule Other
Threads.\n std::endl;
+//std::cerr T tc-threadId() YIELD: Schedule Other
Threads.\n std::endl;
//tc-suspend();
// Save last known PC in TCRestart
// @TODO: Needs to check if this is a branch and if so, take
previous instruction
diff -r 76abee886def -r e8c1d4e669a7 src/arch/mips/utility.cc
--- a/src/arch/mips/utility.cc Sun Nov 02 21:57:07 2008 -0500
+++ b/src/arch/mips/utility.cc Tue Nov 04 11:35:42 2008 -0500
@@ -259,7 +259,7 @@
void
[m5-dev] changeset in m5: Change the findBlock(addr, lat) to accessBlock, ...
changeset ee56bb539212 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ee56bb539212
description:
Change the findBlock(addr, lat) to accessBlock, which I think has
better connotations for what is really happening and how it should be used.
diffstat:
3 files changed, 11 insertions(+), 6 deletions(-)
src/mem/cache/tags/fa_lru.hh |6 --
src/mem/cache/tags/iic.hh|6 --
src/mem/cache/tags/lru.hh|5 +++--
diffs (121 lines):
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/cache_impl.hh Tue Nov 04 11:35:57 2008 -0500
@@ -269,7 +269,7 @@
return false;
}
-blk = tags-findBlock(pkt-getAddr(), lat);
+blk = tags-accessBlock(pkt-getAddr(), lat);
if (prefetchAccess) {
//We are determining prefetches on access stream, call prefetcher
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/fa_lru.cc
--- a/src/mem/cache/tags/fa_lru.cc Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/fa_lru.cc Tue Nov 04 11:35:57 2008 -0500
@@ -155,7 +155,7 @@
}
FALRUBlk*
-FALRU::findBlock(Addr addr, int lat, int *inCache)
+FALRU::accessBlock(Addr addr, int lat, int *inCache)
{
accesses++;
int tmp_in_cache = 0;
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/fa_lru.hh
--- a/src/mem/cache/tags/fa_lru.hh Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/fa_lru.hh Tue Nov 04 11:35:57 2008 -0500
@@ -171,15 +171,17 @@
void invalidateBlk(BlkType *blk);
/**
- * Find the block in the cache and update the replacement data. Returns
- * the access latency and the in cache flags as a side effect
+ * Access block and update replacement data. May not succeed, in which
case
+ * NULL pointer is returned. This has all the implications of a cache
+ * access and should only be used as such.
+ * Returns the access latency and inCache flags as a side effect.
* @param addr The address to look for.
* @param asid The address space ID.
* @param lat The latency of the access.
* @param inCache The FALRUBlk::inCache flags.
* @return Pointer to the cache block.
*/
-FALRUBlk* findBlock(Addr addr, int lat, int *inCache = 0);
+FALRUBlk* accessBlock(Addr addr, int lat, int *inCache = 0);
/**
* Find the block in the cache, do not update the replacement data.
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/iic.cc
--- a/src/mem/cache/tags/iic.cc Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/iic.cc Tue Nov 04 11:35:57 2008 -0500
@@ -221,7 +221,7 @@
IICTag*
-IIC::findBlock(Addr addr, int lat)
+IIC::accessBlock(Addr addr, int lat)
{
Addr tag = extractTag(addr);
unsigned set = hash(addr);
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/iic.hh
--- a/src/mem/cache/tags/iic.hh Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/iic.hh Tue Nov 04 11:35:57 2008 -0500
@@ -410,14 +410,16 @@
void invalidateBlk(BlkType *blk);
/**
- * Find the block and update the replacement data. This call also returns
- * the access latency as a side effect.
+ * Access block and update replacement data. May not succeed, in which
case
+ * NULL pointer is returned. This has all the implications of a cache
+ * access and should only be used as such.
+ * Returns the access latency and inCache flags as a side effect.
* @param addr The address to find.
* @param asid The address space ID.
* @param lat The access latency.
* @return A pointer to the block found, if any.
*/
-IICTag* findBlock(Addr addr, int lat);
+IICTag* accessBlock(Addr addr, int lat);
/**
* Find the block, do not update the replacement data.
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/lru.cc
--- a/src/mem/cache/tags/lru.cc Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/lru.cc Tue Nov 04 11:35:57 2008 -0500
@@ -151,7 +151,7 @@
}
LRUBlk*
-LRU::findBlock(Addr addr, int lat)
+LRU::accessBlock(Addr addr, int lat)
{
Addr tag = extractTag(addr);
unsigned set = extractSet(addr);
diff -r e8c1d4e669a7 -r ee56bb539212 src/mem/cache/tags/lru.hh
--- a/src/mem/cache/tags/lru.hh Tue Nov 04 11:35:42 2008 -0500
+++ b/src/mem/cache/tags/lru.hh Tue Nov 04 11:35:57 2008 -0500
@@ -160,17 +160,19 @@
void invalidateBlk(BlkType *blk);
/**
- * Finds the given address in the cache and update replacement data.
- * Returns the access latency as a side effect.
+ * Access block and update replacement data. May not succeed, in which
case
+ * NULL pointer is returned. This has all the implications of a cache
+ * access and should only be used as such. Returns the access latency as a
side effect.
* @param addr The address to find.
* @param asid The address space ID.
* @param lat The access latency.
[m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. See /z/m5/regression/regress-2008-11-04-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Make it so that all thread contexts are registe...
changeset 993c7952b930 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=993c7952b930
description:
Make it so that all thread contexts are registered with the System,
even in
SE. Process still keeps track of the tc's it owns, but registration
occurs
with the System, this eases the way for system-wide context Ids based on
registration.
diffstat:
8 files changed, 18 insertions(+), 30 deletions(-)
src/arch/alpha/process.cc |5 ++---
src/arch/sparc/process.cc | 11 +--
src/arch/x86/process.cc |1 -
src/cpu/base.cc |1 -
src/kern/tru64/tru64.hh |8
src/sim/process.cc| 17 +++--
src/sim/system.cc |3 ++-
src/sim/system.hh |2 ++
diffs (truncated from 432 to 300 lines):
diff -r 199d31b47f7b -r 993c7952b930 src/arch/alpha/process.cc
--- a/src/arch/alpha/process.cc Sun Nov 02 21:56:57 2008 -0500
+++ b/src/arch/alpha/process.cc Sun Nov 02 21:57:06 2008 -0500
@@ -67,12 +67,13 @@
argsInit(MachineBytes, VMPageSize);
-threadContexts[0]-setIntReg(GlobalPointerReg, objFile-globalPointer());
-//Opperate in user mode
-threadContexts[0]-setMiscRegNoEffect(IPR_ICM, 0x18);
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
+tc-setIntReg(GlobalPointerReg, objFile-globalPointer());
+//Operate in user mode
+tc-setMiscRegNoEffect(IPR_ICM, 0x18);
//No super page mapping
-threadContexts[0]-setMiscRegNoEffect(IPR_MCSR, 0);
+tc-setMiscRegNoEffect(IPR_MCSR, 0);
//Set this to 0 for now, but it should be unique for each process
-threadContexts[0]-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
+tc-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
}
diff -r 199d31b47f7b -r 993c7952b930 src/arch/sparc/process.cc
--- a/src/arch/sparc/process.cc Sun Nov 02 21:56:57 2008 -0500
+++ b/src/arch/sparc/process.cc Sun Nov 02 21:57:06 2008 -0500
@@ -112,44 +112,45 @@
{
Process::startup();
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
//From the SPARC ABI
//Setup default FP state
-threadContexts[0]-setMiscRegNoEffect(MISCREG_FSR, 0);
+tc-setMiscRegNoEffect(MISCREG_FSR, 0);
-threadContexts[0]-setMiscRegNoEffect(MISCREG_TICK, 0);
+tc-setMiscRegNoEffect(MISCREG_TICK, 0);
/*
* Register window management registers
*/
//No windows contain info from other programs
-//threadContexts[0]-setMiscRegNoEffect(MISCREG_OTHERWIN, 0);
-threadContexts[0]-setIntReg(NumIntArchRegs + 6, 0);
+//tc-setMiscRegNoEffect(MISCREG_OTHERWIN, 0);
+tc-setIntReg(NumIntArchRegs + 6, 0);
//There are no windows to pop
-//threadContexts[0]-setMiscRegNoEffect(MISCREG_CANRESTORE, 0);
-threadContexts[0]-setIntReg(NumIntArchRegs + 4, 0);
+//tc-setMiscRegNoEffect(MISCREG_CANRESTORE, 0);
+tc-setIntReg(NumIntArchRegs + 4, 0);
//All windows are available to save into
-//threadContexts[0]-setMiscRegNoEffect(MISCREG_CANSAVE, NWindows - 2);
-threadContexts[0]-setIntReg(NumIntArchRegs + 3, NWindows - 2);
+//tc-setMiscRegNoEffect(MISCREG_CANSAVE, NWindows - 2);
+tc-setIntReg(NumIntArchRegs + 3, NWindows - 2);
//All windows are clean
-//threadContexts[0]-setMiscRegNoEffect(MISCREG_CLEANWIN, NWindows);
-threadContexts[0]-setIntReg(NumIntArchRegs + 5, NWindows);
+//tc-setMiscRegNoEffect(MISCREG_CLEANWIN, NWindows);
+tc-setIntReg(NumIntArchRegs + 5, NWindows);
//Start with register window 0
-threadContexts[0]-setMiscRegNoEffect(MISCREG_CWP, 0);
+tc-setMiscRegNoEffect(MISCREG_CWP, 0);
//Always use spill and fill traps 0
-//threadContexts[0]-setMiscRegNoEffect(MISCREG_WSTATE, 0);
-threadContexts[0]-setIntReg(NumIntArchRegs + 7, 0);
+//tc-setMiscRegNoEffect(MISCREG_WSTATE, 0);
+tc-setIntReg(NumIntArchRegs + 7, 0);
//Set the trap level to 0
-threadContexts[0]-setMiscRegNoEffect(MISCREG_TL, 0);
+tc-setMiscRegNoEffect(MISCREG_TL, 0);
//Set the ASI register to something fixed
-threadContexts[0]-setMiscRegNoEffect(MISCREG_ASI, ASI_PRIMARY);
+tc-setMiscRegNoEffect(MISCREG_ASI, ASI_PRIMARY);
/*
* T1 specific registers
*/
//Turn on the icache, dcache, dtb translation, and itb translation.
-threadContexts[0]-setMiscRegNoEffect(MISCREG_MMU_LSU_CTRL, 15);
+tc-setMiscRegNoEffect(MISCREG_MMU_LSU_CTRL, 15);
}
void
@@ -160,8 +161,9 @@
SparcLiveProcess::startup();
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
//The process runs in user mode with 32 bit addresses
-threadContexts[0]-setMiscReg(MISCREG_PSTATE, 0x0a);
+tc-setMiscReg(MISCREG_PSTATE, 0x0a);
argsInit(32 / 8, VMPageSize);
}
@@ -174,8 +176,9 @@
SparcLiveProcess::startup();
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
//The process runs in user mode
-threadContexts[0]-setMiscReg(MISCREG_PSTATE, 0x02);
+
[m5-dev] CMP using EIO traces
Hey guys, I'm trying to run a timing CMP with caches using EIO traces, but the EIO can't seem to be run on multicore platforms, the 2nd cpu inevitably itb pagefaults continually on a single PC (presumably the first) and then dies. Is this a bug or a feature? Is there something I don't know about how EIO works that keeps it from working in a CMP environment? Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] CMP using EIO traces
It's definitely a bug... it used to work. I wonder if it has something to do with migrating towards a more realistic paging model for SE mode (though that happened quite a while ago---August 2007 according to hg---and if that was totally broken I'm surprised no one noticed it yet). I'd take a look at the Process and EioProcess objects and see if anything looks fishy in the way the address space mappings get set up (esp. compared to LiveProcess). 2008/11/4 Lisa Hsu [EMAIL PROTECTED]: Hey guys, I'm trying to run a timing CMP with caches using EIO traces, but the EIO can't seem to be run on multicore platforms, the 2nd cpu inevitably itb pagefaults continually on a single PC (presumably the first) and then dies. Is this a bug or a feature? Is there something I don't know about how EIO works that keeps it from working in a CMP environment? Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: make BaseCPU the provider of _cpuId, and cpuId(...
changeset 199d31b47f7b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=199d31b47f7b
description:
make BaseCPU the provider of _cpuId, and cpuId() instead of being
scattered
across the subclasses. generally make it so that member data is _cpuId
and
accessor functions are cpuId(). The ID val comes from the python
(default -1 if
none provided), and if it is -1, the index of cpuList will be given.
this has
passed util/regress quick and se.py -n4 and fs.py -n4 as well as
standard
switch.
diffstat:
12 files changed, 12 insertions(+), 19 deletions(-)
src/arch/sparc/ua2005.cc |2 +-
src/cpu/base.cc |5 +++--
src/cpu/base.hh |5 +
src/cpu/o3/cpu.hh|4
src/cpu/o3/thread_context.hh |2 --
src/cpu/ozone/cpu.hh |2 --
src/cpu/simple/atomic.cc |1 -
src/cpu/simple/timing.cc |1 -
src/cpu/thread_context.cc|1 -
src/cpu/thread_context.hh|1 -
src/cpu/thread_state.cc |4 ++--
src/sim/system.cc|3 +--
diffs (truncated from 719 to 300 lines):
diff -r 93eb7f618517 -r 199d31b47f7b src/arch/alpha/locked_mem.hh
--- a/src/arch/alpha/locked_mem.hh Tue Oct 28 21:13:21 2008 -0400
+++ b/src/arch/alpha/locked_mem.hh Sun Nov 02 21:56:57 2008 -0500
@@ -87,7 +87,7 @@
if (stCondFailures % 10 == 0) {
warn(cpu %d: %d consecutive
store conditional failures\n,
- xc-readCpuId(), stCondFailures);
+ xc-cpuId(), stCondFailures);
}
// store conditional failed already, so don't issue it to mem
diff -r 93eb7f618517 -r 199d31b47f7b src/arch/mips/locked_mem.hh
--- a/src/arch/mips/locked_mem.hh Tue Oct 28 21:13:21 2008 -0400
+++ b/src/arch/mips/locked_mem.hh Sun Nov 02 21:56:57 2008 -0500
@@ -85,7 +85,7 @@
if (stCondFailures % 10 == 0) {
warn(%i: cpu %d: %d consecutive
store conditional failures\n,
- curTick, xc-readCpuId(), stCondFailures);
+ curTick, xc-cpuId(), stCondFailures);
}
if (stCondFailures == 5000) {
diff -r 93eb7f618517 -r 199d31b47f7b src/arch/sparc/ua2005.cc
--- a/src/arch/sparc/ua2005.cc Tue Oct 28 21:13:21 2008 -0400
+++ b/src/arch/sparc/ua2005.cc Sun Nov 02 21:56:57 2008 -0500
@@ -257,11 +257,11 @@
temp = readRegNoEffect(miscReg) (STS::active | STS::speculative);
// Check that the CPU array is fully populated
// (by calling getNumCPus())
-assert(sys-getNumCPUs() tc-readCpuId());
+assert(sys-getNumCPUs() tc-cpuId());
-temp |= tc-readCpuId() STS::shft_id;
+temp |= tc-cpuId() STS::shft_id;
-for (x = tc-readCpuId() ~3; x sys-threadContexts.size(); x++) {
+for (x = tc-cpuId() ~3; x sys-threadContexts.size(); x++) {
switch (sys-threadContexts[x]-status()) {
case ThreadContext::Active:
temp |= STS::st_run (STS::shft_fsm0 -
diff -r 93eb7f618517 -r 199d31b47f7b src/arch/x86/tlb.cc
--- a/src/arch/x86/tlb.cc Tue Oct 28 21:13:21 2008 -0400
+++ b/src/arch/x86/tlb.cc Sun Nov 02 21:56:57 2008 -0500
@@ -654,7 +654,7 @@
*/
// Force the access to be uncacheable.
req-setFlags(req-getFlags() | UNCACHEABLE);
-req-setPaddr(x86LocalAPICAddress(tc-readCpuId(), paddr - baseAddr));
+req-setPaddr(x86LocalAPICAddress(tc-cpuId(), paddr - baseAddr));
}
#endif
return NoFault;
diff -r 93eb7f618517 -r 199d31b47f7b src/cpu/BaseCPU.py
--- a/src/cpu/BaseCPU.pyTue Oct 28 21:13:21 2008 -0400
+++ b/src/cpu/BaseCPU.pySun Nov 02 21:56:57 2008 -0500
@@ -63,7 +63,7 @@
abstract = True
system = Param.System(Parent.any, system object)
-cpu_id = Param.Int(CPU identifier)
+cpu_id = Param.Int(-1, CPU identifier)
numThreads = Param.Unsigned(1, number of HW thread contexts)
function_trace = Param.Bool(False, Enable function trace)
diff -r 93eb7f618517 -r 199d31b47f7b src/cpu/base.cc
--- a/src/cpu/base.cc Tue Oct 28 21:13:21 2008 -0400
+++ b/src/cpu/base.cc Sun Nov 02 21:56:57 2008 -0500
@@ -94,20 +94,28 @@
#if FULL_SYSTEM
BaseCPU::BaseCPU(Params *p)
-: MemObject(p), clock(p-clock), instCnt(0), interrupts(p-interrupts),
+: MemObject(p), clock(p-clock), instCnt(0), _cpuId(p-cpu_id),
+ interrupts(p-interrupts),
number_of_threads(p-numThreads), system(p-system),
phase(p-phase)
#else
BaseCPU::BaseCPU(Params *p)
-: MemObject(p), clock(p-clock),
+: MemObject(p), clock(p-clock), _cpuId(p-cpu_id),
number_of_threads(p-numThreads), system(p-system),
phase(p-phase)
#endif
{
//currentTick = curTick;
+// if Python did not provide a valid ID, do it here
+if (_cpuId == -1 ) {
+_cpuId = cpuList.size();
+
Re: [m5-dev] CMP using EIO traces
...and make a regression that catches the problem in the future. Every time we find a bug that isn't caught by a regression test I think we need to create a configuration that will catch it. In the future we'll never miss it again, and the new regression might catch other bugs that the current ones don't. Ali On Nov 4, 2008, at 4:31 PM, Steve Reinhardt wrote: It's definitely a bug... it used to work. I wonder if it has something to do with migrating towards a more realistic paging model for SE mode (though that happened quite a while ago---August 2007 according to hg---and if that was totally broken I'm surprised no one noticed it yet). I'd take a look at the Process and EioProcess objects and see if anything looks fishy in the way the address space mappings get set up (esp. compared to LiveProcess). 2008/11/4 Lisa Hsu [EMAIL PROTECTED]: Hey guys, I'm trying to run a timing CMP with caches using EIO traces, but the EIO can't seem to be run on multicore platforms, the 2nd cpu inevitably itb pagefaults continually on a single PC (presumably the first) and then dies. Is this a bug or a feature? Is there something I don't know about how EIO works that keeps it from working in a CMP environment? Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] CMP using EIO traces
I figured out what I need to do to make the regression suite more easily extensible. Yell at me if I don't actually do something to fix it within a week. Nate On Tue, Nov 4, 2008 at 1:44 PM, Ali Saidi [EMAIL PROTECTED] wrote: ...and make a regression that catches the problem in the future. Every time we find a bug that isn't caught by a regression test I think we need to create a configuration that will catch it. In the future we'll never miss it again, and the new regression might catch other bugs that the current ones don't. Ali On Nov 4, 2008, at 4:31 PM, Steve Reinhardt wrote: It's definitely a bug... it used to work. I wonder if it has something to do with migrating towards a more realistic paging model for SE mode (though that happened quite a while ago---August 2007 according to hg---and if that was totally broken I'm surprised no one noticed it yet). I'd take a look at the Process and EioProcess objects and see if anything looks fishy in the way the address space mappings get set up (esp. compared to LiveProcess). 2008/11/4 Lisa Hsu [EMAIL PROTECTED]: Hey guys, I'm trying to run a timing CMP with caches using EIO traces, but the EIO can't seem to be run on multicore platforms, the 2nd cpu inevitably itb pagefaults continually on a single PC (presumably the first) and then dies. Is this a bug or a feature? Is there something I don't know about how EIO works that keeps it from working in a CMP environment? Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] encumbered: fix multicore eio.
This might be a reasonable fix for the immediate term, but I don't think
eio is limited to Alpha. A more appropriate place for this is probably
in the EIO process object constructor.
Gabe
[EMAIL PROTECTED] wrote:
changeset 2c7b9d01d542 in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=2c7b9d01d542
summary: fix multicore eio.
diffstat:
0 files changed
diffs (25 lines):
diff -r 25ae7c9393d9 -r 2c7b9d01d542 eio/eio.cc
--- a/eio/eio.cc Tue Nov 04 11:40:05 2008 -0500
+++ b/eio/eio.cc Tue Nov 04 21:55:49 2008 -0500
@@ -71,6 +71,7 @@
// field name in eval.h.
#include eio/libexo.h
+using namespace AlphaISA;
using namespace std;
static struct {
@@ -650,6 +651,13 @@
eio_close(chkpt_fd);
chkpt_fd = NULL;
}
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
+//Operate in user mode
+tc-setMiscRegNoEffect(IPR_ICM, 0x18);
+//No super page mapping
+tc-setMiscRegNoEffect(IPR_MCSR, 0);
+//Set this to 0 for now, but it should be unique for each process
+tc-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] encumbered: fix multicore eio.
It happens in AlphaLiveProcess. I had the inclination that EIO is only
Alpha capable, I think I saw it on our wiki. Is that inherent or just the
way it is because we just don't have it for something else? I'm not sure
we'll develop eio for non-alpha anyway. But if people object, let me know,
I had an alternate fix that resides within the AlphaTLB only.
Lisa
On Tue, Nov 4, 2008 at 11:04 PM, Gabe Black [EMAIL PROTECTED] wrote:
Actually not if the EIO process object is generic. Where would this
normally happen for a live process? In a subclass? I'm really surprised
I don't remember... It's been a while :)
Gabe
Gabe Black wrote:
This might be a reasonable fix for the immediate term, but I don't think
eio is limited to Alpha. A more appropriate place for this is probably
in the EIO process object constructor.
Gabe
[EMAIL PROTECTED] wrote:
changeset 2c7b9d01d542 in /z/repo/encumbered
details:
http://repo.m5sim.org/encumbered?cmd=changeset;node=2c7b9d01d542
summary: fix multicore eio.
diffstat:
0 files changed
diffs (25 lines):
diff -r 25ae7c9393d9 -r 2c7b9d01d542 eio/eio.cc
--- a/eio/eio.cc Tue Nov 04 11:40:05 2008 -0500
+++ b/eio/eio.cc Tue Nov 04 21:55:49 2008 -0500
@@ -71,6 +71,7 @@
// field name in eval.h.
#include eio/libexo.h
+using namespace AlphaISA;
using namespace std;
static struct {
@@ -650,6 +651,13 @@
eio_close(chkpt_fd);
chkpt_fd = NULL;
}
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
+//Operate in user mode
+tc-setMiscRegNoEffect(IPR_ICM, 0x18);
+//No super page mapping
+tc-setMiscRegNoEffect(IPR_MCSR, 0);
+//Set this to 0 for now, but it should be unique for each process
+tc-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] encumbered: fix multicore eio.
EIO is Alpha only right now and will almost certainly remain so... not
because you couldn't port it to other ISAs, but if we decided we did
want to have an ISA-independent EIO-like capability we'd almost
certainly develop something else from scratch. The actual EIO code is
really there only for SimpleScalar compatibility. Note that M5
doesn't even generate EIO traces; you have to use ones that were
generated with SS. Not to mention that we'd want to have something
that could live in our tree and not be encumbered.
So in short I think we're safe hard-coding Alpha stuff into EIO.
Steve
2008/11/4 Lisa Hsu [EMAIL PROTECTED]:
It happens in AlphaLiveProcess. I had the inclination that EIO is only
Alpha capable, I think I saw it on our wiki. Is that inherent or just the
way it is because we just don't have it for something else? I'm not sure
we'll develop eio for non-alpha anyway. But if people object, let me know,
I had an alternate fix that resides within the AlphaTLB only.
Lisa
On Tue, Nov 4, 2008 at 11:04 PM, Gabe Black [EMAIL PROTECTED] wrote:
Actually not if the EIO process object is generic. Where would this
normally happen for a live process? In a subclass? I'm really surprised
I don't remember... It's been a while :)
Gabe
Gabe Black wrote:
This might be a reasonable fix for the immediate term, but I don't think
eio is limited to Alpha. A more appropriate place for this is probably
in the EIO process object constructor.
Gabe
[EMAIL PROTECTED] wrote:
changeset 2c7b9d01d542 in /z/repo/encumbered
details:
http://repo.m5sim.org/encumbered?cmd=changeset;node=2c7b9d01d542
summary: fix multicore eio.
diffstat:
0 files changed
diffs (25 lines):
diff -r 25ae7c9393d9 -r 2c7b9d01d542 eio/eio.cc
--- a/eio/eio.cc Tue Nov 04 11:40:05 2008 -0500
+++ b/eio/eio.cc Tue Nov 04 21:55:49 2008 -0500
@@ -71,6 +71,7 @@
// field name in eval.h.
#include eio/libexo.h
+using namespace AlphaISA;
using namespace std;
static struct {
@@ -650,6 +651,13 @@
eio_close(chkpt_fd);
chkpt_fd = NULL;
}
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
+//Operate in user mode
+tc-setMiscRegNoEffect(IPR_ICM, 0x18);
+//No super page mapping
+tc-setMiscRegNoEffect(IPR_MCSR, 0);
+//Set this to 0 for now, but it should be unique for each process
+tc-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] encumbered: fix multicore eio.
I agree that it's not a very serious problem. I think I remember my
cubemate at HP trying to get SPARC EIO traces to work in M5 at one point
which is why I'm thinking they do exist, but if we want EIO to be Alpha
only I'm fine with that. Maybe we should put something like the
following in files which are Alpha specific but where that might not be
obvious? Otherwise you'll probably get weird type related errors or
something similar.
#if THE_ISA != ALPHA_ISA
#error This file is only compatible with the Alpha ISA.
#endif
Gabe
Steve Reinhardt wrote:
EIO is Alpha only right now and will almost certainly remain so... not
because you couldn't port it to other ISAs, but if we decided we did
want to have an ISA-independent EIO-like capability we'd almost
certainly develop something else from scratch. The actual EIO code is
really there only for SimpleScalar compatibility. Note that M5
doesn't even generate EIO traces; you have to use ones that were
generated with SS. Not to mention that we'd want to have something
that could live in our tree and not be encumbered.
So in short I think we're safe hard-coding Alpha stuff into EIO.
Steve
2008/11/4 Lisa Hsu [EMAIL PROTECTED]:
It happens in AlphaLiveProcess. I had the inclination that EIO is only
Alpha capable, I think I saw it on our wiki. Is that inherent or just the
way it is because we just don't have it for something else? I'm not sure
we'll develop eio for non-alpha anyway. But if people object, let me know,
I had an alternate fix that resides within the AlphaTLB only.
Lisa
On Tue, Nov 4, 2008 at 11:04 PM, Gabe Black [EMAIL PROTECTED] wrote:
Actually not if the EIO process object is generic. Where would this
normally happen for a live process? In a subclass? I'm really surprised
I don't remember... It's been a while :)
Gabe
Gabe Black wrote:
This might be a reasonable fix for the immediate term, but I don't think
eio is limited to Alpha. A more appropriate place for this is probably
in the EIO process object constructor.
Gabe
[EMAIL PROTECTED] wrote:
changeset 2c7b9d01d542 in /z/repo/encumbered
details:
http://repo.m5sim.org/encumbered?cmd=changeset;node=2c7b9d01d542
summary: fix multicore eio.
diffstat:
0 files changed
diffs (25 lines):
diff -r 25ae7c9393d9 -r 2c7b9d01d542 eio/eio.cc
--- a/eio/eio.cc Tue Nov 04 11:40:05 2008 -0500
+++ b/eio/eio.cc Tue Nov 04 21:55:49 2008 -0500
@@ -71,6 +71,7 @@
// field name in eval.h.
#include eio/libexo.h
+using namespace AlphaISA;
using namespace std;
static struct {
@@ -650,6 +651,13 @@
eio_close(chkpt_fd);
chkpt_fd = NULL;
}
+ThreadContext *tc = system-getThreadContext(contextIds[0]);
+//Operate in user mode
+tc-setMiscRegNoEffect(IPR_ICM, 0x18);
+//No super page mapping
+tc-setMiscRegNoEffect(IPR_MCSR, 0);
+//Set this to 0 for now, but it should be unique for each process
+tc-setMiscRegNoEffect(IPR_DTB_ASN, M5_pid 57);
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] early failing store conditional dcache_pkt
Looking into this more, there are two problems. First, it looks like Alpha is passing back it's store conditional result in the extra data part of the request. I think for regular swaps this is actually the data to swap in, and for conditional swaps this is what to compare to, but I'm not absolutely sure. In any case, what to do with this value to split it up is very ambiguous, so I'm just going to panic on any spit swap. Second, handleLockedWrite is called on any swap, but it isn't until later, and only for conditional swaps, where that extra data field is actually set to anything. That means that in all cases you're actually trashing something useful, and for conditional swaps you're actually then loosing the value when you set the pointer to something real. I tried rolling back my changes to timing.cc to make sure this wasn't something I did accidentally and it appears not, but that still may be the case. If nobody does anything with this for a while I'll get to it, but that might not happen quickly. Gabe Steve Reinhardt wrote: You're right, it is the request and not the packet... that's what I get for answering off the top of my head. The packet pointer is what's passed back to completeAcc() I believe just because loads and stores both share the same interface and loads need the packet pointer to get the response data. At least for store conditional, the result is really a status rather a value, so the most general approach would be to have a function that combines the status values from the split requests into a final status. If we can define a function that works for all instructions that care about the status value then that might not be too bad. Given that store conditional may be the only thing that cares, it shouldn't be hard to define a function that works for now, particularly if it never gets called. Either assert that both status values are equal or bitwise OR would probably work. I'm not sure which one is more likely to work in the future, but probably all we can do is pick one at this point and then if the need ever arises to actually use it then we can revisit the issue. I'd lean toward assert that both status values are equal because it's less likely to have some subtle failure mode that leaves us scratching our heads until we recall this conversation. Steve On Sun, Nov 2, 2008 at 5:35 PM, Gabe Black [EMAIL PROTECTED] wrote: Ok. really the result is being passed in the request and not the packet, right? There are several things that make this tricky. The request in this case would need to reflect whether or not the call to handleLockedWrite worked, but it would also have to potentially be broken into two parts for a split access. Which request do you give back? The original one for the whole write, or the partial one you actually used? Which half? The first one or the one that failed? Which packet do you use to carry the result back to completeAcc? I think a lot of things could work here, but nothing is clearly the right answer. The immediate reality is that nothing we have uses both the locked accesses and unaligned/split accesses, but I REALLY don't design something where that's not possible. I'll eventually need to properly support locked accesses at some point, so I may need to use this mechanism in x86. We need to pick a set of semantics so that this sort of thing can be handled consistently and sensibly everywhere, so that instructions know what they can/can't expect, etc. Gabe Steve Reinhardt wrote: You need to always call completeAcc() because it may do something necessary... in the case of store conditional, it updates the destination register that indicates to the program whether the store succeeded or not. completeAcc() gets this information out of the packet, so that's why you need to have one to pass to it if you don't actually call the cache. completeAcc() doesn't care whether the request made it to the cache or not. Steve On Sun, Nov 2, 2008 at 12:00 AM, Gabe Black [EMAIL PROTECTED] wrote: I have split reads working (I think), and now I'm starting in on writes. The write function is a little more convoluted than the read function, partly because it tries to always have a dcache_pkt around even when there hasn't been an access since that's passed to completeAcc. The only time completeAcc is called inline with initiateAcc, which is where read/write is called, is if the CPU is still running, aka not waiting for the dcache, and there was no fault. The only way this can happen is if either the instruction itself never did an access, which can be the case with ARM apparently, or if the instruction is a store conditional which tried to do an access but failed for some reason before the actual packet got sent. In both of these cases, rather than make sure that some nonsense dcache_pkt is around so completeAcc doesn't get a NULL pointer, would it make sense to just not call
