[gem5-dev] Change in gem5/gem5[develop]: util: add pkg-config to ubuntu all-dependencies Dockerfiles

2020-09-21 Thread Ciro Santilli (Gerrit) via gem5-dev 
Ciro Santilli has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34777 )


Change subject: util: add pkg-config to ubuntu all-dependencies Dockerfiles
..

util: add pkg-config to ubuntu all-dependencies Dockerfiles

Without this, HDF5 is not built, e.g. a run such as
http://jenkins.gem5.org/job/Nightly/68/console contains:

Checking for hdf5-serial using pkg-config... pkg-config not found
Checking for hdf5 using pkg-config... pkg-config not found
Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) no
Warning: Couldn't find any HDF5 C++ libraries. Disabling
 HDF5 support.

This is done to increase coverage a bit, and serve as dependency
documentation to users.

Change-Id: Ibf820a3aa76c291201646924ee181615a162
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34777
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M util/dockerfiles/ubuntu-18.04_all-dependencies/Dockerfile
M util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
2 files changed, 2 insertions(+), 2 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/util/dockerfiles/ubuntu-18.04_all-dependencies/Dockerfile  
b/util/dockerfiles/ubuntu-18.04_all-dependencies/Dockerfile

index 282805d..1259f2e 100644
--- a/util/dockerfiles/ubuntu-18.04_all-dependencies/Dockerfile
+++ b/util/dockerfiles/ubuntu-18.04_all-dependencies/Dockerfile
@@ -31,4 +31,4 @@
 RUN apt -y install build-essential git m4 scons zlib1g zlib1g-dev \
 libprotobuf-dev protobuf-compiler libprotoc-dev  
libgoogle-perftools-dev \
 python-dev python python-six doxygen libboost-all-dev  
libhdf5-serial-dev \

-python-pydot libpng-dev libelf-dev
+python-pydot libpng-dev libelf-dev pkg-config
diff --git a/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile  
b/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile

index 283d356..3facf7e 100644
--- a/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
+++ b/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
@@ -32,4 +32,4 @@
 RUN apt -y install build-essential git m4 scons zlib1g zlib1g-dev \
 libprotobuf-dev protobuf-compiler libprotoc-dev  
libgoogle-perftools-dev \

 python3-dev python3-six python-is-python3 doxygen libboost-all-dev \
-libhdf5-serial-dev python3-pydot libpng-dev libelf-dev
+libhdf5-serial-dev python3-pydot libpng-dev libelf-dev pkg-config

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34777
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: Ibf820a3aa76c291201646924ee181615a162
Gerrit-Change-Number: 34777
Gerrit-PatchSet: 3
Gerrit-Owner: Ciro Santilli 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Ciro Santilli 
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]: base,sim: implement a faster mutex for single thread case

2020-09-21 Thread Earl Ou (Gerrit) via gem5-dev 
Earl Ou has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34915 )



Change subject: base,sim: implement a faster mutex for single thread case
..

base,sim: implement a faster mutex for single thread case

This change applies an atomic variable to check if we really need to
obtain a mutex, and uses a condition variable to notify.

See about 5% improvement in the simulation speed.

Change-Id: I7e165987dcb587b27fae90978b9b3fde6f5563ef
---
A src/base/fast_mutex.hh
M src/sim/eventq.cc
M src/sim/eventq.hh
3 files changed, 86 insertions(+), 3 deletions(-)



diff --git a/src/base/fast_mutex.hh b/src/base/fast_mutex.hh
new file mode 100644
index 000..b003072
--- /dev/null
+++ b/src/base/fast_mutex.hh
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2020 Google, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __BASE_FAST_MUTEXT_HH__
+#define __BASE_FAST_MUTEXT_HH__
+
+#include 
+#include 
+#include 
+
+/*
+ * The FastMutex uses an atomic flag to check if we really need to obtain a
+ * mutex lock. For most cases without multi-threads event queues, e.g.  
non-KVM

+ * simulation, this avoid the system call and speed up the simulation.
+ */
+class FastMutex {
+  private:
+// A flag to record the current status:
+// 0: no one has the lock
+// 1: exactly one thread has the lock
+// >1: more than one threads are waiting for the lock.
+std::atomic flag;
+std::mutex m;
+std::condition_variable cv;
+
+bool test_and_set(int expected, int desired) {
+return flag.compare_exchange_strong(expected, desired);
+}
+
+  public:
+FastMutex() : flag(0) {}
+
+void
+lock()
+{
+while (!test_and_set(0, 1)) {
+std::unique_lock ul(m);
+if (flag++ == 0)  // in case flag is set to 0 before we get m.
+break;
+cv.wait(ul);
+}
+}
+
+void
+unlock()
+{
+if (test_and_set(1, 0))
+return;
+
+{
+std::lock_guard g(m);
+flag = 0;
+}
+cv.notify_all();
+}
+};
+
+#endif // __BASE_FAST_MUTEXT_HH__
diff --git a/src/sim/eventq.cc b/src/sim/eventq.cc
index bc4864c..adce51e 100644
--- a/src/sim/eventq.cc
+++ b/src/sim/eventq.cc
@@ -32,6 +32,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/src/sim/eventq.hh b/src/sim/eventq.hh
index aa54722..ecd9b78 100644
--- a/src/sim/eventq.hh
+++ b/src/sim/eventq.hh
@@ -41,10 +41,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include "base/debug.hh"
+#include "base/fast_mutex.hh"
 #include "base/flags.hh"
 #include "base/types.hh"
 #include "debug/Event.hh"
