[gem5-dev] Change in public/gem5[master]: riscv: throw IllegalInstFault when decoding invalid instructions

2018-03-19 Thread Tuan Ta (Gerrit)
Tuan Ta has submitted this change and it was merged. (  
https://gem5-review.googlesource.com/9261 )


Change subject: riscv: throw IllegalInstFault when decoding invalid  
instructions

..

riscv: throw IllegalInstFault when decoding invalid instructions

If an instruction is invalid, some assertions may in the decoder may
fail the entire simulation. Instead, we want to raise an
IllegalInstFault instead of failing immediately in the decoder if the
invalid instruction is being speculatively executed.

Change-Id: I5cb72ba06f07f173922f86897ddfdf677e8c702f
Reviewed-on: https://gem5-review.googlesource.com/9261
Maintainer: Alec Roelke 
Reviewed-by: Monir Zaman 
Reviewed-by: Jason Lowe-Power 
---
M src/arch/riscv/isa/decoder.isa
1 file changed, 58 insertions(+), 19 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved
  Monir Zaman: Looks good to me, but someone else must approve
  Alec Roelke: Looks good to me, approved



diff --git a/src/arch/riscv/isa/decoder.isa b/src/arch/riscv/isa/decoder.isa
index bbed650..e3992d7 100644
--- a/src/arch/riscv/isa/decoder.isa
+++ b/src/arch/riscv/isa/decoder.isa
@@ -117,7 +117,9 @@
 if (CIMM1 > 0)
 imm |= ~((uint64_t)0x1F);
 }}, {{
-assert(RC1 != 0);
+if (RC1 == 0) {
+fault = make_shared("source reg x0");
+}
 Rc1_sd = (int32_t)Rc1_sd + imm;
 }});
 0x2: c_li({{
@@ -125,7 +127,9 @@
 if (CIMM1 > 0)
 imm |= ~((uint64_t)0x1F);
 }}, {{
-assert(RC1 != 0);
+if (RC1 == 0) {
+fault = make_shared("source reg x0");
+}
 Rc1_sd = imm;
 }});
 0x3: decode RC1 {
@@ -137,7 +141,9 @@
 if (CIMM1 > 0)
 imm |= ~((int64_t)0x1FF);
 }}, {{
-assert(imm != 0);
+if (imm == 0) {
+fault = make_shared("immediate =  
0");

+}
 sp_sd = sp_sd + imm;
 }});
 default: c_lui({{
@@ -145,8 +151,12 @@
 if (CIMM1 > 0)
 imm |= ~((uint64_t)0x1);
 }}, {{
-assert(RC1 != 0 && RC1 != 2);
-assert(imm != 0);
+if (RC1 == 0 || RC1 == 2) {
+fault = make_shared("source reg  
x0");

+}
+if (imm == 0) {
+fault = make_shared("immediate =  
0");

+}
 Rc1_sd = imm;
 }});
 }
@@ -155,14 +165,18 @@
 format CIOp {
 0x0: c_srli({{
 imm = CIMM5 | (CIMM1 << 5);
-assert(imm != 0);
 }}, {{
+if (imm == 0) {
+fault = make_shared("immediate =  
0");

+}
 Rp1 = Rp1 >> imm;
 }}, uint64_t);
 0x1: c_srai({{
 imm = CIMM5 | (CIMM1 << 5);
-assert(imm != 0);
 }}, {{
+if (imm == 0) {
+fault = make_shared("immediate =  
0");

+}
 Rp1_sd = Rp1_sd >> imm;
 }}, uint64_t);
 0x2: c_andi({{
@@ -230,9 +244,13 @@
 0x2: decode COPCODE {
 0x0: CIOp::c_slli({{
 imm = CIMM5 | (CIMM1 << 5);
-assert(imm != 0);
 }}, {{
-assert(RC1 != 0);
+if (imm == 0) {
+fault = make_shared("immediate = 0");
+}
+if (RC1 == 0) {
+fault = make_shared("source reg x0");
+}
 Rc1 = Rc1 << imm;
 }}, uint64_t);
 format CompressedLoad {
@@ -250,7 +268,9 @@
  CIMM1 << 5 |
  CIMM5<1:0> << 6;
 }}, {{
-assert(RC1 != 0);
+if (RC1 == 0) {
+fault = make_shared("source reg x0");
+}
 Rc1_sd = Mem_sw;
 }}, {{
 EA = sp + offset;
@@ -260,7 +280,9 @@
  CIMM1 << 5 |
  CIMM5<2:0> << 6;
 }}, {{
-assert(RC1 != 0);
+if (RC1 == 0) {
+fault = make_shared("source reg x0");
+}
 Rc1_sd = Mem_sd;
 }}, {{
 EA = sp + offset;
@@ -269,22 +291,31 @@
 0x4: decode CFUNCT1 {
 0x0: decode RC2 {
 0x0: 

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

2018-03-19 Thread Gabe Black
This is on an chromebook based on the RK3399 with only ~4GB of RAM which is
not ideal, although we have a bigger machine in the works for the future. I
agree with your reasoning and don't think option 1 is a problem. We're
using static DTBs so I don't think that's an issue either. In my script,
I'm not doing anything smart with the event queues, so that's likely at
least part of the problem. When I tried using fs_bigLITTLE.py I ran into
what looked like a similar issue so that might not be the whole story, but
it's definitely something I should fix up. I'll let you know how that goes!

Gabe

On Mon, Mar 19, 2018 at 4:30 AM, Andreas Sandberg 
wrote:

> Hmm, OK, this is very strange.
>
> What type of hardware are you running on? Is it an A57-based chip or
> something else? Also, what's your simulation quantum? I have been able to
> run with a 0.5ms quantum  (5e8 ticks).
> I think the following trace of two CPUs running in KVM should be roughly
> equivalent to the trace you shared earlier. It was generated on a
> commercially available 8xA57 (16GiB ram) using the following command (gem5
> rev 9dc44b417):
>
> gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun 
> configs/example/arm/fs_bigLITTLE.py \
> --sim-quantum '0.5ms' \
> --cpu-type kvm --big-cpus 0 --little-cpus 2 \
> --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel 
> vmlinux.aarch64.4.4-d318f95d0c
>
> Note that the tick counts are a bit weird since we have three different
> event queues at play (1 for devices and one per CPU).
>
>   0: system.littleCluster.cpus0: KVM: Executing for 5 ticks
>   0: system.littleCluster.cpus1: KVM: Executing for 5 ticks
>   0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in 
> 176363 cycles (88181504 ticks, sim cycles: 176363).
> 88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
> 88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
> 0x1c090024, len: 4)
> 88332000: system.littleCluster.cpus0: Entering KVM...
> 88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks
> 88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
> 16854 cycles (8427000 ticks, sim cycles: 16854).
> 96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
> 96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
> 0x1c090030, len: 4)
>   0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in 
> 666400 cycles (33320 ticks, sim cycles: 666400).
> 33320: system.littleCluster.cpus1: Entering KVM...
> 33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks
> 96909000: system.littleCluster.cpus0: Entering KVM...
> 96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks
> 96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
> 15257 cycles (7628500 ticks, sim cycles: 15257).
> 104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
> 104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
> 0x1c0100a0, len: 4)
> 33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in 
> 200820 cycles (10041 ticks, sim cycles: 200820).
> 43361: system.littleCluster.cpus1: Entering KVM...
> 43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks
> 104688000: system.littleCluster.cpus0: Entering KVM...
> 104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks
> 104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in 
> 14942 cycles (7471000 ticks, sim cycles: 14942).
>
> Comparing this trace to yours, I'd say that there the frequent KVM exits
> look a bit suspicious. I would expect secondary CPUs to make very little
> process while the main CPU initializes the system and starts the early boot
> code.
>
> There area  couple of possibilities that might be causing issues:
>
> 1) There is some CPU ID weirdness that confuses the boot code and puts
> both CPUs in the holding pen. This seems unlikely since there are some
> writes to the UART.
>
> 2) Some device is incorrectly mapped to the CPU event queues and causes
> frequent KVM exits. Have a look at _build_kvm in fs_bigLITTLE.py, it
> doesn't use configs/common, so no need to tear your eyes out. ;) Do you map
> event queues in the same way? It's mapping all simulated devices to one
> event queue and the CPUs to private event queues. It's important to remap
> CPU child devices to the device queue instead of the CPU queue. Failing to
> do this will cause chaos, madness, and quite possibly result in Armageddon.
>
> 3) You're using DTB autogeneration. This doesn't work for KVM guests due
> to issues with the timer interrupt specification. We have a patch for the
> timer that we are testing internally. Sorry. :(
>
> Regards,
> Andreas
> On 16/03/2018 23:20, Gabe Black wrote:
>
> Ok, diving into this a little deeper, it looks like execution is
> progressing but is making 

[gem5-dev] Change in public/gem5[master]: arch-riscv: implement bare metal specific system class

2018-03-19 Thread Robert Scheffel (Gerrit)
Robert Scheffel has uploaded this change for review. (  
https://gem5-review.googlesource.com/9281



Change subject: arch-riscv: implement bare metal specific system class
..

arch-riscv: implement bare metal specific system class

A new system class was implemented, that manages
variables, which are only relevant for bare metal applications.
That will help to enable both, bare metal systems and later on linux
systems.

Change-Id: I379315bbea5042ae9f933ab24222a59b619b95a4
---
M src/arch/riscv/RiscvSystem.py
M src/arch/riscv/SConscript
A src/arch/riscv/bare_metal/system.cc
A src/arch/riscv/bare_metal/system.hh
M src/arch/riscv/system.cc
M src/arch/riscv/system.hh
6 files changed, 151 insertions(+), 49 deletions(-)



diff --git a/src/arch/riscv/RiscvSystem.py b/src/arch/riscv/RiscvSystem.py
index df0f964..89e6cf0 100644
--- a/src/arch/riscv/RiscvSystem.py
+++ b/src/arch/riscv/RiscvSystem.py
@@ -32,8 +32,15 @@
 from m5.params import *
 from System import System

+
 class RiscvSystem(System):
 type = 'RiscvSystem'
 cxx_header = 'arch/riscv/system.hh'
-bootloader = Param.String("File, that contains the bootloader code")
+resetVect = Param.Addr(0x0, 'Reset vector')
 load_addr_mask = 0x
+
+
+class BareMetalRiscvSystem(RiscvSystem):
+type = 'BareMetalRiscvSystem'
+cxx_header = 'arch/riscv/bare_metal/system.hh'
+bootloader = Param.String("File, that contains the bootloader code")
diff --git a/src/arch/riscv/SConscript b/src/arch/riscv/SConscript
index 2482414..2ddba72 100644
--- a/src/arch/riscv/SConscript
+++ b/src/arch/riscv/SConscript
@@ -62,6 +62,8 @@
 Source('linux/process.cc')
 Source('linux/linux.cc')

+Source('bare_metal/system.cc')
+
 SimObject('RiscvInterrupts.py')
 SimObject('RiscvISA.py')
 SimObject('RiscvTLB.py')
diff --git a/src/arch/riscv/bare_metal/system.cc  
b/src/arch/riscv/bare_metal/system.cc

new file mode 100644
index 000..c8b3ad2
--- /dev/null
+++ b/src/arch/riscv/bare_metal/system.cc
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2018 TU Dresden
+ * 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.
+ *
+ * Authors: Robert Scheffel
+ */
+
+#include "arch/riscv/bare_metal/system.hh"
+
+#include "base/loader/object_file.hh"
+
+BareMetalRiscvSystem::BareMetalRiscvSystem(Params *p)
+: RiscvSystem(p)
+{
+bootloaderSymtab = new SymbolTable;
+
+// load bootloader code into memory
+bootloader = createObjectFile(p->bootloader);
+if (bootloader == NULL) {
+ fatal("Could not load bootloader file %s", p->bootloader);
+}
+
+// load symbols
+if (!bootloader->loadGlobalSymbols(bootloaderSymtab)) {
+panic("Could not load bootloader symbols\n");
+}
+
+if (!bootloader->loadLocalSymbols(bootloaderSymtab)) {
+panic("Could not load bootloader symbols\n");
+}
+
+_resetVect = bootloader->entryPoint();
+}
+
+BareMetalRiscvSystem::~BareMetalRiscvSystem()
+{
+delete bootloaderSymtab;
+delete bootloader;
+}
+
+void
+BareMetalRiscvSystem::initState()
+{
+// Call the initialisation of the super class
+RiscvSystem::initState();
+
+// load program sections into memory
+if (!bootloader->loadSections(physProxy)) {
+warn("could not load sections to memory");
+}
+}
+
+BareMetalRiscvSystem *
+BareMetalRiscvSystemParams::create()
+{
+return new BareMetalRiscvSystem(this);
+}
diff --git a/src/arch/riscv/bare_metal/system.hh  

[gem5-dev] Change in public/gem5[master]: arch-riscv: enable rudimentary fs simulation

2018-03-19 Thread Robert Scheffel (Gerrit)
Robert Scheffel has uploaded this change for review. (  
https://gem5-review.googlesource.com/9282



Change subject: arch-riscv: enable rudimentary fs simulation
..

arch-riscv: enable rudimentary fs simulation

The RiscvSystem class is extended with a variable, that indicates, if we
execute a bare metal system or not.

Change-Id: I973793fe723ce0b2d58d3f3cfd920d3c7106fc63
---
M src/arch/riscv/RiscvSystem.py
M src/arch/riscv/system.cc
M src/arch/riscv/system.hh
M src/arch/riscv/tlb.cc
4 files changed, 82 insertions(+), 37 deletions(-)



diff --git a/src/arch/riscv/RiscvSystem.py b/src/arch/riscv/RiscvSystem.py
index 89e6cf0..a9eca6e 100644
--- a/src/arch/riscv/RiscvSystem.py
+++ b/src/arch/riscv/RiscvSystem.py
@@ -28,6 +28,7 @@
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #
 # Authors: Alec Roelke
+#  Robert Scheffel

 from m5.params import *
 from System import System
@@ -36,6 +37,7 @@
 class RiscvSystem(System):
 type = 'RiscvSystem'
 cxx_header = 'arch/riscv/system.hh'
+bare_metal = Param.Bool(False, "Using Bare Metal Application?")
 resetVect = Param.Addr(0x0, 'Reset vector')
 load_addr_mask = 0x

@@ -44,3 +46,5 @@
 type = 'BareMetalRiscvSystem'
 cxx_header = 'arch/riscv/bare_metal/system.hh'
 bootloader = Param.String("File, that contains the bootloader code")
+
+bare_metal = True
diff --git a/src/arch/riscv/system.cc b/src/arch/riscv/system.cc
index c36aa99..2b33923 100644
--- a/src/arch/riscv/system.cc
+++ b/src/arch/riscv/system.cc
@@ -29,6 +29,7 @@
  * Authors: Ali Saidi
  *  Nathan Binkert
  *  Jaidev Patwardhan
+ *  Robert Scheffel
  */

 #include "arch/riscv/system.hh"
@@ -46,6 +47,7 @@

 RiscvSystem::RiscvSystem(Params *p)
 : System(p),
+  _isBareMetal(p->bare_metal),
   _resetVect(p->resetVect)
 {
 }
@@ -63,6 +65,15 @@
 return dynamic_cast(tc->getSystemPtr())->resetVect();
 }

+/**
+ * Return the bare metal checker.
+ */
+bool
+RiscvSystem::isBareMetal(ThreadContext* tc)
+{
+return dynamic_cast(tc->getSystemPtr())->isBareMetal();
+}
+
 Addr
 RiscvSystem::fixFuncEventAddr(Addr addr)
 {
@@ -84,4 +95,3 @@
 {
 return new RiscvSystem(this);
 }
-
diff --git a/src/arch/riscv/system.hh b/src/arch/riscv/system.hh
index 4971a10..46276b3 100644
--- a/src/arch/riscv/system.hh
+++ b/src/arch/riscv/system.hh
@@ -29,6 +29,7 @@
  * Authors: Ali Saidi
  *  Nathan Binkert
  *  Jaidev Patwardhan
+ *  Robert Scheffel
  */

 #ifndef __ARCH_RISCV_SYSTEM_HH__
@@ -48,6 +49,8 @@
 class RiscvSystem : public System
 {
   protected:
+// checker for bare metal application
+bool _isBareMetal;
 // entry point for simulation
 Addr _resetVect;

@@ -56,12 +59,18 @@
 RiscvSystem(Params *p);
 ~RiscvSystem();

-// return reset address
+// return reset vector
 Addr resetVect() const { return _resetVect; }

+// return bare metal checker
+bool isBareMetal() const { return _isBareMetal; }
+
 // return reset address of thread context
 static Addr resetVect(ThreadContext* tc);

+// return bare metal checker of thread context
+static bool isBareMetal(ThreadContext* tc);
+
 virtual bool breakpoint();

   public:
@@ -101,4 +110,3 @@
 };

 #endif
-
diff --git a/src/arch/riscv/tlb.cc b/src/arch/riscv/tlb.cc
index b92327f..96b8bdb 100644
--- a/src/arch/riscv/tlb.cc
+++ b/src/arch/riscv/tlb.cc
@@ -1,7 +1,6 @@
 /*
  * Copyright (c) 2001-2005 The Regents of The University of Michigan
  * Copyright (c) 2007 MIPS Technologies, Inc.
- * Copyright (c) 2018 TU Dresden
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -32,7 +31,6 @@
  *  Jaidev Patwardhan
  *  Zhengxing Li
  *  Deyuan Guo
- *  Robert Scheffel
  */

 #include "arch/riscv/tlb.hh"
@@ -43,6 +41,7 @@
 #include "arch/riscv/faults.hh"
 #include "arch/riscv/pagetable.hh"
 #include "arch/riscv/pra_constants.hh"
+#include "arch/riscv/system.hh"
 #include "arch/riscv/utility.hh"
 #include "base/inifile.hh"
 #include "base/str.hh"
@@ -289,23 +288,25 @@
 {
 if (FullSystem) {
 /**
- * as we currently support bare metal only, we set the physical  
flag

- * that means we treat all addresses as physical addresses
- * no translation needed
+ * check if we simulate a bare metal system
+ * if so, we have no tlb, phys addr == virt addr
  */
-req->setFlags(Request::PHYSICAL);
-}
+if (RiscvSystem::isBareMetal(tc))
+req->setFlags(Request::PHYSICAL);

-if (req->getFlags() & Request::PHYSICAL) {
-/**
- * we simply set the virtual address to physical address
- */
-req->setPaddr(req->getVaddr());
-/**
- * check if the request is cacheable
- * seems like this could have an impact on 

[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings

2018-03-19 Thread Giacomo Travaglini (Gerrit)
Giacomo Travaglini has uploaded a new patch set (#8) to the change  
originally created by Chun-Chen TK Hsu. (  
https://gem5-review.googlesource.com/9101 )


Change subject: arch, arm: Fix implicit-fallthrough GCC warnings
..

arch, arm: Fix implicit-fallthrough GCC warnings

GCC 7 generates spurious fallthrough warnings in nested switch blocks
where the inner switch block return.  There is already a GCC fix [1]
submitted for review but, until it is merged into GCC trunk, GEM5 will
not build with GCC 7 due to these fallthrough warnings.  This patch
silences the spurious fallthrough warnings by appending a M5_UNREACHABLE
statement in the outer switch cases.

Note there is another GEM5 patch [2] to fix other fallthrough warnings.

[1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html
[2] https://gem5-review.googlesource.com/c/public/gem5/+/8541

Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Signed-off-by: Chun-Chen Hsu 
---
M src/arch/arm/isa/formats/aarch64.isa
M src/arch/isa_parser.py
2 files changed, 6 insertions(+), 1 deletion(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Gerrit-Change-Number: 9101
Gerrit-PatchSet: 8
Gerrit-Owner: Chun-Chen TK Hsu 
Gerrit-Assignee: Giacomo Travaglini 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Chun-Chen TK Hsu 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP Replacement Policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8981

to look at the new patch set (#4).

Change subject: mem-cache: Create BRRIP Replacement Policy
..

mem-cache: Create BRRIP Replacement Policy

Implementation of a Bimodal RRIP replacement policy.

Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/brrip_rp.cc
A src/mem/cache/replacement_policies/brrip_rp.hh
4 files changed, 145 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b
Gerrit-Change-Number: 8981
Gerrit-PatchSet: 4
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create NRU Replacement Policy

2018-03-19 Thread Daniel Carvalho (Gerrit)
Daniel Carvalho has uploaded a new patch set (#2). (  
https://gem5-review.googlesource.com/9001 )


Change subject: mem-cache: Create NRU Replacement Policy
..

mem-cache: Create NRU Replacement Policy

Implementation of a Not Recently Used replacement policy.

Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/nru_rp.cc
A src/mem/cache/replacement_policies/nru_rp.hh
4 files changed, 115 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8
Gerrit-Change-Number: 9001
Gerrit-PatchSet: 2
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-CC: Jason Lowe-Power 
Gerrit-CC: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create RRIP replacement policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8891

to look at the new patch set (#3).

Change subject: mem-cache: Create RRIP replacement policy
..

mem-cache: Create RRIP replacement policy

Implementation of a Re-Reference Interval Prediction replacement
policy.

Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
---
M src/mem/cache/blk.hh
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/rrip_rp.cc
A src/mem/cache/replacement_policies/rrip_rp.hh
5 files changed, 239 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
Gerrit-Change-Number: 8891
Gerrit-PatchSet: 3
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create MRU replacement policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8889

to look at the new patch set (#3).

Change subject: mem-cache: Create MRU replacement policy
..

mem-cache: Create MRU replacement policy

Implementation of a Most Recently Used replacement policy.

Change-Id: Id52cb247ca25d4523dcc53490d113695dac6a3f1
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/mru_rp.cc
A src/mem/cache/replacement_policies/mru_rp.hh
4 files changed, 176 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Id52cb247ca25d4523dcc53490d113695dac6a3f1
Gerrit-Change-Number: 8889
Gerrit-PatchSet: 3
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BIP Replacement Policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/9003

to look at the new patch set (#2).

Change subject: mem-cache: Create BIP Replacement Policy
..

mem-cache: Create BIP Replacement Policy

Implementation of a Bimodal Insertion Policy replacement policy.

Change-Id: Ife058d0d4310dbcb35858348006189f0b2bf7c37
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/bip_rp.cc
A src/mem/cache/replacement_policies/bip_rp.hh
4 files changed, 150 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ife058d0d4310dbcb35858348006189f0b2bf7c37
Gerrit-Change-Number: 9003
Gerrit-PatchSet: 2
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create FIFO replacement policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/

to look at the new patch set (#4).

Change subject: mem-cache: Create FIFO replacement policy
..

mem-cache: Create FIFO replacement policy

Implementation of a First-In, First-Out replacement policy.

Change-Id: Id234ec9d29c092dd4516e609da14b8a75a96b5e4
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/fifo_rp.cc
A src/mem/cache/replacement_policies/fifo_rp.hh
4 files changed, 144 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Id234ec9d29c092dd4516e609da14b8a75a96b5e4
Gerrit-Change-Number: 
Gerrit-PatchSet: 4
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create LFU replacement policy

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8890

to look at the new patch set (#3).

Change subject: mem-cache: Create LFU replacement policy
..

mem-cache: Create LFU replacement policy

Implementation of a Least Frequently Used replacement policy.

Change-Id: I772afccd3a7955777e53d59341e922718db44e5c
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/lfu_rp.cc
A src/mem/cache/replacement_policies/lfu_rp.hh
4 files changed, 145 insertions(+), 0 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I772afccd3a7955777e53d59341e922718db44e5c
Gerrit-Change-Number: 8890
Gerrit-PatchSet: 3
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

2018-03-19 Thread Andreas Sandberg

Hmm, OK, this is very strange.

What type of hardware are you running on? Is it an A57-based chip or something 
else? Also, what's your simulation quantum? I have been able to run with a 
0.5ms quantum  (5e8 ticks).

I think the following trace of two CPUs running in KVM should be roughly 
equivalent to the trace you shared earlier. It was generated on a commercially 
available 8xA57 (16GiB ram) using the following command (gem5 rev 9dc44b417):

gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun configs/example/arm/fs_bigLITTLE.py \
   --sim-quantum '0.5ms' \
   --cpu-type kvm --big-cpus 0 --little-cpus 2 \
   --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel 
vmlinux.aarch64.4.4-d318f95d0c

Note that the tick counts are a bit weird since we have three different event 
queues at play (1 for devices and one per CPU).

 0: system.littleCluster.cpus0: KVM: Executing for 5 ticks
 0: system.littleCluster.cpus1: KVM: Executing for 5 ticks
 0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in 176363 
cycles (88181504 ticks, sim cycles: 176363).
88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
0x1c090024, len: 4)
88332000: system.littleCluster.cpus0: Entering KVM...
88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks
88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 16854 
cycles (8427000 ticks, sim cycles: 16854).
96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
0x1c090030, len: 4)
 0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in 666400 
cycles (33320 ticks, sim cycles: 666400).
33320: system.littleCluster.cpus1: Entering KVM...
33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks
96909000: system.littleCluster.cpus0: Entering KVM...
96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks
96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 15257 
cycles (7628500 ticks, sim cycles: 15257).
104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
0x1c0100a0, len: 4)
33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in 
200820 cycles (10041 ticks, sim cycles: 200820).
43361: system.littleCluster.cpus1: Entering KVM...
43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks
104688000: system.littleCluster.cpus0: Entering KVM...
104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks
104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in 14942 
cycles (7471000 ticks, sim cycles: 14942).


Comparing this trace to yours, I'd say that there the frequent KVM exits look a 
bit suspicious. I would expect secondary CPUs to make very little process while 
the main CPU initializes the system and starts the early boot code.

There area  couple of possibilities that might be causing issues:

1) There is some CPU ID weirdness that confuses the boot code and puts both 
CPUs in the holding pen. This seems unlikely since there are some writes to the 
UART.

2) Some device is incorrectly mapped to the CPU event queues and causes 
frequent KVM exits. Have a look at _build_kvm in fs_bigLITTLE.py, it doesn't 
use configs/common, so no need to tear your eyes out. ;) Do you map event 
queues in the same way? It's mapping all simulated devices to one event queue 
and the CPUs to private event queues. It's important to remap CPU child devices 
to the device queue instead of the CPU queue. Failing to do this will cause 
chaos, madness, and quite possibly result in Armageddon.

3) You're using DTB autogeneration. This doesn't work for KVM guests due to 
issues with the timer interrupt specification. We have a patch for the timer 
that we are testing internally. Sorry. :(

Regards,
Andreas

On 16/03/2018 23:20, Gabe Black wrote:
Ok, diving into this a little deeper, it looks like execution is progressing but is 
making very slow progress for some reason. I added a call to "dump()" before 
each ioctl invocation which enters the VM and looked at the PC to get an idea of what it 
was up to. I made sure to put that before the timers to avoid taking up VM time with 
printing debug stuff. In any case, I see that neither CPU gets off of PC 0 for about 2ms 
simulated time (~500Hz), and that's EXTREMELY slow for a CPU which is supposed to be 
running in the ballpark of 2GHz. It's not clear to me why it's making such slow progress, 
but that would explain why I'm getting very little out on the simulated console. It's 
just taking forever to make it that far.

Any idea why it's going so slow, or how to debug further?

Gabe

On Wed, Mar 14, 2018 at 7:42 PM, Gabe Black 
> wrote:
Some output 

[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.

2018-03-19 Thread Daniel Carvalho (Gerrit)

Hello Nikos Nikoleris, Andreas Sandberg,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8501

to look at the new patch set (#12).

Change subject: mem-cache: Split array indexing and replacement policies.
..

mem-cache: Split array indexing and replacement policies.

Replacement policies (LRU, Random) are currently considered as array
indexing methods, but have completely different functionalities:

- Array indexers determine the possible locations for block allocation.
  This information is used to generate replacement candidates when
  conflicts happen.
- Replacement policies determine which of the replacement candidates
  should be evicted to make room for new allocations.

For this reason, they were split into different classes. Advantages:

- Easier and more straightforward to implement other replacement
  policies (RRIP, LFU, ARC, ...)
- Allow easier future implementation of cache organization schemes

As now we can't assure the use of sets, the previous way to create a
true LRU is not viable. Now a timestamp_bits parameter controls how
many bits are dedicated for the timestamp, and a true LRU can be
achieved through an infinite number of bits (although a few bits suffice
in practice).

Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
---
M configs/common/cores/arm/O3_ARM_v7a.py
M configs/common/cores/arm/ex5_LITTLE.py
M configs/common/cores/arm/ex5_big.py
M src/mem/cache/Cache.py
M src/mem/cache/base.cc
M src/mem/cache/blk.hh
M src/mem/cache/cache.cc
A src/mem/cache/replacement_policies/ReplacementPolicies.py
A src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/base.cc
A src/mem/cache/replacement_policies/base.hh
A src/mem/cache/replacement_policies/lru_rp.cc
A src/mem/cache/replacement_policies/lru_rp.hh
A src/mem/cache/replacement_policies/random_rp.cc
A src/mem/cache/replacement_policies/random_rp.hh
M src/mem/cache/tags/SConscript
M src/mem/cache/tags/Tags.py
M src/mem/cache/tags/base.cc
M src/mem/cache/tags/base.hh
M src/mem/cache/tags/base_set_assoc.cc
M src/mem/cache/tags/base_set_assoc.hh
M src/mem/cache/tags/fa_lru.cc
M src/mem/cache/tags/fa_lru.hh
D src/mem/cache/tags/lru.cc
D src/mem/cache/tags/lru.hh
D src/mem/cache/tags/random_repl.cc
D src/mem/cache/tags/random_repl.hh
27 files changed, 654 insertions(+), 444 deletions(-)


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


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
Gerrit-Change-Number: 8501
Gerrit-PatchSet: 12
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-CC: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2018-03-19 Thread Cron Daemon
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: 
FAILED!
*** diff[config.json]: SKIPPED* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby:
 FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: 
FAILED!
*** diff[simout]: SKIPPED* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/o3-timing: FAILED!
* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
FAILED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: 
CHANGED!
--- quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level ---* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 CHANGED!
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.* 
build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
CHANGED!*** gem5: OK
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
CHANGED!
*** diff[config.ini]: SKIPPED* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
CHANGED!--- quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple ---
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED!
*** diff[config.ini]: SKIPPED* 
build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 CHANGED!
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 CHANGED!
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 CHANGED!
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 CHANGED!* 
build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 CHANGED!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: 
CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
CHANGED!
*** diff[simerr]: SKIPPED* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: 
CHANGED!*** diff[smred.sv2]: SKIPPED
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
*