[gem5-dev] Change in gem5/gem5[develop]: arch,cpu,dev,sim,mem: Collect System thread elements into a subclass.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/25144 )
Change subject: arch,cpu,dev,sim,mem: Collect System thread elements into a
subclass.
..
arch,cpu,dev,sim,mem: Collect System thread elements into a subclass.
The System class has a few different arrays of values which each
correspond to a thread of execution based on their position. This
change collects them together into a single class to make managing them
easier and less error prone. It also collects methods for manipulating
those threads as an API for that class.
This class acts as a collection point for thread based state which the
System class can look into to get at all its state. It also acts as an
interface for interacting with threads for other classes. This forces
external consumers to use the API instead of accessing the individual
arrays which improves consistency.
Change-Id: Idc4575c5a0b56fe75f5c497809ad91c22bfe26cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25144
Reviewed-by: Bobby R. Bruce
Maintainer: Bobby R. Bruce
Tested-by: kokoro
---
M src/arch/arm/freebsd/fs_workload.cc
M src/arch/arm/fs_workload.cc
M src/arch/arm/isa.cc
M src/arch/arm/isa/insts/misc.isa
M src/arch/arm/kvm/gic.cc
M src/arch/arm/linux/fs_workload.cc
M src/arch/arm/linux/process.cc
M src/arch/arm/process.cc
M src/arch/arm/tlbi_op.hh
M src/arch/mips/process.cc
M src/arch/power/process.cc
M src/arch/riscv/bare_metal/fs_workload.cc
M src/arch/riscv/process.cc
M src/arch/sparc/fs_workload.cc
M src/arch/sparc/process.cc
M src/arch/sparc/tlb.cc
M src/arch/sparc/ua2005.cc
M src/arch/x86/fs_workload.cc
M src/arch/x86/interrupts.cc
M src/arch/x86/linux/fs_workload.cc
M src/arch/x86/process.cc
M src/cpu/base.hh
M src/cpu/intr_control.cc
M src/cpu/kvm/vm.cc
M src/cpu/o3/cpu.cc
M src/dev/arm/a9scu.cc
M src/dev/arm/fvp_base_pwr_ctrl.cc
M src/dev/arm/generic_timer.cc
M src/dev/arm/gic_v2.cc
M src/dev/arm/gic_v2.hh
M src/dev/arm/gic_v3.cc
M src/dev/arm/gic_v3_cpu_interface.cc
M src/dev/arm/gic_v3_distributor.cc
M src/dev/arm/gic_v3_redistributor.cc
M src/dev/arm/timer_cpulocal.cc
M src/dev/arm/vgic.cc
M src/dev/mips/malta_cchip.cc
M src/dev/net/dist_iface.cc
M src/dev/sparc/iob.cc
M src/dev/x86/i82094aa.cc
M src/kern/linux/linux.cc
M src/mem/abstract_mem.cc
M src/mem/cache/prefetch/queued.cc
M src/sim/mem_state.cc
M src/sim/process.cc
M src/sim/pseudo_inst.cc
M src/sim/syscall_emul.cc
M src/sim/syscall_emul.hh
M src/sim/system.cc
M src/sim/system.hh
50 files changed, 363 insertions(+), 266 deletions(-)
Approvals:
Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/arm/freebsd/fs_workload.cc
b/src/arch/arm/freebsd/fs_workload.cc
index d15e1a2..080dc35 100644
--- a/src/arch/arm/freebsd/fs_workload.cc
+++ b/src/arch/arm/freebsd/fs_workload.cc
@@ -113,7 +113,7 @@
delete dtb_file;
// Kernel boot requirements to set up r0, r1 and r2 in ARMv7
-for (auto tc: system->threadContexts) {
+for (auto *tc: system->threads) {
tc->setIntReg(0, 0);
tc->setIntReg(1, params()->machine_type);
tc->setIntReg(2, params()->atags_addr + _loadAddrOffset);
diff --git a/src/arch/arm/fs_workload.cc b/src/arch/arm/fs_workload.cc
index 5bd534f..0cafb1b 100644
--- a/src/arch/arm/fs_workload.cc
+++ b/src/arch/arm/fs_workload.cc
@@ -103,7 +103,7 @@
// FPEXC.EN = 0
-for (auto *tc: system->threadContexts) {
+for (auto *tc: system->threads) {
Reset().invoke(tc);
tc->activate();
}
@@ -126,7 +126,7 @@
fatal_if(!arm_sys->params()->gic_cpu_addr && is_gic_v2,
"gic_cpu_addr must be set with bootloader");
-for (auto tc: arm_sys->threadContexts) {
+for (auto *tc: arm_sys->threads) {
if (!arm_sys->highestELIs64())
tc->setIntReg(3, kernelEntry);
if (is_gic_v2)
@@ -137,7 +137,7 @@
} else {
// Set the initial PC to be at start of the kernel code
if (!arm_sys->highestELIs64())
-arm_sys->threadContexts[0]->pcState(kernelObj->entryPoint());
+arm_sys->threads[0]->pcState(kernelObj->entryPoint());
}
}
diff --git a/src/arch/arm/isa.cc b/src/arch/arm/isa.cc
index b18bbb0..b3ea91e 100644
--- a/src/arch/arm/isa.cc
+++ b/src/arch/arm/isa.cc
@@ -683,7 +683,7 @@
// mostly unimplemented, just set NumCPUs field from sim and
return
L2CTLR l2ctlr = 0;
// b00:1CPU to b11:4CPUs
-l2ctlr.numCPUs = tc->getSystemPtr()->numContexts() - 1;
+l2ctlr.numCPUs = tc->getSystemPtr()->threads.size() - 1;
return l2ctlr;
}
case MISCREG_DBGDIDR:
diff --git a/src/arch/arm/isa/insts/misc.isa
b/src/arch/arm/isa/insts/misc.isa
index 88c473d..cd44387 100644
--- a/src/arch/arm/isa/insts/misc.isa
+++
[gem5-dev] Change in gem5/gem5[develop]: arch,base,cpu,kerm,sim: Build a symbol table for object files.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/24787 )
Change subject: arch,base,cpu,kerm,sim: Build a symbol table for object
files.
..
arch,base,cpu,kerm,sim: Build a symbol table for object files.
Instead of calling into object files after the fact and asking them to
put symbols into a target symbol table, this change makes object files
fill in a symbol table themselves at construction. Then, that table can
be retrieved and used to fill in aggregate tables, masked, moved,
and/or filtered to have only one type of symbol binding.
This simplifies the symbol management API of the object file types
significantly, and makes it easier to deal with symbol tables alongside
binaries in the FS workload classes.
Change-Id: Ic9006ca432033d72589867c93d9c5f8a1d87f73c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24787
Reviewed-by: Bobby R. Bruce
Reviewed-by: Giacomo Travaglini
Maintainer: Gabe Black
Tested-by: kokoro
---
M src/arch/arm/freebsd/fs_workload.cc
M src/arch/arm/fs_workload.cc
M src/arch/arm/linux/fs_workload.cc
M src/arch/arm/stacktrace.cc
M src/arch/generic/linux/threadinfo.hh
M src/arch/riscv/bare_metal/fs_workload.cc
M src/arch/riscv/bare_metal/fs_workload.hh
M src/arch/sparc/fs_workload.hh
M src/arch/x86/stacktrace.cc
M src/base/loader/elf_object.cc
M src/base/loader/elf_object.hh
M src/base/loader/object_file.hh
M src/cpu/profile.cc
M src/cpu/profile.hh
M src/kern/linux/helpers.cc
M src/mem/abstract_mem.cc
M src/sim/kernel_workload.cc
M src/sim/kernel_workload.hh
M src/sim/process.cc
M src/sim/syscall_emul.hh
M src/sim/workload.hh
M src/unittest/nmtest.cc
22 files changed, 128 insertions(+), 244 deletions(-)
Approvals:
Giacomo Travaglini: Looks good to me, approved
Bobby R. Bruce: Looks good to me, approved
Gabe Black: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/arm/freebsd/fs_workload.cc
b/src/arch/arm/freebsd/fs_workload.cc
index e3660d9..d15e1a2 100644
--- a/src/arch/arm/freebsd/fs_workload.cc
+++ b/src/arch/arm/freebsd/fs_workload.cc
@@ -81,14 +81,14 @@
// to do this permanently, for but early bootup work
// it is helpful.
if (params()->early_kernel_symbols) {
-kernelObj->loadGlobalSymbols(kernelSymtab, 0, 0, _loadAddrMask);
-kernelObj->loadGlobalSymbols(
-::debugSymbolTable, 0, 0, _loadAddrMask);
+auto phys_globals =
kernelObj->symtab().globals()->mask(_loadAddrMask);
+kernelSymtab.insert(*phys_globals);
+Loader::debugSymbolTable.insert(*phys_globals);
}
// Check if the kernel image has a symbol that tells us it supports
// device trees.
-fatal_if(kernelSymtab->find("fdt_get_range") == kernelSymtab->end(),
+fatal_if(kernelSymtab.find("fdt_get_range") == kernelSymtab.end(),
"Kernel must have fdt support.");
fatal_if(params()->dtb_filename == "", "dtb file is not specified.");
diff --git a/src/arch/arm/fs_workload.cc b/src/arch/arm/fs_workload.cc
index 4c654b8..5bd534f 100644
--- a/src/arch/arm/fs_workload.cc
+++ b/src/arch/arm/fs_workload.cc
@@ -91,7 +91,7 @@
"Can't find a matching boot loader / kernel combination!");
if (bootldr)
-bootldr->loadGlobalSymbols(::debugSymbolTable);
+Loader::debugSymbolTable.insert(*bootldr->symtab().globals());
}
void
diff --git a/src/arch/arm/linux/fs_workload.cc
b/src/arch/arm/linux/fs_workload.cc
index 7f0853f..d45c7f0 100644
--- a/src/arch/arm/linux/fs_workload.cc
+++ b/src/arch/arm/linux/fs_workload.cc
@@ -76,16 +76,16 @@
// to do this permanently, for but early bootup work
// it is helpful.
if (params()->early_kernel_symbols) {
-kernelObj->loadGlobalSymbols(kernelSymtab, 0, 0, _loadAddrMask);
-kernelObj->loadGlobalSymbols(
-::debugSymbolTable, 0, 0, _loadAddrMask);
+auto phys_globals =
kernelObj->symtab().globals()->mask(_loadAddrMask);
+kernelSymtab.insert(*phys_globals);
+Loader::debugSymbolTable.insert(*phys_globals);
}
// Setup boot data structure
// Check if the kernel image has a symbol that tells us it supports
// device trees.
bool kernel_has_fdt_support =
-kernelSymtab->find("unflatten_device_tree") != kernelSymtab->end();
+kernelSymtab.find("unflatten_device_tree") != kernelSymtab.end();
bool dtb_file_specified = params()->dtb_filename != "";
if (kernel_has_fdt_support && dtb_file_specified) {
diff --git a/src/arch/arm/stacktrace.cc b/src/arch/arm/stacktrace.cc
index 535cddd..2c39576 100644
--- a/src/arch/arm/stacktrace.cc
+++ b/src/arch/arm/stacktrace.cc
@@ -45,10 +45,10 @@
readSymbol(ThreadContext *tc, const std::string name)
{
PortProxy = tc->getVirtProxy();
-const auto *symtab = tc->getSystemPtr()->workload->symtab(tc);
+const auto =
[gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse
+1 for Discourse :). Just to give a bit more context: I'm also trying to find a good forum for community engagement during my online Learning gem5 class this summer. I would like to find a platform that could be used generally for my class this summer, future iterations of the class, and general gem5 questions, as I believe there will be significant overlap between these groups. Other potential options that IMO have more cons than pros when compared to Discourse: - Slack/Teams/etc. - gitter.im - stackoverflow That said, we're open to suggestions :). Our goal is to create the most welcoming and inclusive environment possible. We'll go where our users are! Cheers, Jason On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev wrote: > Dear all, > > In an effort to better support the gem5 community, there has been a > suggestion that we drop the gem5-users mailing list and replace it with > Discourse, https://www.discourse.org/about, a web-based discussion > platform. I'm writing this email to propose this to the community and ask > for feedback on the matter. > > We have noticed that using mailing lists as our primary communication > platform is problematic. Sending an email to a list can be daunting > experience, requiring an etiquette many are not accustom to. I'm sure I'm > not the only one who feels like they are unduly bothering a large number of > people when posting to a list (like I'm doing right now :) ). This is, of > course, an unfortunate hurdle for many to get over when they encounter > problems using gem5, particularly those new to the project. I've come to > believe mailing lists are simply not a very good technology for fostering > community engagement and helping those who are running into difficulties. > Mailing lists are also difficult to search, and lack proper formatting > mechanisms to neatly display attributes such as code and output logs. > > Looking around at alternative technologies available, Discourse appears to > be a suitable replacement. For those unaware, Discourse is (essentially) a > revamp of messaging forums. It is an increasingly popular platform for > users and developers in open source projects to communicate with one > another (see LLVM's discourse as an example: https://llvm.discourse.group > ). > All-in-all, I think it's a well-designed product and contains all the > features we'd expect and need to get our work done. I can see no immediate > downsides to using it, though feedback from the community on the matter > would be greatly appreciated, particularly from those who have used > Discourse before. Dissenting opinions on the whole idea of moving away from > the gem5-user's mailing list are also welcome. > > So, let me know what you think! :) > > Please note, regardless as to any decision made, we will continue the use > of the gem5-dev mailing list for technical discussions for the foreseeable > future. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > > web: https://www.bobbybruce.net > ___ > 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 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] [Suggestion] Replace gem5-users mailing-list with Discourse
Dear all, In an effort to better support the gem5 community, there has been a suggestion that we drop the gem5-users mailing list and replace it with Discourse, https://www.discourse.org/about, a web-based discussion platform. I'm writing this email to propose this to the community and ask for feedback on the matter. We have noticed that using mailing lists as our primary communication platform is problematic. Sending an email to a list can be daunting experience, requiring an etiquette many are not accustom to. I'm sure I'm not the only one who feels like they are unduly bothering a large number of people when posting to a list (like I'm doing right now :) ). This is, of course, an unfortunate hurdle for many to get over when they encounter problems using gem5, particularly those new to the project. I've come to believe mailing lists are simply not a very good technology for fostering community engagement and helping those who are running into difficulties. Mailing lists are also difficult to search, and lack proper formatting mechanisms to neatly display attributes such as code and output logs. Looking around at alternative technologies available, Discourse appears to be a suitable replacement. For those unaware, Discourse is (essentially) a revamp of messaging forums. It is an increasingly popular platform for users and developers in open source projects to communicate with one another (see LLVM's discourse as an example: https://llvm.discourse.group). All-in-all, I think it's a well-designed product and contains all the features we'd expect and need to get our work done. I can see no immediate downsides to using it, though feedback from the community on the matter would be greatly appreciated, particularly from those who have used Discourse before. Dissenting opinions on the whole idea of moving away from the gem5-user's mailing list are also welcome. So, let me know what you think! :) Please note, regardless as to any decision made, we will continue the use of the gem5-dev mailing list for technical discussions for the foreseeable future. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net ___ 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: Add codes for pure virtual functions for compilation
Anthony Gutierrez has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/28409 )
Change subject: mem-ruby: Add codes for pure virtual functions for
compilation
..
mem-ruby: Add codes for pure virtual functions for compilation
Change-Id: Ic34f9ccf10ec28d68eed236dc6246e2ae2ef1b89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28409
Tested-by: kokoro
Reviewed-by: Anthony Gutierrez
Reviewed-by: Matt Sinclair
Maintainer: Anthony Gutierrez
---
M src/mem/ruby/system/VIPERCoalescer.cc
M src/mem/ruby/system/VIPERCoalescer.hh
2 files changed, 13 insertions(+), 0 deletions(-)
Approvals:
Anthony Gutierrez: Looks good to me, approved; Looks good to me, approved
Matt Sinclair: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/mem/ruby/system/VIPERCoalescer.cc
b/src/mem/ruby/system/VIPERCoalescer.cc
index d8977ac..cdef2b1 100644
--- a/src/mem/ruby/system/VIPERCoalescer.cc
+++ b/src/mem/ruby/system/VIPERCoalescer.cc
@@ -76,6 +76,16 @@
{
}
+void
+VIPERCoalescer::issueRequest(CoalescedRequest* crequest)
+{
+}
+
+void
+VIPERCoalescer::issueMemSyncRequest(PacketPtr pkt)
+{
+}
+
// Places an uncoalesced packet in uncoalescedTable. If the packet is a
// special type (MemFence, scoping, etc), it is issued immediately.
RequestStatus
diff --git a/src/mem/ruby/system/VIPERCoalescer.hh
b/src/mem/ruby/system/VIPERCoalescer.hh
index 2b6e86e..814166d 100644
--- a/src/mem/ruby/system/VIPERCoalescer.hh
+++ b/src/mem/ruby/system/VIPERCoalescer.hh
@@ -57,6 +57,9 @@
typedef VIPERCoalescerParams Params;
VIPERCoalescer(const Params *);
~VIPERCoalescer();
+
+void issueMemSyncRequest(PacketPtr pkt);
+void issueRequest(CoalescedRequest* crequest) override;
void wbCallback(Addr address);
void invCallback(Addr address);
RequestStatus makeRequest(PacketPtr pkt);
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/28409
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: Ic34f9ccf10ec28d68eed236dc6246e2ae2ef1b89
Gerrit-Change-Number: 28409
Gerrit-PatchSet: 6
Gerrit-Owner: Anthony Gutierrez
Gerrit-Reviewer: Alexandru Duțu
Gerrit-Reviewer: Anthony Gutierrez
Gerrit-Reviewer: Bradford Beckmann
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Matt Sinclair
Gerrit-Reviewer: Matthew Poremba
Gerrit-Reviewer: Tony Gutierrez
Gerrit-Reviewer: Tuan Ta
Gerrit-Reviewer: Xianwei Zhang
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: update memory interfaces to support GPU ISA
Anthony Gutierrez has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/28408 )
Change subject: mem-ruby: update memory interfaces to support GPU ISA
..
mem-ruby: update memory interfaces to support GPU ISA
This patch deprecates HSA-based memory request types and adds new
types that can be used by real ISA instructions.
Change-Id: Ie107a69d8a35e9de0853f1407392ad01a8b3e930
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28408
Reviewed-by: Anthony Gutierrez
Maintainer: Anthony Gutierrez
Tested-by: kokoro
---
M src/mem/packet.cc
M src/mem/packet.hh
M src/mem/request.hh
M src/mem/ruby/slicc_interface/RubyRequest.hh
4 files changed, 45 insertions(+), 131 deletions(-)
Approvals:
Anthony Gutierrez: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/mem/packet.cc b/src/mem/packet.cc
index 2d69ba2..1c1da21 100644
--- a/src/mem/packet.cc
+++ b/src/mem/packet.cc
@@ -181,6 +181,10 @@
{ 0, InvalidCmd, "Deprecated_MessageResp" },
/* MemFenceReq -- for synchronization requests */
{SET2(IsRequest, NeedsResponse), MemFenceResp, "MemFenceReq"},
+/* MemSyncReq */
+{SET2(IsRequest, NeedsResponse), MemSyncResp, "MemSyncReq"},
+/* MemSyncResp */
+{SET1(IsResponse), InvalidCmd, "MemSyncResp"},
/* MemFenceResp -- for synchronization responses */
{SET1(IsResponse), InvalidCmd, "MemFenceResp"},
/* Cache Clean Request -- Update with the latest data all existing
diff --git a/src/mem/packet.hh b/src/mem/packet.hh
index d390c00..42d286a 100644
--- a/src/mem/packet.hh
+++ b/src/mem/packet.hh
@@ -110,6 +110,8 @@
SwapResp,
// MessageReq and MessageResp are deprecated.
MemFenceReq = SwapResp + 3,
+MemSyncReq, // memory synchronization request (e.g., cache
invalidate)
+MemSyncResp, // memory synchronization response
MemFenceResp,
CleanSharedReq,
CleanSharedResp,
diff --git a/src/mem/request.hh b/src/mem/request.hh
index 01252bf..4e0ba97 100644
--- a/src/mem/request.hh
+++ b/src/mem/request.hh
@@ -110,7 +110,7 @@
* STRICT_ORDER flag should be set if such reordering is
* undesirable.
*/
-UNCACHEABLE= 0x0400,
+UNCACHEABLE = 0x0400,
/**
* The request is required to be strictly ordered by CPU
* models and is non-speculative.
@@ -216,35 +216,30 @@
};
/** @} */
-typedef uint32_t MemSpaceConfigFlagsType;
-typedef ::Flags MemSpaceConfigFlags;
+typedef uint64_t CacheCoherenceFlagsType;
+typedef ::Flags CacheCoherenceFlags;
-enum : MemSpaceConfigFlagsType {
-/** Has a synchronization scope been set? */
-SCOPE_VALID= 0x0001,
-/** Access has Wavefront scope visibility */
-WAVEFRONT_SCOPE= 0x0002,
-/** Access has Workgroup scope visibility */
-WORKGROUP_SCOPE= 0x0004,
-/** Access has Device (e.g., GPU) scope visibility */
-DEVICE_SCOPE = 0x0008,
-/** Access has System (e.g., CPU + GPU) scope visibility */
-SYSTEM_SCOPE = 0x0010,
-
-/** Global Segment */
-GLOBAL_SEGMENT = 0x0020,
-/** Group Segment */
-GROUP_SEGMENT = 0x0040,
-/** Private Segment */
-PRIVATE_SEGMENT= 0x0080,
-/** Kergarg Segment */
-KERNARG_SEGMENT= 0x0100,
-/** Readonly Segment */
-READONLY_SEGMENT = 0x0200,
-/** Spill Segment */
-SPILL_SEGMENT = 0x0400,
-/** Arg Segment */
-ARG_SEGMENT= 0x0800,
+/**
+ * These bits are used to set the coherence policy
+ * for the GPU and are encoded in the GCN3 instructions.
+ * See the AMD GCN3 ISA Architecture Manual for more
+ * details.
+ *
+ * SLC: System Level Coherent. Accesses are forced to miss in
+ * the L2 cache and are coherent with system memory.
+ *
+ * GLC: Globally Coherent. Controls how reads and writes are
+ * handled by the L1 cache. Global here referes to the
+ * data being visible globally on the GPU (i.e., visible
+ * to all WGs).
+ *
+ * For atomics, the GLC bit is used to distinguish between
+ * between atomic return/no-return operations.
+ */
+enum : CacheCoherenceFlagsType {
+/** user-policy flags */
+SLC_BIT = 0x0080,
+GLC_BIT = 0x0100,
};
using LocalAccessor =
@@ -305,8 +300,8 @@
/** Flag structure for the request. */
Flags _flags;
-/** Memory space configuraiton flag structure for the request. */
-MemSpaceConfigFlags _memSpaceConfigFlags;
+/** Flags that
[gem5-dev] Change in gem5/gem5[develop]: mem-cache: Make indexing policies range-aware
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/30095 )
Change subject: mem-cache: Make indexing policies range-aware
..
mem-cache: Make indexing policies range-aware
Change-Id: Ibdee97be47f9bd4161d74c5625ab7d5036bad689
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/tags/indexing_policies/IndexingPolicies.py
M src/mem/cache/tags/indexing_policies/base.cc
M src/mem/cache/tags/indexing_policies/base.hh
M src/mem/cache/tags/indexing_policies/set_associative.cc
M src/mem/cache/tags/indexing_policies/set_associative.hh
M src/mem/cache/tags/indexing_policies/skewed_associative.cc
M src/mem/cache/tags/indexing_policies/skewed_associative.hh
7 files changed, 85 insertions(+), 30 deletions(-)
diff --git a/src/mem/cache/tags/indexing_policies/IndexingPolicies.py
b/src/mem/cache/tags/indexing_policies/IndexingPolicies.py
index 7414ddf..058a1c9 100644
--- a/src/mem/cache/tags/indexing_policies/IndexingPolicies.py
+++ b/src/mem/cache/tags/indexing_policies/IndexingPolicies.py
@@ -42,6 +42,10 @@
# Get the associativity
assoc = Param.Int(Parent.assoc, "associativity")
+# Get the address range used by the parent (cache)
+addr_ranges = VectorParam.AddrRange(Parent.addr_ranges,
+"Address range used by the cache")
+
class SetAssociative(BaseIndexingPolicy):
type = 'SetAssociative'
cxx_class = 'SetAssociative'
diff --git a/src/mem/cache/tags/indexing_policies/base.cc
b/src/mem/cache/tags/indexing_policies/base.cc
index 6a799e6..25fd0d0 100644
--- a/src/mem/cache/tags/indexing_policies/base.cc
+++ b/src/mem/cache/tags/indexing_policies/base.cc
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2018 Inria
- * Copyright (c) 2012-2014,2017 ARM Limited
+ * Copyright (c) 2012-2014,2017,2020 ARM Limited
* All rights reserved.
*
* The license below extends only to copyright in the software and shall
@@ -48,6 +48,7 @@
#include
+#include "base/channel_addr.hh"
#include "base/intmath.hh"
#include "base/logging.hh"
#include "mem/cache/replacement_policies/replaceable_entry.hh"
@@ -56,7 +57,8 @@
: SimObject(p), assoc(p->assoc),
numSets(p->size / (p->entry_size * assoc)),
setShift(floorLog2(p->entry_size)), setMask(numSets - 1),
sets(numSets),
- tagShift(setShift + floorLog2(numSets))
+ tagShift(setShift + floorLog2(numSets)),
+ range(p->addr_ranges)
{
fatal_if(!isPowerOf2(numSets), "# of sets must be non-zero and a
power " \
"of 2");
@@ -95,5 +97,22 @@
Addr
BaseIndexingPolicy::extractTag(const Addr addr) const
{
-return (addr >> tagShift);
+// addr is physical, tags are extracted from relative
+ChannelAddr ch_addr(range, addr);
+return Addr(ch_addr) >> tagShift;
+}
+
+std::vector
+BaseIndexingPolicy::getPossibleEntries(const Addr addr) const
+{
+return getPossibleEntries(ChannelAddr(range, addr));
+}
+
+Addr
+BaseIndexingPolicy::regenerateAddr(const Addr tag,
+ const ReplaceableEntry* entry) const
+{
+// _regenerateAddr returns an offset into the range
+ChannelAddr ch_addr = getChannelAddr(tag, entry);
+return ch_addr.getPA(range);
}
diff --git a/src/mem/cache/tags/indexing_policies/base.hh
b/src/mem/cache/tags/indexing_policies/base.hh
index 9a56b54..803ff61 100644
--- a/src/mem/cache/tags/indexing_policies/base.hh
+++ b/src/mem/cache/tags/indexing_policies/base.hh
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2018 Inria
- * Copyright (c) 2012-2014,2017 ARM Limited
+ * Copyright (c) 2012-2014,2017,2020 ARM Limited
* All rights reserved.
*
* The license below extends only to copyright in the software and shall
@@ -49,6 +49,7 @@
#include
+#include "base/channel_addr.hh"
#include "params/BaseIndexingPolicy.hh"
#include "sim/sim_object.hh"
@@ -93,6 +94,33 @@
*/
const int tagShift;
+/**
+ * The range covered by this indexing policy's cache.
+ */
+const AddrRange range;
+
+/**
+ * Find all possible entries for insertion and replacement of a
+ * relative address in this range. Called by getPossibleEntries
+ * with a relative address.
+ *
+ * @param addr The addr to a find possible entries for.
+ * @return The possible entries.
+ */
+virtual std::vector getPossibleEntries(
+const ChannelAddr ch_addr) const = 0;
+
+/**
+ * Regenerate an entry's address from its tag and assigned indexing
bits.
+ * Called by regenerateAddr, should produce a relative address
+ *
+ * @param tag The tag bits.
+ * @param entry The entry.
+ * @return the entry's original address relative to the range.
+ */
+virtual ChannelAddr getChannelAddr(
+const Addr tag, const ReplaceableEntry* entry) const = 0;
+
public:
/**
* Convenience typedef.
@@ -143,8 +171,7 @@
* @param addr The addr to
[gem5-dev] Change in gem5/gem5[develop]: mem-cache: Add support for blocking the cache on fills
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/30096 )
Change subject: mem-cache: Add support for blocking the cache on fills
..
mem-cache: Add support for blocking the cache on fills
Change-Id: I0b15139cf457e4c34d4f11a6b95ca4f6bd64e4ce
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/Cache.py
M src/mem/cache/base.cc
M src/mem/cache/base.hh
3 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/src/mem/cache/Cache.py b/src/mem/cache/Cache.py
index 4f4e445..a55ed2a 100644
--- a/src/mem/cache/Cache.py
+++ b/src/mem/cache/Cache.py
@@ -79,6 +79,9 @@
tag_latency = Param.Cycles("Tag lookup latency")
data_latency = Param.Cycles("Data access latency")
+block_on_fills = Param.Bool(False, "Block the cache for further "
+"read/writes until fill completes")
+fill_latency = Param.Cycles(Self.data_latency, "Fill latency")
response_latency = Param.Cycles("Latency for the return path on a
miss");
warmup_percentage = Param.Percent(0,
diff --git a/src/mem/cache/base.cc b/src/mem/cache/base.cc
index 0187703..6614d16 100644
--- a/src/mem/cache/base.cc
+++ b/src/mem/cache/base.cc
@@ -92,7 +92,8 @@
lookupLatency(p->tag_latency),
dataLatency(p->data_latency),
forwardLatency(p->tag_latency),
- fillLatency(p->data_latency),
+ blockOnFills(p->block_on_fills),
+ fillLatency(p->fill_latency),
responseLatency(p->response_latency),
sequentialAccess(p->sequential_access),
numTarget(p->tgts_per_mshr),
@@ -104,6 +105,8 @@
noTargetMSHR(nullptr),
missCount(p->max_miss_count),
addrRanges(p->addr_ranges.begin(), p->addr_ranges.end()),
+ dataArrayUnblockEvent([this]{ clearBlocked(Blocked_DataArray); },
+name()),
system(p->system),
stats(*this)
{
@@ -1171,8 +1174,15 @@
// When the packet metadata arrives, the tag lookup will be done
while
// the payload is arriving. Then the block will be ready to access
as
// soon as the fill is done
-blk->setWhenReady(clockEdge(fillLatency) + pkt->headerDelay +
-std::max(cyclesToTicks(tag_latency),
(uint64_t)pkt->payloadDelay));
+const Tick fill_done_tick = clockEdge(fillLatency) +
pkt->headerDelay +
+std::max(cyclesToTicks(tag_latency),
(uint64_t)pkt->payloadDelay);
+
+if (system->isTimingMode() && blockOnFills) {
+setBlocked(Blocked_DataArray);
+reschedule(dataArrayUnblockEvent, clockEdge(fillLatency),
true);
+}
+
+blk->setWhenReady(fill_done_tick);
return true;
} else if (pkt->cmd == MemCmd::CleanEvict) {
@@ -1245,8 +1255,15 @@
// When the packet metadata arrives, the tag lookup will be done
while
// the payload is arriving. Then the block will be ready to access
as
// soon as the fill is done
-blk->setWhenReady(clockEdge(fillLatency) + pkt->headerDelay +
-std::max(cyclesToTicks(tag_latency),
(uint64_t)pkt->payloadDelay));
+const Tick fill_done_tick = clockEdge(fillLatency) +
pkt->headerDelay +
+std::max(cyclesToTicks(tag_latency),
(uint64_t)pkt->payloadDelay);
+
+if (system->isTimingMode() && blockOnFills) {
+setBlocked(Blocked_DataArray);
+schedule(dataArrayUnblockEvent, clockEdge(fillLatency));
+}
+
+blk->setWhenReady(fill_done_tick);
// If this a write-through packet it will be sent to cache below
return !pkt->writeThrough();
@@ -1383,6 +1400,10 @@
DPRINTF(Cache, "Block addr %#llx (%s) moving from state %x to %s\n",
addr, is_secure ? "s" : "ns", old_state, blk->print());
+// The block will be ready when the payload arrives and the fill is
done
+const Tick fill_done_tick = clockEdge(fillLatency) + pkt->headerDelay +
+pkt->payloadDelay;
+
// if we got new data, copy it in (checking for a read response
// and a response that has data is the same in the end)
if (pkt->isRead()) {
@@ -1391,10 +1412,12 @@
assert(pkt->getSize() == blkSize);
pkt->writeDataToBlock(blk->data, blkSize);
+if (system->isTimingMode() && blockOnFills) {
+setBlocked(Blocked_DataArray);
+schedule(dataArrayUnblockEvent, clockEdge(fillLatency));
+}
}
-// The block will be ready when the payload arrives and the fill is
done
-blk->setWhenReady(clockEdge(fillLatency) + pkt->headerDelay +
- pkt->payloadDelay);
+blk->setWhenReady(fill_done_tick);
return blk;
}
diff --git a/src/mem/cache/base.hh b/src/mem/cache/base.hh
index 3efc7c7..1f02c86 100644
--- a/src/mem/cache/base.hh
+++ b/src/mem/cache/base.hh
@@ -105,6 +105,7 @@
Blocked_NoMSHRs = MSHRQueue_MSHRs,
[gem5-dev] Change in gem5/gem5[develop]: mem-cache: Add support for blocking on reads
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/30097 )
Change subject: mem-cache: Add support for blocking on reads
..
mem-cache: Add support for blocking on reads
Change-Id: I1aab914956640e38e72df0da392cfaa9f95be0d6
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/Cache.py
M src/mem/cache/base.cc
M src/mem/cache/base.hh
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mem/cache/Cache.py b/src/mem/cache/Cache.py
index a55ed2a..14668ea 100644
--- a/src/mem/cache/Cache.py
+++ b/src/mem/cache/Cache.py
@@ -79,6 +79,10 @@
tag_latency = Param.Cycles("Tag lookup latency")
data_latency = Param.Cycles("Data access latency")
+block_on_reads = Param.Bool(False, "Block the cache for further "
+"read/writes until read completes")
+data_read_latency = Param.Cycles(Self.data_latency,
+ "Data array read latency")
block_on_fills = Param.Bool(False, "Block the cache for further "
"read/writes until fill completes")
fill_latency = Param.Cycles(Self.data_latency, "Fill latency")
diff --git a/src/mem/cache/base.cc b/src/mem/cache/base.cc
index 6614d16..5a0075c 100644
--- a/src/mem/cache/base.cc
+++ b/src/mem/cache/base.cc
@@ -92,6 +92,8 @@
lookupLatency(p->tag_latency),
dataLatency(p->data_latency),
forwardLatency(p->tag_latency),
+ blockOnReads(p->block_on_reads),
+ dataArrayReadLatency(p->data_read_latency),
blockOnFills(p->block_on_fills),
fillLatency(p->fill_latency),
responseLatency(p->response_latency),
@@ -219,6 +221,10 @@
assert(pkt->payloadDelay == 0);
pkt->makeTimingResponse();
+if (blockOnReads && pkt->isRead()) {
+setBlocked(Blocked_DataArray);
+schedule(dataArrayUnblockEvent,
clockEdge(dataArrayReadLatency));
+}
// In this case we are considering request_time that takes
// into account the delay of the xbar, if any, and just
diff --git a/src/mem/cache/base.hh b/src/mem/cache/base.hh
index 1f02c86..6d9b602 100644
--- a/src/mem/cache/base.hh
+++ b/src/mem/cache/base.hh
@@ -858,6 +858,9 @@
*/
const Cycles forwardLatency;
+const bool blockOnReads;
+const Cycles dataArrayReadLatency;
+
const bool blockOnFills;
/**
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30097
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: I1aab914956640e38e72df0da392cfaa9f95be0d6
Gerrit-Change-Number: 30097
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
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]: base: Fix ChannelAddr<->Addr conversation
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/30094 )
Change subject: base: Fix ChannelAddr<->Addr conversation
..
base: Fix ChannelAddr<->Addr conversation
Previously calculating a ChannelAddr from an Addr and converting back
ignored that the start of the address range can be different than
0. After this change, ChannelAddr is always an address in the
continuous range [0, MaxChannelAddr).
Change-Id: Icd8b611c43da7f8ff102c1872b175be59ece7ae9
Signed-off-by: Nikos Nikoleris
---
M src/base/channel_addr.hh
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/base/channel_addr.hh b/src/base/channel_addr.hh
index 06fae72..56812c7 100644
--- a/src/base/channel_addr.hh
+++ b/src/base/channel_addr.hh
@@ -63,14 +63,14 @@
constexpr ChannelAddr() : a(0) { }
ChannelAddr(const AddrRange , Addr _a)
-: a(range.removeIntlvBits(_a)) {}
+: a(range.removeIntlvBits(_a) - range.start()) {}
ChannelAddr(const ChannelAddr &) = default;
ChannelAddr =(const ChannelAddr &) = default;
Addr getPA(const AddrRange ) const {
-return range.addIntlvBits(a);
+return range.addIntlvBits(a) + range.start();
}
constexpr ChannelAddr operator|(const Type b) const {
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30094
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: Icd8b611c43da7f8ff102c1872b175be59ece7ae9
Gerrit-Change-Number: 30094
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
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]: mem: Default the SE translating port proxy alloc method to NextPage.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/29399 ) Change subject: mem: Default the SE translating port proxy alloc method to NextPage. .. mem: Default the SE translating port proxy alloc method to NextPage. This is what's used in 99% of cases, so it makes sense to make it the default. Change-Id: I51535b3387d1c1a0d1d89e77cfca10363388b472 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29399 Reviewed-by: Matthew Poremba Maintainer: Gabe Black Tested-by: kokoro --- M src/mem/se_translating_port_proxy.hh 1 file changed, 1 insertion(+), 1 deletion(-) Approvals: Matthew Poremba: Looks good to me, approved Gabe Black: Looks good to me, approved kokoro: Regressions pass diff --git a/src/mem/se_translating_port_proxy.hh b/src/mem/se_translating_port_proxy.hh index 0fe3212..41f92a6 100644 --- a/src/mem/se_translating_port_proxy.hh +++ b/src/mem/se_translating_port_proxy.hh @@ -60,7 +60,7 @@ bool fixupAddr(Addr addr, BaseTLB::Mode mode) const override; public: -SETranslatingPortProxy(ThreadContext *tc, AllocType alloc, +SETranslatingPortProxy(ThreadContext *tc, AllocType alloc=NextPage, Request::Flags _flags=0); }; -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/29399 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: I51535b3387d1c1a0d1d89e77cfca10363388b472 Gerrit-Change-Number: 29399 Gerrit-PatchSet: 2 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bradford Beckmann Gerrit-Reviewer: Ciro Santilli Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini 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