@@ -622,7 +622,7 @@
 Tick _curTick;

 //! Mutex to protect async queue.
-std::mutex async_queue_mutex;
+FastMutex async_queue_mutex;

 //! List of events added by other threads to this event queue.
 std::list async_queue;
@@ -647,7 +647,7 @@
  * @see EventQueue::lock()
  * @see EventQueue::unlock()
  */
-std::mutex service_mutex;
+FastMutex service_mutex;

 //! Insert / remove event from the queue. Should only be called
 //! by thread operating this queue.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34915
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:

[gem5-dev] Build failed in Jenkins: Nightly #75

2020-09-21 Thread jenkins-no-reply--- via gem5-dev 
See 

Changes:

[Bobby R. Bruce] util: Removed libelf-dev dep from Dockerfiles

[Bobby R. Bruce] tests,base: Fixed unittests for .fast


--
[...truncated 157.07 KB...]
[ RUN  ] StrTest.EatEndWhiteNoTrailingWhitespace
[   OK ] StrTest.EatEndWhiteNoTrailingWhitespace (0 ms)
[ RUN  ] StrTest.EatWhite
[   OK ] StrTest.EatWhite (0 ms)
[ RUN  ] StrTest.EatWhiteNoWhitespace
[   OK ] StrTest.EatWhiteNoWhitespace (0 ms)
[ RUN  ] StrTest.ToLower
[   OK ] StrTest.ToLower (0 ms)
[ RUN  ] StrTest.SplitFirst
[   OK ] StrTest.SplitFirst (0 ms)
[ RUN  ] StrTest.SplitFirstNoChar
[   OK ] StrTest.SplitFirstNoChar (0 ms)
[ RUN  ] StrTest.SplitFirstOnFirstChar
[   OK ] StrTest.SplitFirstOnFirstChar (0 ms)
[ RUN  ] StrTest.SplitLast
[   OK ] StrTest.SplitLast (0 ms)
[ RUN  ] StrTest.SplitLastNoChar
[   OK ] StrTest.SplitLastNoChar (0 ms)
[ RUN  ] StrTest.SplitLastOnLastChar
[   OK ] StrTest.SplitLastOnLastChar (0 ms)
[ RUN  ] StrTest.TokenizeOnSpace
[   OK ] StrTest.TokenizeOnSpace (0 ms)
[ RUN  ] StrTest.TokenizeOnSpaceIgnFalse
[   OK ] StrTest.TokenizeOnSpaceIgnFalse (0 ms)
[ RUN  ] StrTest.TokenizedTokenDoesNotExist
[   OK ] StrTest.TokenizedTokenDoesNotExist (0 ms)
[ RUN  ] StrTest.ToNumber8BitInt
[   OK ] StrTest.ToNumber8BitInt (0 ms)
[ RUN  ] StrTest.ToNumber8BitIntStringOutOfRange
[   OK ] StrTest.ToNumber8BitIntStringOutOfRange (0 ms)
[ RUN  ] StrTest.ToNumber8BitIntInvalidString
[   OK ] StrTest.ToNumber8BitIntInvalidString (1 ms)
[ RUN  ] StrTest.ToNumberUnsigned8BitInt
[   OK ] StrTest.ToNumberUnsigned8BitInt (0 ms)
[ RUN  ] StrTest.ToNumberUnsigned8BitIntNegative
[   OK ] StrTest.ToNumberUnsigned8BitIntNegative (0 ms)
[ RUN  ] StrTest.ToNumber64BitInt
[   OK ] StrTest.ToNumber64BitInt (0 ms)
[ RUN  ] StrTest.ToNumber64BitIntInvalidString
[   OK ] StrTest.ToNumber64BitIntInvalidString (0 ms)
[ RUN  ] StrTest.ToNumberFloat
[   OK ] StrTest.ToNumberFloat (0 ms)
[ RUN  ] StrTest.ToNumberFloatIntegerString
[   OK ] StrTest.ToNumberFloatIntegerString (0 ms)
[ RUN  ] StrTest.ToNumberFloatNegative
[   OK ] StrTest.ToNumberFloatNegative (0 ms)
[ RUN  ] StrTest.ToNumberDouble
[   OK ] StrTest.ToNumberDouble (0 ms)
[ RUN  ] StrTest.ToNumberDoubleIntegerString
[   OK ] StrTest.ToNumberDoubleIntegerString (0 ms)
[ RUN  ] StrTest.ToNumberDoubleNegative
[   OK ] StrTest.ToNumberDoubleNegative (0 ms)
[ RUN  ] StrTest.ToBoolTrue
[   OK ] StrTest.ToBoolTrue (0 ms)
[ RUN  ] StrTest.ToBoolFalse
[   OK ] StrTest.ToBoolFalse (0 ms)
[ RUN  ] StrTest.ToBoolInvalidInput
[   OK ] StrTest.ToBoolInvalidInput (0 ms)
[ RUN  ] StrTest.QuoteStringNoSpace
[   OK ] StrTest.QuoteStringNoSpace (0 ms)
[ RUN  ] StrTest.QuoteStringWithSpace
[   OK ] StrTest.QuoteStringWithSpace (0 ms)
[ RUN  ] StrTest.QuoteQuotedString
[   OK ] StrTest.QuoteQuotedString (0 ms)
[ RUN  ] StrTest.QuoteStringWithTab
[   OK ] StrTest.QuoteStringWithTab (0 ms)
[ RUN  ] StrTest.StartswithDoubleStringDoesStartWith
[   OK ] StrTest.StartswithDoubleStringDoesStartWith (0 ms)
[ RUN  ] StrTest.StartswithDoubleStringDoesNotStartWith
[   OK ] StrTest.StartswithDoubleStringDoesNotStartWith (0 ms)
[ RUN  ] StrTest.StartswithDoubleCharArrayDoesStartWith
[   OK ] StrTest.StartswithDoubleCharArrayDoesStartWith (0 ms)
[ RUN  ] StrTest.StartswithDoubleCharArrayDoesNotStartWith
[   OK ] StrTest.StartswithDoubleCharArrayDoesNotStartWith (0 ms)
[ RUN  ] StrTest.StartswithStringCharArrayDoesStartWith
[   OK ] StrTest.StartswithStringCharArrayDoesStartWith (0 ms)
[ RUN  ] StrTest.StartswithStringCharArrayDoesNotStartWith
[   OK ] StrTest.StartswithStringCharArrayDoesNotStartWith (0 ms)
[--] 42 tests from StrTest (1 ms total)

