[gem5-dev] Change in gem5/gem5[develop]: tests: Re-add the DerivO3CPU asmtests
Bobby Bruce has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/56809 )
Change subject: tests: Re-add the DerivO3CPU asmtests
..
tests: Re-add the DerivO3CPU asmtests
In previous releases of gem5 these tests were failing and were therefore
ignored. At some point it appears these tests have been fixed. This
patch therefore re-introduces these tests to our test suite.
Issue-on: https://gem5.atlassian.net/browse/GEM5-496
Change-Id: Ia196ac536fb2b36998f4cfa11898b176e0b2f0e4
---
M tests/gem5/asmtest/tests.py
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests/gem5/asmtest/tests.py b/tests/gem5/asmtest/tests.py
index 6f2c7117..e5bd095 100755
--- a/tests/gem5/asmtest/tests.py
+++ b/tests/gem5/asmtest/tests.py
@@ -89,15 +89,12 @@
cpu_types =
('AtomicSimpleCPU', 'TimingSimpleCPU', 'MinorCPU', 'DerivO3CPU')
-# The following lists the RISCV binaries. Those commented out presently
result
-# in a test failure. This is outlined in the following Jira issue:
-# https://gem5.atlassian.net/browse/GEM5-496
binaries = (
'rv64samt-ps-sysclone_d',
'rv64samt-ps-sysfutex1_d',
-#'rv64samt-ps-sysfutex2_d',
+'rv64samt-ps-sysfutex2_d',
'rv64samt-ps-sysfutex3_d',
-#'rv64samt-ps-sysfutex_d',
+'rv64samt-ps-sysfutex_d',
'rv64ua-ps-amoadd_d',
'rv64ua-ps-amoadd_w',
'rv64ua-ps-amoand_d',
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/56809
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ia196ac536fb2b36998f4cfa11898b176e0b2f0e4
Gerrit-Change-Number: 56809
Gerrit-PatchSet: 1
Gerrit-Owner: Bobby Bruce
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: python: Update gem5 url output by the simulator
Bobby Bruce has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/56649 )
Change subject: python: Update gem5 url output by the simulator
..
python: Update gem5 url output by the simulator
This patch:
- Replaces 'http' with 'https'.
- Adds 'www'.
Change-Id: I6500a39171eb79c98754f517ff1fdd0cf60d83d0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56649
Reviewed-by: Jason Lowe-Power
Maintainer: Jason Lowe-Power
Tested-by: kokoro
---
M src/python/m5/main.py
1 file changed, 18 insertions(+), 1 deletion(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/python/m5/main.py b/src/python/m5/main.py
index 701d9f6..b216840 100644
--- a/src/python/m5/main.py
+++ b/src/python/m5/main.py
@@ -310,7 +310,7 @@
verbose = options.verbose - options.quiet
if verbose >= 0:
-print("gem5 Simulator System. http://gem5.org";)
+print("gem5 Simulator System. https://www.gem5.org";)
print(brief_copyright)
print()
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/56649
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I6500a39171eb79c98754f517ff1fdd0cf60d83d0
Gerrit-Change-Number: 56649
Gerrit-PatchSet: 2
Gerrit-Owner: Bobby Bruce
Gerrit-Reviewer: Andreas Sandberg
Gerrit-Reviewer: Bobby Bruce
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: Fix handling of stale CleanUnique
Tiago Muck has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/56810 )
Change subject: mem-ruby: Fix handling of stale CleanUnique
..
mem-ruby: Fix handling of stale CleanUnique
JIRA: https://gem5.atlassian.net/browse/GEM5-1185
Fixed an issue in which a CleanUnique responder would incorrectly
deallocate the cache block when handling an stale CU when the state
is UD_RU or UC_RU (thus incorrectly transitioning to RU).
The fix is to handle stale CUs similarly to stale WBs where we
override the dataValid TBE field to prevent the wrong state
transition.
This patch moves the stale code path to a separate transition
(similarly to stale WBs/Evicts) and moves the dataValid override to
Initiate_Request_Stale so it applies to all stale request types.
Notice now the stale field is also set on stale Comp_UC responses.
Additional minor change: CheckUpgrade_FromRU is the same as
CheckUpgrade_FromStore so it was removed.
Change-Id: I0a2cedcfde1dc30d67aa2c16d71b7470369c2b6e
Signed-off-by: Tiago Mück
---
M src/mem/ruby/protocol/chi/CHI-cache-actions.sm
M src/mem/ruby/protocol/chi/CHI-cache-ports.sm
M src/mem/ruby/protocol/chi/CHI-cache-transitions.sm
M src/mem/ruby/protocol/chi/CHI-cache.sm
4 files changed, 112 insertions(+), 44 deletions(-)
diff --git a/src/mem/ruby/protocol/chi/CHI-cache-actions.sm
b/src/mem/ruby/protocol/chi/CHI-cache-actions.sm
index b1a7d99..93a97d4 100644
--- a/src/mem/ruby/protocol/chi/CHI-cache-actions.sm
+++ b/src/mem/ruby/protocol/chi/CHI-cache-actions.sm
@@ -219,6 +219,17 @@
was_retried := in_msg.allowRetry == false;
}
copyCacheAndDir(cache_entry, getDirEntry(address), tbe, initial);
+
+ // usually we consider data locally invalid on RU states even if we
+ // have a copy; so it override it to valid so we can comeback to
UD_RU/UC_RU
+ // at the end of this transaction
+ if (tbe.dir_ownerExists && tbe.dir_ownerIsExcl && is_valid(cache_entry))
{
+// treat the data we got from the cache as valid
+tbe.dataBlk := cache_entry.DataBlk;
+tbe.dataBlkValid.fillMask();
+tbe.dataValid := true;
+ }
+
incomingTransactionStart(address, curTransitionEvent(), initial,
was_retried);
}
@@ -288,6 +299,8 @@
tbe.is_stale := (tbe.dataValid && tbe.dataUnique) == false;
} else if (hazard_tbe.pendReqType == CHIRequestType:Evict) {
tbe.is_stale := tbe.dataValid == false;
+ } else if (hazard_tbe.pendReqType == CHIRequestType:CleanUnique) {
+tbe.is_stale := tbe.dataValid == false;
}
// a pending action from the original request may have been stalled
during
@@ -575,45 +588,50 @@
action(Initiate_CleanUnique, desc="") {
tbe.actions.push(Event:ReadMissPipe); // TODO need another latency
pipe ??
+ // invalidates everyone except requestor
+ if (tbe.dir_sharers.count() > 1) {
+tbe.actions.push(Event:SendSnpCleanInvalidNoReq);
+ }
+ // auto upgrade if HN
+ tbe.dataUnique := tbe.dataUnique || is_HN;
+ // get unique permission
+ if (tbe.dataUnique == false) {
+tbe.actions.push(Event:SendCleanUnique);
+tbe.actions.push(Event:CheckUpgrade_FromCU);
+ }
+ // next actions will depend on the data state after snoops+CleanUnique
+ tbe.actions.push(Event:FinishCleanUnique);
+}
+
+action(Initiate_CleanUnique_Stale, desc="") {
// requestor don't have the line anymore; send response but don't update
the
// directory on CompAck. The requestor knows we are not tracking it and
will
// send a ReadUnique later
- if (tbe.dir_sharers.isElement(tbe.requestor) == false) {
-tbe.actions.push(Event:SendCompUCResp);
-tbe.actions.push(Event:WaitCompAck);
-tbe.updateDirOnCompAck := false;
- } else {
-// invalidates everyone except requestor
-if (tbe.dir_sharers.count() > 1) {
- tbe.actions.push(Event:SendSnpCleanInvalidNoReq);
-}
-// auto upgrade if HN
-tbe.dataUnique := tbe.dataUnique || is_HN;
-// get unique permission
-if (tbe.dataUnique == false) {
- tbe.actions.push(Event:SendCleanUnique);
- tbe.actions.push(Event:CheckUpgrade_FromCU);
-}
-// next actions will depend on the data state after snoops+CleanUnique
-tbe.actions.push(Event:FinishCleanUnique);
- }
+ tbe.actions.push(Event:SendCompUCRespStale);
+ tbe.actions.push(Event:WaitCompAck);
+ tbe.updateDirOnCompAck := false;
}
action(Finish_CleanUnique, desc="") {
// This is should be executed at the end of a transaction
assert(tbe.actions.empty());
- tbe.actions.push(Event:SendCompUCResp);
- tbe.actions.push(Event:WaitCompAck);
// everyone may have been hit by an invalidation so check again
if (tbe.dir_sharers.isElement(tbe.requestor) == false) {
tbe.updateDirOnCompAck := false;
assert(tbe.dataValid == false);
+assert(tbe.is_stale);
+tbe.actions.push(Event:SendCompUCRespStale);
+tbe.actions.push(Event:WaitCompAck);
+tbe.is_stale := false;
} else {
[gem5-dev] Change in gem5/gem5[develop]: cpu: fix issues with ruby's memtest
Tiago Muck has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/56811 )
Change subject: cpu: fix issues with ruby's memtest
..
cpu: fix issues with ruby's memtest
If the size of the address range is smaller than the maximum number
of outstanding requests allowed downstream, the tester will get stuck
trying to find a unique address. This patch adds a check for this
condition and forces the tester to wait for responses before
trying to generate another request.
Change-Id: Ie894a074cc4f8c7ad3d875dc21e8eb4f04562d72
Signed-off-by: Tiago Mück
---
M src/cpu/testers/memtest/memtest.cc
M src/cpu/testers/memtest/memtest.hh
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/cpu/testers/memtest/memtest.cc
b/src/cpu/testers/memtest/memtest.cc
index f229cab..7c256d8 100644
--- a/src/cpu/testers/memtest/memtest.cc
+++ b/src/cpu/testers/memtest/memtest.cc
@@ -88,6 +88,7 @@
noResponseEvent([this]{ noResponse(); }, name()),
port("port", *this),
retryPkt(nullptr),
+ waitResponse(false),
size(p.size),
interval(p.interval),
percentReads(p.percent_reads),
@@ -96,6 +97,7 @@
requestorId(p.system->getRequestorId(this)),
blockSize(p.system->cacheLineSize()),
blockAddrMask(blockSize - 1),
+ sizeBlocks(size / blockSize),
baseAddr1(p.base_addr_1),
baseAddr2(p.base_addr_2),
uncacheAddr(p.uncacheable_base_addr),
@@ -191,6 +193,12 @@
reschedule(noResponseEvent, clockEdge(progressCheck));
else if (noResponseEvent.scheduled())
deschedule(noResponseEvent);
+
+// schedule the next tick
+if (waitResponse) {
+waitResponse = false;
+schedule(tickEvent, clockEdge(interval));
+}
}
MemTest::MemTestStats::MemTestStats(statistics::Group *parent)
: statistics::Group(parent),
@@ -205,8 +213,9 @@
void
MemTest::tick()
{
-// we should never tick if we are waiting for a retry
+// we should never tick if we are waiting for a retry or response
assert(!retryPkt);
+assert(!waitResponse);
// create a new request
unsigned cmd = random_mt.random(0, 100);
@@ -216,6 +225,13 @@
Request::Flags flags;
Addr paddr;
+// halt until we clear outstanding requests, otherwise it won't be
able to
+// find a new unique address
+if (outstandingAddrs.size() >= sizeBlocks) {
+waitResponse = true;
+return;
+}
+
// generate a unique address
do {
unsigned offset = random_mt.random(0, size - 1);
diff --git a/src/cpu/testers/memtest/memtest.hh
b/src/cpu/testers/memtest/memtest.hh
index 2e7824e..2dc1f13 100644
--- a/src/cpu/testers/memtest/memtest.hh
+++ b/src/cpu/testers/memtest/memtest.hh
@@ -120,6 +120,10 @@
PacketPtr retryPkt;
+// Set if reached the maximum number of outstanding requests.
+// Won't tick until a response is received.
+bool waitResponse;
+
const unsigned size;
const Cycles interval;
@@ -142,6 +146,8 @@
const Addr blockAddrMask;
+const unsigned sizeBlocks;
+
/**
* Get the block aligned address.
*
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/56811
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ie894a074cc4f8c7ad3d875dc21e8eb4f04562d72
Gerrit-Change-Number: 56811
Gerrit-PatchSet: 1
Gerrit-Owner: Tiago Muck
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: arch-x86: Fix immediate based IN instructions.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/55286 )
(
14 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the
submitted one.
)Change subject: arch-x86: Fix immediate based IN instructions.
..
arch-x86: Fix immediate based IN instructions.
These were loading the immediate into a temporary microcode register
which would then be used to calculate the address to actually send to
the memory system. Unfortunately this was using a data size equal to the
address size, which would mean that the immediate would be merged into
that temporary, leaving previously set bits intact. The data size
*should* have been set to 8, and was already in other similar
instructions. That forces the limm microop to overwrite the temporary
entirely.
Change-Id: I87c82b4677db768ccb6401a3dbda61317c014152
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55286
Maintainer: Gabe Black
Tested-by: kokoro
Reviewed-by: Bobby Bruce
---
M src/arch/x86/isa/insts/general_purpose/input_output/general_io.py
1 file changed, 23 insertions(+), 1 deletion(-)
Approvals:
Bobby Bruce: Looks good to me, approved
Gabe Black: Looks good to me, approved
kokoro: Regressions pass
diff --git
a/src/arch/x86/isa/insts/general_purpose/input_output/general_io.py
b/src/arch/x86/isa/insts/general_purpose/input_output/general_io.py
index 27396e2..58b38e5 100644
--- a/src/arch/x86/isa/insts/general_purpose/input_output/general_io.py
+++ b/src/arch/x86/isa/insts/general_purpose/input_output/general_io.py
@@ -39,7 +39,7 @@
microcode = '''
def macroop IN_R_I {
.adjust_imm trimImm(8)
-limm t1, imm, dataSize=asz
+limm t1, imm, dataSize=8
mfence
ld reg, intseg, [1, t1, t0], "IntAddrPrefixIO << 3",
addressSize=8, \
nonSpec=True
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/55286
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I87c82b4677db768ccb6401a3dbda61317c014152
Gerrit-Change-Number: 55286
Gerrit-PatchSet: 16
Gerrit-Owner: Gabe Black
Gerrit-Reviewer: Bobby Bruce
Gerrit-Reviewer: Bradford Beckmann
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Matt Sinclair
Gerrit-Reviewer: Matthew Poremba
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: arch-x86: Use the seg unusable bit and not a null selector in the TLB.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/55245 )
Change subject: arch-x86: Use the seg unusable bit and not a null selector
in the TLB.
..
arch-x86: Use the seg unusable bit and not a null selector in the TLB.
When dealing with segmentation in x86, it is *usually* illegal to
attempt to access a segment which has a null selector when in protected
mode and not in 64 bit mode. While this is *almost* true, it is not
actually technically true.
What actually *is* true is that if you *set up* a segment using a null
selector in those circumstances, that segment becomes unusable, and then
tryint to use it causes a fault.
When in real mode, it is perfectly legal to use a null selector to
access memory, since that is just a selector with numerical value 0.
When you then transition into protected mode, the selector would still
be 0 (a null selector), but the segment itself would still be set up
properly and usuable using the base value, limit, and other attributes
it carried over from real mode.
Rather than check if a segment has a null selector while handling
segmentation, it's more correct for us to keep track of whether the
segment is currently usable and check that in the TLB.
Change-Id: Ic2c09e1cfa05afcb03900213b72733545c8f0f4c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55245
Maintainer: Gabe Black
Tested-by: kokoro
Reviewed-by: Bobby Bruce
---
M src/arch/x86/faults.cc
M src/arch/x86/isa/microops/regop.isa
M src/arch/x86/process.cc
M src/arch/x86/tlb.cc
4 files changed, 52 insertions(+), 9 deletions(-)
Approvals:
Bobby Bruce: Looks good to me, approved
Gabe Black: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/x86/faults.cc b/src/arch/x86/faults.cc
index 347a857..09b4d99 100644
--- a/src/arch/x86/faults.cc
+++ b/src/arch/x86/faults.cc
@@ -255,7 +255,8 @@
tc->setMiscReg(MISCREG_IDTR_LIMIT, 0x);
SegAttr tslAttr = 0;
-tslAttr.present = 1;
+tslAttr.unusable = 1;
+tslAttr.present = 0;
tslAttr.type = 2; // LDT
tc->setMiscReg(MISCREG_TSL, 0);
tc->setMiscReg(MISCREG_TSL_BASE, 0);
@@ -263,7 +264,8 @@
tc->setMiscReg(MISCREG_TSL_ATTR, tslAttr);
SegAttr trAttr = 0;
-trAttr.present = 1;
+trAttr.unusable = 1;
+trAttr.present = 0;
trAttr.type = 3; // Busy 16-bit TSS
tc->setMiscReg(MISCREG_TR, 0);
tc->setMiscReg(MISCREG_TR_BASE, 0);
diff --git a/src/arch/x86/isa/microops/regop.isa
b/src/arch/x86/isa/microops/regop.isa
index 153060c..d37cb6f 100644
--- a/src/arch/x86/isa/microops/regop.isa
+++ b/src/arch/x86/isa/microops/regop.isa
@@ -1669,9 +1669,15 @@
SegLimitDest = desc.limit;
SegAttrDest = attr;
} else {
+HandyM5Reg m5reg = M5Reg;
+
SegBaseDest = SegBaseDest;
SegLimitDest = SegLimitDest;
-SegAttrDest = SegAttrDest;
+
+SegAttr attr = SegAttrDest;
+if (m5reg != LongMode)
+attr.unusable = 1;
+SegAttrDest = attr;
}
break;
}
diff --git a/src/arch/x86/process.cc b/src/arch/x86/process.cc
index b4f8dee..b1d2f43 100644
--- a/src/arch/x86/process.cc
+++ b/src/arch/x86/process.cc
@@ -322,7 +322,8 @@
// LDT
tc->setMiscReg(MISCREG_TSL, 0);
SegAttr tslAttr = 0;
-tslAttr.present = 1;
+tslAttr.unusable = 1;
+tslAttr.present = 0;
tslAttr.type = 2;
tc->setMiscReg(MISCREG_TSL_ATTR, tslAttr);
@@ -684,6 +685,9 @@
// Set the LDT selector to 0 to deactivate it.
tc->setMiscRegNoEffect(MISCREG_TSL, 0);
+SegAttr attr = 0;
+attr.unusable = 1;
+tc->setMiscRegNoEffect(MISCREG_TSL_ATTR, attr);
Efer efer = 0;
efer.sce = 1; // Enable system call extensions.
diff --git a/src/arch/x86/tlb.cc b/src/arch/x86/tlb.cc
index 2fc34fb..b2856ed 100644
--- a/src/arch/x86/tlb.cc
+++ b/src/arch/x86/tlb.cc
@@ -334,13 +334,11 @@
// If we're not in 64-bit mode, do protection/limit checks
if (m5Reg.mode != LongMode) {
DPRINTF(TLB, "Not in long mode. Checking segment
protection.\n");
-// Check for a NULL segment selector.
-if (!(seg == SEGMENT_REG_TSG || seg == SYS_SEGMENT_REG_IDTR ||
-seg == SEGMENT_REG_HS || seg == SEGMENT_REG_LS)
-&& !tc->readMiscRegNoEffect(MISCREG_SEG_SEL(seg)))
+SegAttr attr = tc->readMiscRegNoEffect(MISCREG_SEG_ATTR(seg));
+// Check for an unusable segment.
+if (attr.unusable)
return std::make_shared(0);
bool expandDown = false;
-SegAttr attr = tc->readMiscRegNoEffect(MISC
[gem5-dev] Change in gem5/gem5[develop]: configs: Call createThreads() for FutureCPUs.
ZHENGRONG WANG has uploaded this change for review. ( https://gem5-review.googlesource.com/c/public/gem5/+/56812 ) Change subject: configs: Call createThreads() for FutureCPUs. .. configs: Call createThreads() for FutureCPUs. When using fast forwarding, createThreads() is not called upon FutureCPUs. This causes segment fault as the decoder is initialized in createThreads() and needed when instantiating CPUs. This commit basically fixes this by invoking createThreads() on FutureCPUs after they are created. Change-Id: I812d18f06878f9fc3fa2183a2c8a64d316413398 --- M configs/common/Simulation.py 1 file changed, 18 insertions(+), 0 deletions(-) diff --git a/configs/common/Simulation.py b/configs/common/Simulation.py index 3b9efc0..2416773 100644 --- a/configs/common/Simulation.py +++ b/configs/common/Simulation.py @@ -488,6 +488,7 @@ options.indirect_bp_type) switch_cpus[i].branchPred.indirectBranchPred = \ IndirectBPClass() +switch_cpus[i].createThreads() # If elastic tracing is enabled attach the elastic trace probe # to the switch CPUs -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/56812 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I812d18f06878f9fc3fa2183a2c8a64d316413398 Gerrit-Change-Number: 56812 Gerrit-PatchSet: 1 Gerrit-Owner: ZHENGRONG WANG Gerrit-MessageType: newchange ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: configs: Call createThreads() for FutureCPUs.
ZHENGRONG WANG has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/56812 ) Change subject: configs: Call createThreads() for FutureCPUs. .. configs: Call createThreads() for FutureCPUs. When using fast forwarding, createThreads() is not called upon FutureCPUs. This causes segment fault as the decoder is initialized in createThreads() and needed when instantiating CPUs. This commit basically fixes this by invoking createThreads() on FutureCPUs after they are created. Change-Id: I812d18f06878f9fc3fa2183a2c8a64d316413398 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56812 Reviewed-by: Jason Lowe-Power Maintainer: Jason Lowe-Power Reviewed-by: Luming Wang Tested-by: kokoro --- M configs/common/Simulation.py 1 file changed, 23 insertions(+), 0 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved Luming Wang: Looks good to me, but someone else must approve kokoro: Regressions pass diff --git a/configs/common/Simulation.py b/configs/common/Simulation.py index 3b9efc0..2416773 100644 --- a/configs/common/Simulation.py +++ b/configs/common/Simulation.py @@ -488,6 +488,7 @@ options.indirect_bp_type) switch_cpus[i].branchPred.indirectBranchPred = \ IndirectBPClass() +switch_cpus[i].createThreads() # If elastic tracing is enabled attach the elastic trace probe # to the switch CPUs -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/56812 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I812d18f06878f9fc3fa2183a2c8a64d316413398 Gerrit-Change-Number: 56812 Gerrit-PatchSet: 2 Gerrit-Owner: ZHENGRONG WANG Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Luming Wang Gerrit-Reviewer: ZHENGRONG WANG Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