[--] Global test environment tear-down
[==] 42 tests from 1 test case ran. (1 ms total)
[  PASSED  ] 42 tests.
 [ CXX] NULL/sim/proxy_ptr.test.cc -> .fo
 [LINK]  -> NULL/base/trie.test.fast.unstripped
 [   STRIP] NULL/base/trie.test.fast.unstripped -> .fast
 [LINK]  -> NULL/sim/byteswap.test.fast.unstripped
build/NULL/base/trie.test.fast 
--gtest_output=xml:build/NULL/unittests.fast/base/trie.test.xml
Running main() from gtest_main.cc
[==] Running 7 tests from 1 test case.
[--] Global test environment set-up.
[--] 7 tests from TrieTestData
[ RUN  ] TrieTestData.Empty
[   OK ] TrieTestData.Empty (0 ms)
[ RUN  ] TrieTestData.SingleEntry
[   OK ] TrieTestData.SingleEntry (0 ms)
[ RUN  ] TrieTestData.TwoOverlappingEntries
[   OK ] TrieTestData.TwoOverlappingEntries (0 ms)
[ RUN  ] TrieTestData.TwoOverlappingEntriesReversed
[   OK ] TrieTestData.TwoOverlappingEntriesRevers

[gem5-dev] Change in gem5/gem5[release-staging-v20.1.0.0]: tests,base: Fixed unittests for .fast

2020-09-21 Thread Bobby R. Bruce (Gerrit) via gem5-dev 
Bobby R. Bruce has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34898 )


Change subject: tests,base: Fixed unittests for .fast
..

tests,base: Fixed unittests for .fast

unittests.fast, unittests.prof, and unittests.perf had failing tests due
to the stripping of asserts via compiler optimization. This patch alters
the unittests to skip these tests when TRACING_ON == 0.

Change-Id: I2d4ab795ecfc2c4556b5eb1877635409d0836ec6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34898
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/base/intmath.test.cc
M src/base/sat_counter.test.cc
2 files changed, 11 insertions(+), 1 deletion(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/base/intmath.test.cc b/src/base/intmath.test.cc
index 5740bd4..4e88b00 100644
--- a/src/base/intmath.test.cc
+++ b/src/base/intmath.test.cc
@@ -72,11 +72,17 @@
 EXPECT_EQ(0, floorLog2((int64_t)1));
 }

+/* The IntmathDeathTest floorLog2 test is dependent on an assert being
+ * triggered. We therefore only run this test for .debug and .opt (where
+ * `TRACING_ON == 1`).
+ */
+#if TRACING_ON
 TEST(IntmathDeathTest, floorLog2)
 {
 // Verify a non-positive input triggers an assert.
 EXPECT_DEATH_IF_SUPPORTED(floorLog2(0), "x > 0");
 }
+#endif

 TEST(IntmathTest, ceilLog2)
 {
diff --git a/src/base/sat_counter.test.cc b/src/base/sat_counter.test.cc
index 6de7ef7..214b015 100644
--- a/src/base/sat_counter.test.cc
+++ b/src/base/sat_counter.test.cc
@@ -185,9 +185,13 @@
 ASSERT_EQ(counter, 0);

 // Make sure the counters cannot be shifted by negative numbers, since
-// that is undefined behaviour
+// that is undefined behaviour. As these tests depend on asserts  
failing,

+// these tests are only functional if `TRACING_ON == 1`, when gem5 is
+// compiled as `debug` or `opt`.
+#if TRACING_ON
 ASSERT_DEATH(counter >>= -1, "");
 ASSERT_DEATH(counter <<= -1, "");
+#endif
 }

 /**

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34898
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I2d4ab795ecfc2c4556b5eb1877635409d0836ec6
Gerrit-Change-Number: 34898
Gerrit-PatchSet: 2
Gerrit-Owner: Bobby R. Bruce 
Gerrit-Reviewer: Bobby R. 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[release-staging-v20.1.0.0]: tests,base: Fixed unittests for .fast

2020-09-21 Thread Bobby R. Bruce (Gerrit) via gem5-dev 
Bobby R. Bruce has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34898 )



Change subject: tests,base: Fixed unittests for .fast
..

tests,base: Fixed unittests for .fast

unittests.fast, unittests.prof, and unittests.perf had failing tests due
to the stripping of asserts via compiler optimization. This patch alters
the unittests to skip these tests when TRACING_ON == 0.

Change-Id: I2d4ab795ecfc2c4556b5eb1877635409d0836ec6
---
M src/base/intmath.test.cc
M src/base/sat_counter.test.cc
2 files changed, 11 insertions(+), 1 deletion(-)



diff --git a/src/base/intmath.test.cc b/src/base/intmath.test.cc
index 5740bd4..4e88b00 100644
--- a/src/base/intmath.test.cc
+++ b/src/base/intmath.test.cc
@@ -72,11 +72,17 @@
 EXPECT_EQ(0, floorLog2((int64_t)1));
 }

+/* The IntmathDeathTest floorLog2 test is dependent on an assert being
+ * triggered. We therefore only run this test for .debug and .opt (where
+ * `TRACING_ON == 1`).
+ */
+#if TRACING_ON
 TEST(IntmathDeathTest, floorLog2)
 {
 // Verify a non-positive input triggers an assert.
 EXPECT_DEATH_IF_SUPPORTED(floorLog2(0), "x > 0");
 }
+#endif

 TEST(IntmathTest, ceilLog2)
 {
diff --git a/src/base/sat_counter.test.cc b/src/base/sat_counter.test.cc
index 6de7ef7..214b015 100644
--- a/src/base/sat_counter.test.cc
+++ b/src/base/sat_counter.test.cc
@@ -185,9 +185,13 @@
 ASSERT_EQ(counter, 0);

 // Make sure the counters cannot be shifted by negative numbers, since
-// that is undefined behaviour
+// that is undefined behaviour. As these tests depend on asserts  
failing,

+// these tests are only functional if `TRACING_ON == 1`, when gem5 is
+// compiled as `debug` or `opt`.
+#if TRACING_ON
 ASSERT_DEATH(counter >>= -1, "");
 ASSERT_DEATH(counter <<= -1, "");
+#endif
 }

 /**

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34898
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: release-staging-v20.1.0.0
Gerrit-Change-Id: I2d4ab795ecfc2c4556b5eb1877635409d0836ec6
Gerrit-Change-Number: 34898
Gerrit-PatchSet: 1
Gerrit-Owner: Bobby R. 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]: base: Delete the RefCountingPtr implementation.

2020-09-21 Thread Gabe Black (Gerrit) via gem5-dev 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34896 )



Change subject: base: Delete the RefCountingPtr implementation.
..

base: Delete the RefCountingPtr implementation.

It is no longer used and has been superceded by std::shared_ptr.

Change-Id: I3ff80c882a736781d4568fafa8e517b1c49e895c
---
M src/base/SConscript
D src/base/refcnt.hh
D src/base/refcnt.test.cc
3 files changed, 0 insertions(+), 461 deletions(-)



diff --git a/src/base/SConscript b/src/base/SConscript
index 6514de0..ff36d20 100644
--- a/src/base/SConscript
+++ b/src/base/SConscript
@@ -89,7 +89,6 @@
 GTest('circlebuf.test', 'circlebuf.test.cc')
 GTest('circular_queue.test', 'circular_queue.test.cc')
 GTest('sat_counter.test', 'sat_counter.test.cc')
-GTest('refcnt.test','refcnt.test.cc')
 GTest('condcodes.test', 'condcodes.test.cc')
 GTest('chunk_generator.test', 'chunk_generator.test.cc')

diff --git a/src/base/refcnt.hh b/src/base/refcnt.hh
deleted file mode 100644
index b4eeabf..000
--- a/src/base/refcnt.hh
+++ /dev/null
@@ -1,287 +0,0 @@
-/*
- * Copyright (c) 2017-2018 ARM Limited
- * All rights reserved.
- *
- * The license below extends only to copyright in the software and shall
- * not be construed as granting a license to any other intellectual
- * property including but not limited to intellectual property relating
- * to a hardware implementation of the functionality of the software
- * licensed hereunder.  You may use the software subject to the license
- * terms below provided that you ensure that this notice is replicated
- * unmodified and in its entirety in all distributions of the software,
- * modified or unmodified, in source code or in binary form.
- *
- * Copyright (c) 2002-2005 The Regents of The University of Michigan
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met: redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer;
- * redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution;
- * neither the name of the copyright holders nor the names of its
- * contributors may be used to endorse or promote products derived from
- * this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef __BASE_REFCNT_HH__
-#define __BASE_REFCNT_HH__
-
-#include 
-
-/**
- * @file base/refcnt.hh
- *
- * Classes for managing reference counted objects.
- */
-
-/**
- * Derive from RefCounted if you want to enable reference counting of
- * this class.  If you want to use automatic reference counting, you
- * should use RefCountingPtr instead of regular pointers.
- */
-class RefCounted
-{
-  private:
-// The reference count is mutable because one may want to
-// reference count a const pointer.  This really is OK because
-// const is about logical constness of the object not really about
-// strictly disallowing an object to change.
-mutable int count;
-
-  private:
-// Don't allow a default copy constructor or copy operator on
-// these objects because the default operation will copy the
-// reference count as well and we certainly don't want that.
-RefCounted(const RefCounted &);
-RefCounted &operator=(const RefCounted &);
-
-  public:
-/**
- * We initialize the reference count to zero and the first object
- * to take ownership of it must increment it to one.
- *
- * @attention A memory leak will occur if you never assign a newly
- * constructed object to a reference counting pointer.
- */
-RefCounted() : count(0) {}
-
-/**
- * We make the destructor virtual because we're likely to have
- * virtual functions on reference counted objects.
- *
- * @todo Even if this were true, does it matter?  Shouldn't the
- * derived class indicate this?  This only matters if we wou

[gem5-dev] Change in gem5/gem5[develop]: arch,cpu: Replace RefCountingPtr with std::shared_ptr.

2020-09-21 Thread Gabe Black (Gerrit) via gem5-dev 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34895 )



Change subject: arch,cpu: Replace RefCountingPtr with std::shared_ptr.
..

arch,cpu: Replace RefCountingPtr with std::shared_ptr.

RefCountingPtr was used before std::shared_ptr existed, but now that the
later does, the former no longer needs to.

Change-Id: I5e0867ff0283c77699acc5cd64358592d504f889
---
M src/arch/arm/insts/macromem.cc
M src/arch/arm/insts/sve_macromem.hh
M src/arch/arm/insts/tme64.cc
M src/arch/arm/isa/formats/aarch64.isa
M src/arch/arm/isa/formats/branch.isa
M src/arch/arm/isa/formats/breakpoint.isa
M src/arch/arm/isa/formats/crypto64.isa
M src/arch/arm/isa/formats/data.isa
M src/arch/arm/isa/formats/fp.isa
M src/arch/arm/isa/formats/m5ops.isa
M src/arch/arm/isa/formats/macromem.isa
M src/arch/arm/isa/formats/mem.isa
M src/arch/arm/isa/formats/misc.isa
M src/arch/arm/isa/formats/mult.isa
M src/arch/arm/isa/formats/neon64.isa
M src/arch/arm/isa/formats/pseudo.isa
M src/arch/arm/isa/formats/sve_2nd_level.isa
M src/arch/arm/isa/formats/sve_top_level.isa
M src/arch/arm/isa/formats/uncond.isa
M src/arch/arm/isa/insts/fp.isa
M src/arch/arm/isa/insts/ldr.isa
M src/arch/arm/isa/insts/ldr64.isa
M src/arch/arm/isa/insts/neon.isa
M src/arch/arm/isa/insts/str.isa
M src/arch/arm/isa/insts/str64.isa
M src/arch/arm/isa/insts/sve.isa
M src/arch/arm/isa/insts/sve_mem.isa
M src/arch/arm/isa/templates/basic.isa
M src/arch/arm/isa/templates/mem.isa
M src/arch/arm/isa/templates/mem64.isa
M src/arch/arm/isa/templates/pred.isa
M src/arch/mips/isa/formats/basic.isa
M src/arch/mips/isa/formats/noop.isa
M src/arch/mips/isa/formats/unknown.isa
M src/arch/power/isa/formats/basic.isa
M src/arch/power/isa/formats/unknown.isa
M src/arch/power/isa/formats/util.isa
M src/arch/riscv/isa/formats/amo.isa
M src/arch/riscv/isa/formats/basic.isa
M src/arch/riscv/isa/formats/unknown.isa
M src/arch/sparc/isa/base.isa
M src/arch/sparc/isa/formats/basic.isa
M src/arch/sparc/isa/formats/branch.isa
M src/arch/sparc/isa/formats/integerop.isa
M src/arch/sparc/isa/formats/mem/blockmem.isa
M src/arch/sparc/isa/formats/unknown.isa
M src/arch/x86/insts/badmicroop.cc
M src/arch/x86/isa/formats/basic.isa
M src/arch/x86/isa/formats/string.isa
M src/arch/x86/isa/formats/unknown.isa
M src/arch/x86/isa/macroop.isa
M src/arch/x86/isa/microops/debug.isa
M src/arch/x86/isa/microops/fpop.isa
M src/arch/x86/isa/microops/ldstop.isa
M src/arch/x86/isa/microops/limmop.isa
M src/arch/x86/isa/microops/mediaop.isa
M src/arch/x86/isa/microops/regop.isa
M src/arch/x86/isa/microops/seqop.isa
M src/arch/x86/isa/microops/specop.isa
M src/arch/x86/isa/specialize.isa
M src/cpu/base_dyn_inst.hh
M src/cpu/minor/decode.cc
M src/cpu/minor/dyn_inst.cc
M src/cpu/minor/dyn_inst.hh
M src/cpu/minor/fetch2.cc
M src/cpu/o3/fetch_impl.hh
M src/cpu/o3/impl.hh
M src/cpu/o3/lsq_unit.hh
M src/cpu/static_inst.cc
M src/cpu/static_inst_fwd.hh
70 files changed, 6,530 insertions(+), 4,604 deletions(-)




--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34895
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: I5e0867ff0283c77699acc5cd64358592d504f889
Gerrit-Change-Number: 34895
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
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-arm: Add ID_MMFR4{,EL1} system registers

2020-09-21 Thread Giacomo Travaglini (Gerrit) via gem5-dev 
Giacomo Travaglini has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34876 )



Change subject: arch-arm: Add ID_MMFR4{,EL1} system registers
..

arch-arm: Add ID_MMFR4{,EL1} system registers

Change-Id: Id50ebd2ef2e69ecbd3b7f64a4e9eafe00e283806
---
M src/arch/arm/ArmISA.py
M src/arch/arm/insts/misc64.cc
M src/arch/arm/isa.cc
M src/arch/arm/miscregs.cc
M src/arch/arm/miscregs.hh
M src/arch/arm/tracers/tarmac_parser.cc
M src/arch/arm/utility.cc
7 files changed, 19 insertions(+), 1 deletion(-)



diff --git a/src/arch/arm/ArmISA.py b/src/arch/arm/ArmISA.py
index ebad774..ef6b1a0 100644
--- a/src/arch/arm/ArmISA.py
+++ b/src/arch/arm/ArmISA.py
@@ -71,6 +71,7 @@
 # SuperSec | Coherent TLB | Bcast Maint |
 # BP Maint | Cache Maint Set/way | Cache Maint MVA
 id_mmfr3 = Param.UInt32(0x02102211, "Memory Model Feature Register 3")
+id_mmfr4 = Param.UInt32(0x, "Memory Model Feature Register 4")

 # See section B4.1.84 of ARM ARM
 # All values are latest for ARMv7-A profile
diff --git a/src/arch/arm/insts/misc64.cc b/src/arch/arm/insts/misc64.cc
index 47a8ad9..e0b5189 100644
--- a/src/arch/arm/insts/misc64.cc
+++ b/src/arch/arm/insts/misc64.cc
@@ -365,7 +365,7 @@
   case MISCREG_ID_MMFR1_EL1:
   case MISCREG_ID_MMFR2_EL1:
   case MISCREG_ID_MMFR3_EL1:
-  //case MISCREG_ID_MMFR4_EL1:
+  case MISCREG_ID_MMFR4_EL1:
   case MISCREG_ID_ISAR0_EL1:
   case MISCREG_ID_ISAR1_EL1:
   case MISCREG_ID_ISAR2_EL1:
diff --git a/src/arch/arm/isa.cc b/src/arch/arm/isa.cc
index 9ace236..1b6ed72 100644
--- a/src/arch/arm/isa.cc
+++ b/src/arch/arm/isa.cc
@@ -349,6 +349,7 @@
 miscRegs[MISCREG_ID_MMFR1] = p->id_mmfr1;
 miscRegs[MISCREG_ID_MMFR2] = p->id_mmfr2;
 miscRegs[MISCREG_ID_MMFR3] = p->id_mmfr3;
+miscRegs[MISCREG_ID_MMFR4] = p->id_mmfr4;

 miscRegs[MISCREG_ID_ISAR5] = insertBits(
 miscRegs[MISCREG_ID_ISAR5], 19, 4,
@@ -1387,6 +1388,7 @@
   case MISCREG_ID_MMFR1:
   case MISCREG_ID_MMFR2:
   case MISCREG_ID_MMFR3:
+  case MISCREG_ID_MMFR4:
   case MISCREG_ID_ISAR0:
   case MISCREG_ID_ISAR1:
   case MISCREG_ID_ISAR2:
diff --git a/src/arch/arm/miscregs.cc b/src/arch/arm/miscregs.cc
index 932abc3..2a9df19 100644
--- a/src/arch/arm/miscregs.cc
+++ b/src/arch/arm/miscregs.cc
@@ -394,6 +394,7 @@
   case 5:
 return MISCREG_ID_ISAR5;
   case 6:
+return MISCREG_ID_MMFR4;
   case 7:
 return MISCREG_RAZ; // read as zero
 }
@@ -2059,6 +2060,8 @@
 return MISCREG_ID_ISAR4_EL1;
   case 5:
 return MISCREG_ID_ISAR5_EL1;
+  case 6:
+return MISCREG_ID_MMFR4_EL1;
 }
 break;
   case 3:
@@ -3767,6 +3770,8 @@
   .allPrivileges().exceptUserMode().writes(0);
 InitReg(MISCREG_ID_MMFR3)
   .allPrivileges().exceptUserMode().writes(0);
+InitReg(MISCREG_ID_MMFR4)
+  .allPrivileges().exceptUserMode().writes(0);
 InitReg(MISCREG_ID_ISAR0)
   .allPrivileges().exceptUserMode().writes(0);
 InitReg(MISCREG_ID_ISAR1)
@@ -4690,6 +4695,9 @@
 InitReg(MISCREG_ID_MMFR3_EL1)
   .allPrivileges().exceptUserMode().writes(0)
   .mapsTo(MISCREG_ID_MMFR3);
+InitReg(MISCREG_ID_MMFR4_EL1)
+  .allPrivileges().exceptUserMode().writes(0)
+  .mapsTo(MISCREG_ID_MMFR4);
 InitReg(MISCREG_ID_ISAR0_EL1)
   .allPrivileges().exceptUserMode().writes(0)
   .mapsTo(MISCREG_ID_ISAR0);
diff --git a/src/arch/arm/miscregs.hh b/src/arch/arm/miscregs.hh
index f683297..964788b 100644
--- a/src/arch/arm/miscregs.hh
+++ b/src/arch/arm/miscregs.hh
@@ -212,6 +212,7 @@
 MISCREG_ID_MMFR1,
 MISCREG_ID_MMFR2,
 MISCREG_ID_MMFR3,
+MISCREG_ID_MMFR4,
 MISCREG_ID_ISAR0,
 MISCREG_ID_ISAR1,
 MISCREG_ID_ISAR2,
@@ -541,6 +542,7 @@
 MISCREG_ID_MMFR1_EL1,
 MISCREG_ID_MMFR2_EL1,
 MISCREG_ID_MMFR3_EL1,
+MISCREG_ID_MMFR4_EL1,
 MISCREG_ID_ISAR0_EL1,
 MISCREG_ID_ISAR1_EL1,
 MISCREG_ID_ISAR2_EL1,
@@ -1315,6 +1317,7 @@
 "id_mmfr1",
 "id_mmfr2",
 "id_mmfr3",
+"id_mmfr4",
 "id_isar0",
 "id_isar1",
 "id_isar2",
@@ -1642,6 +1645,7 @@
 "id_mmfr1_el1",
 "id_mmfr2_el1",
 "id_mmfr3_el1",
+"id_mmfr4_el1",
 "id_isar0_el1",
 "id_isar1_el1",
 "id_isar2_el1",
diff --git a/src/arch/arm/tracers/tarmac_parser.cc  
b/src/arch/arm/tracers/tarmac_parser.cc

index c7bf977..9a21f87 100644
--- a/src/arch/arm/tracers/tarmac_parser.cc
+++ b/src/arch/arm/tracers/tarmac_parser.cc
@@ -200,6 +200,7 @@
 { "id_mmfr1", MISCREG_

[gem5-dev] Re: MMU object vs. DTB and ITB

2020-09-21 Thread Jason Lowe-Power via gem5-dev 
We (well, mostly Ayaz) have also been looking at this interface. We've been
thinking more about x86 and RISC-V, but would also like to be kept up to
date!

We were also thinking that many of the TLB/MMU concepts are shared between
ISAs (or are microarchitecture details). So, it would be nice to be able to
use the same multi-level TLB design for any ISA similar to how we can use
caches for any ISA. I'm not sure if this is something that's enabled by
your changes, Giacomo, or if it's something others think is important.

Cheers,
Jason

On Mon, Sep 21, 2020 at 4:06 AM Gabe Black via gem5-dev 
wrote:

> Oh, nice. I got sidetracked with some other things I wanted to rearrange
> first, so I haven't actually started on the MMU part :-). Please add me as
> a reviewer!
>
> Gabe
>
> On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Hi  Gabe, I am actually about to post the same patchset (which is:
>> removing the TLB from the CPU interface and make it interface with an MMU
>> instead)
>>
>>
>>
>> Giacomo
>>
>>
>>
>> *From:* Gabe Black via gem5-dev 
>> *Sent:* 20 September 2020 04:44
>> *To:* gem5 Developer List 
>> *Cc:* Gabe Black 
>> *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB
>>
>>
>>
>> Oh, this will also absorb multilevel TLBs too, like how ARM has second
>> level translation in some cases. This isn't really implemented in x86, but
>> could also be used for it's multilevel translation in SVM and VT's nested
>> page table schemes.
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Sat, Sep 19, 2020 at 8:25 PM Gabe Black  wrote:
>>
>> Hi folks. I've been thinking about how to rework the
>> scanning-through-page-translation thing we currently do when translating a
>> region of addresses through both the ITB and DTB. We currently do that one
>> page at a time by trying one, and then the other. That requires knowing
>> what "the" page size is, which introduces a dependence on the ISA and also
>> constraints things to a single page size.
>>
>>
>>
>> One improvement that I think makes sense is to instead use an approach
>> where you'd ask for a translation for a region and let whatever is
>> translating for you decide how to break things up. Then it can use a single
>> page size, the size of whatever the mapping is, a single byte, etc., as it
>> sees fit without there ever needing to be a particular page size. This
>> would fit mostly nicely with the idea of a range based for loop or
>> generator object.
>>
>>
>>
>> One problem with this approach is how we try one TLB and then the other
>> if we can't get a translation. With a range based for loop, there isn't a
>> good way that I'm aware of to iterate over two different objects at the
>> same time, and also there wouldn't be any coordination between the TLBs.
>> For instance, what should happen in both have a translation? Or if they're
>> to the same place, who's idea of the size of the step takes precedence?
>>
>>
>>
>> That led me to the idea of merging the TLBs into a single object called
>> the MMU. This fits pretty well with the structure of actual hardware, and
>> would also absorb the "UnifiedTLB" concept which was added to the CPU,
>> since the structure of the TLBs would no longer be visible to the CPU.
>>
>>
>>
>> I think this makes a lot of sense and will probably take a stab at it
>> this weekend, but since it's a structural shift that will be fairly visible
>> in a lot of places I wanted to let everybody know a little ahead of time in
>> case there are any big concerns.
>>
>>
>>
>> Gabe
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
> ___
> 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] Change in gem5/gem5[develop]: dev-arm: Implement GICv4.1 GICD_TYPER2 as RES0

2020-09-21 Thread Giacomo Travaglini (Gerrit) via gem5-dev 

Hello Andreas Sandberg, Ciro Santilli,

I'd like you to do a code review. Please visit

https://gem5-review.googlesource.com/c/public/gem5/+/34875

to review the following change.


Change subject: dev-arm: Implement GICv4.1 GICD_TYPER2 as RES0
..

dev-arm: Implement GICv4.1 GICD_TYPER2 as RES0

If GICv4.1 is not implemented (our case) the register should be
treated as RES0

Change-Id: Ia60f6dce9741c34bf167805f60c3fc8bf0897510
Signed-off-by: Giacomo Travaglini 
Reviewed-by: Ciro Santilli 
Reviewed-by: Andreas Sandberg 
---
M src/dev/arm/gic_v3_distributor.cc
M src/dev/arm/gic_v3_distributor.hh
2 files changed, 5 insertions(+), 0 deletions(-)



diff --git a/src/dev/arm/gic_v3_distributor.cc  
b/src/dev/arm/gic_v3_distributor.cc

index 27f404b..27fbe9c 100644
--- a/src/dev/arm/gic_v3_distributor.cc
+++ b/src/dev/arm/gic_v3_distributor.cc
@@ -472,6 +472,9 @@
 //return 0x43b; // ARM JEP106 code (r0p0 GIC-500)
 return 0;

+  case GICD_TYPER2: // Interrupt Controller Type Register 2
+return 0; // RES0
+
   case GICD_STATUSR: // Error Reporting Status Register
 // Optional register, RAZ/WI
 return 0x0;
diff --git a/src/dev/arm/gic_v3_distributor.hh  
b/src/dev/arm/gic_v3_distributor.hh

index 99b65ed..5e17e2a 100644
--- a/src/dev/arm/gic_v3_distributor.hh
+++ b/src/dev/arm/gic_v3_distributor.hh
@@ -65,6 +65,8 @@
 GICD_TYPER = 0x0004,
 // Implementer Identification Register
 GICD_IIDR = 0x0008,
+// Interrupt Controller Type Register 2
+GICD_TYPER2 = 0x000C,
 // Error Reporting Status Register
 GICD_STATUSR = 0x0010,
 // Set Non-secure SPI Pending Register

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34875
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: Ia60f6dce9741c34bf167805f60c3fc8bf0897510
Gerrit-Change-Number: 34875
Gerrit-PatchSet: 1
Gerrit-Owner: Giacomo Travaglini 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Ciro Santilli 
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] Re: MMU object vs. DTB and ITB

2020-09-21 Thread Gabe Black via gem5-dev 
Oh, nice. I got sidetracked with some other things I wanted to rearrange
first, so I haven't actually started on the MMU part :-). Please add me as
a reviewer!

Gabe

On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi  Gabe, I am actually about to post the same patchset (which is:
> removing the TLB from the CPU interface and make it interface with an MMU
> instead)
>
>
>
> Giacomo
>
>
>
> *From:* Gabe Black via gem5-dev 
> *Sent:* 20 September 2020 04:44
> *To:* gem5 Developer List 
> *Cc:* Gabe Black 
> *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB
>
>
>
> Oh, this will also absorb multilevel TLBs too, like how ARM has second
> level translation in some cases. This isn't really implemented in x86, but
> could also be used for it's multilevel translation in SVM and VT's nested
> page table schemes.
>
>
>
> Gabe
>
>
>
> On Sat, Sep 19, 2020 at 8:25 PM Gabe Black  wrote:
>
> Hi folks. I've been thinking about how to rework the
> scanning-through-page-translation thing we currently do when translating a
> region of addresses through both the ITB and DTB. We currently do that one
> page at a time by trying one, and then the other. That requires knowing
> what "the" page size is, which introduces a dependence on the ISA and also
> constraints things to a single page size.
>
>
>
> One improvement that I think makes sense is to instead use an approach
> where you'd ask for a translation for a region and let whatever is
> translating for you decide how to break things up. Then it can use a single
> page size, the size of whatever the mapping is, a single byte, etc., as it
> sees fit without there ever needing to be a particular page size. This
> would fit mostly nicely with the idea of a range based for loop or
> generator object.
>
>
>
> One problem with this approach is how we try one TLB and then the other if
> we can't get a translation. With a range based for loop, there isn't a good
> way that I'm aware of to iterate over two different objects at the same
> time, and also there wouldn't be any coordination between the TLBs. For
> instance, what should happen in both have a translation? Or if they're to
> the same place, who's idea of the size of the step takes precedence?
>
>
>
> That led me to the idea of merging the TLBs into a single object called
> the MMU. This fits pretty well with the structure of actual hardware, and
> would also absorb the "UnifiedTLB" concept which was added to the CPU,
> since the structure of the TLBs would no longer be visible to the CPU.
>
>
>
> I think this makes a lot of sense and will probably take a stab at it this
> weekend, but since it's a structural shift that will be fairly visible in a
> lot of places I wanted to let everybody know a little ahead of time in case
> there are any big concerns.
>
>
>
> Gabe
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
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] Re: MMU object vs. DTB and ITB

2020-09-21 Thread Giacomo Travaglini via gem5-dev 
Hi  Gabe, I am actually about to post the same patchset (which is: removing the 
TLB from the CPU interface and make it interface with an MMU instead)

Giacomo

From: Gabe Black via gem5-dev 
Sent: 20 September 2020 04:44
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] Re: MMU object vs. DTB and ITB

Oh, this will also absorb multilevel TLBs too, like how ARM has second level 
translation in some cases. This isn't really implemented in x86, but could also 
be used for it's multilevel translation in SVM and VT's nested page table 
schemes.

Gabe

On Sat, Sep 19, 2020 at 8:25 PM Gabe Black 
mailto:gabebl...@google.com>> wrote:
Hi folks. I've been thinking about how to rework the 
scanning-through-page-translation thing we currently do when translating a 
region of addresses through both the ITB and DTB. We currently do that one page 
at a time by trying one, and then the other. That requires knowing what "the" 
page size is, which introduces a dependence on the ISA and also constraints 
things to a single page size.

One improvement that I think makes sense is to instead use an approach where 
you'd ask for a translation for a region and let whatever is translating for 
you decide how to break things up. Then it can use a single page size, the size 
of whatever the mapping is, a single byte, etc., as it sees fit without there 
ever needing to be a particular page size. This would fit mostly nicely with 
the idea of a range based for loop or generator object.

One problem with this approach is how we try one TLB and then the other if we 
can't get a translation. With a range based for loop, there isn't a good way 
that I'm aware of to iterate over two different objects at the same time, and 
also there wouldn't be any coordination between the TLBs. For instance, what 
should happen in both have a translation? Or if they're to the same place, 
who's idea of the size of the step takes precedence?

That led me to the idea of merging the TLBs into a single object called the 
MMU. This fits pretty well with the structure of actual hardware, and would 
also absorb the "UnifiedTLB" concept which was added to the CPU, since the 
structure of the TLBs would no longer be visible to the CPU.

I think this makes a lot of sense and will probably take a stab at it this 
weekend, but since it's a structural shift that will be fairly visible in a lot 
of places I wanted to let everybody know a little ahead of time in case there 
are any big concerns.

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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