date:20180321

[gem5-dev] Change in public/gem5[master]: learning_gem5: Add a simple Ruby protocol

2018-03-21 Thread Jason Lowe-Power (Gerrit)


Hello Nikos Nikoleris, Bradford Beckmann, Sooraj Puthoor,

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

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

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

Change subject: learning_gem5: Add a simple Ruby protocol
..

learning_gem5: Add a simple Ruby protocol

Adds the MSI protocol from "A Primer on Memory Consistency and Cache
Coherence" by Daniel J. Sorin, Mark D. Hill, and David A. Wood.

This code follows Learning gem5 Part 3.
http://learning.gem5.org/book/part3/index.html

This is meant to be a simple, clean, example of how to make a Ruby
protocol.
Currently, it only works in SE mode.

The next changeset will contain the required configuration files.

Change-Id: If2cc53f5e6b9c6891749f929d872671615a2b4ab
Signed-off-by: Jason Lowe-Power 
---
A src/learning_gem5/part3/MSI-cache.sm
A src/learning_gem5/part3/MSI-dir.sm
A src/learning_gem5/part3/MSI-msg.sm
A src/learning_gem5/part3/MSI.slicc
A src/learning_gem5/part3/SConsopts
5 files changed, 1,525 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8942
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: If2cc53f5e6b9c6891749f929d872671615a2b4ab
Gerrit-Change-Number: 8942
Gerrit-PatchSet: 4
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bradford Beckmann 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-Reviewer: Sooraj Puthoor 
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]: learning_gem5: Add config files for MSI protocol

2018-03-21 Thread Jason Lowe-Power (Gerrit)

Jason Lowe-Power has uploaded a new patch set (#4). (  
https://gem5-review.googlesource.com/8943 )


Change subject: learning_gem5: Add config files for MSI protocol
..

learning_gem5: Add config files for MSI protocol

Adds the required configuration files to run the MSI protocol. These
config files are much simpler than the current Ruby examples and follow
the pattern in the other Learning gem5 run scripts.

By default, this script runs with two CPUs and runs the recently added
thread test binary.

Currently, only SE mode is supported.

This code follows Learning gem5 Part 3.
http://learning.gem5.org/book/part3/index.html

Change-Id: I813a3153d49e47198444c38a6af30269bd1310cd
Signed-off-by: Jason Lowe-Power 
---
A configs/learning_gem5/part3/msi_caches.py
A configs/learning_gem5/part3/simple_ruby.py
2 files changed, 354 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8943
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: I813a3153d49e47198444c38a6af30269bd1310cd
Gerrit-Change-Number: 8943
Gerrit-PatchSet: 4
Gerrit-Owner: 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: Allow clean operations when block allocation fails

2018-03-21 Thread Gabe Black (Gerrit)

Gabe Black has submitted this change and it was merged. (  
https://gem5-review.googlesource.com/9021 )


Change subject: mem-cache: Allow clean operations when block allocation  
fails

..

mem-cache: Allow clean operations when block allocation fails

Block allocation can fail when there is an in-service MSHR that
operates on the victim block. This can happed due to:
* an upgrade operation: a request that needs a writable copy of the
  block finds a shared (non-writable) copy of the block in the cache
  and has allocates an MSHR for the pending upgrade operation, or
* a clean operation: a clean request finds a dirty copy of the block
  and allocates an MSHR for the pending clean operation.
This changes relaxes an assertion to allow for the 2nd case (cache
clean operations).

Change-Id: Ib51482160b5f2b3702ed744b0eac2029d34bc9d4
Reviewed-by: Curtis Dunham 
Reviewed-on: https://gem5-review.googlesource.com/9021
Reviewed-by: Jason Lowe-Power 
Maintainer: Gabe Black 
---
M src/mem/cache/cache.cc
M src/mem/cache/mshr.hh
2 files changed, 9 insertions(+), 4 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved
  Gabe Black: Looks good to me, approved



diff --git a/src/mem/cache/cache.cc b/src/mem/cache/cache.cc
index 85c9677..9ee9359 100644
--- a/src/mem/cache/cache.cc
+++ b/src/mem/cache/cache.cc
@@ -1826,10 +1826,10 @@
 Addr repl_addr = tags->regenerateBlkAddr(blk);
 MSHR *repl_mshr = mshrQueue.findMatch(repl_addr, blk->isSecure());
 if (repl_mshr) {
-// must be an outstanding upgrade request
+// must be an outstanding upgrade or clean request
 // on a block we're about to replace...
-assert(!blk->isWritable() || blk->isDirty());
-assert(repl_mshr->needsWritable());
+assert((!blk->isWritable() && repl_mshr->needsWritable()) ||
+   repl_mshr->isCleaning());
 // too hard to replace block with transient state
 // allocation failed, block not inserted
 return nullptr;
diff --git a/src/mem/cache/mshr.hh b/src/mem/cache/mshr.hh
index 1f59607..5fe0fb9 100644
--- a/src/mem/cache/mshr.hh
+++ b/src/mem/cache/mshr.hh
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2013, 2015-2016 ARM Limited
+ * Copyright (c) 2012-2013, 2015-2016, 2018 ARM Limited
  * All rights reserved.
  *
  * The license below extends only to copyright in the software and shall
@@ -235,6 +235,11 @@
 /** True if we need to get a writable copy of the block. */
 bool needsWritable() const { return targets.needsWritable; }

+bool isCleaning() const {
+PacketPtr pkt = targets.front().pkt;
+return pkt->isClean();
+}
+
 bool isPendingModified() const {
 assert(inService); return pendingModified;
 }

--
To view, visit https://gem5-review.googlesource.com/9021
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: Ib51482160b5f2b3702ed744b0eac2029d34bc9d4
Gerrit-Change-Number: 9021
Gerrit-PatchSet: 3
Gerrit-Owner: Nikos Nikoleris 
Gerrit-Reviewer: Curtis Dunham 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Protobuf compilation errors

2018-03-21 Thread Gabe Black

I definitely don't think we should disable -Wall or -Werror. I'll look into
ways to disable that check in specific cases. Surprisingly I haven't run
into this problem on my workstation even though I've hit a bunch of other
problems related to very up to date tool versions, but maybe it's just
because I usually use gcc and not clang? I might need some help to make
sure any potential fix actually fixes things.

Gabe

On Wed, Mar 21, 2018 at 9:29 AM, Matthias Jung  wrote:

> Hey,
>
> by the way, when we talk about protobuf, I recently found this:
>
> https://capnproto.org
>
> Its claimed, that capnproto is faster than protobuf,
> However, I cannot confirm that because I have not tried it.
>
> Has somebody else experience with capnproto?
>
> Best,
> Matthias
>
> > Am 21.03.2018 um 16:37 schrieb Matteo Andreozzi <
> matteo.andreo...@arm.com>:
> >
> > Hi Andreas,
> > Thanks for sending this out. I’ve been experiencing issues on Mac using
> clang, the issue in detail is:
> >
> > Scons tries to build a test program including message.h from protobuf to
> check if the protobuf C libraries are present
> > Protobuf versions later than 3.3.0 use the LANG_CXX11 macro without
> defining it first, in at least one of their files (atom.h).
> > This causes the compilation of the test program to fail , due to the
> -Wundef directive being set, and scons assuming that no protobuf is
> available in the system.
> >
> > The quick and dirty fix which I have on my local workspace is to remove
> -Wundef from Sconstruct, which anyway never triggered before with the
> exception of protobuf (on MSC_VER in the past, now on LANG_CXX11), see
> below:
> >
> > main.Append(CCFLAGS=['-fno-strict-aliasing'])
> > # Enable -Wall and -Wextra and then disable the few warnings that
> > # we consistently violate
> > -main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
> > +main.Append(CCFLAGS=['-Wall', '-Wextra',
> >  '-Wno-sign-compare', '-Wno-unused-parameter'])
> > # We always compile using C++11
> > main.Append(CXXFLAGS=['-std=c++11'])
> >
> >
> > From: Andreas Sandberg 
> > Date: Wednesday, 21 March 2018 at 15:25
> > To: gem5 Developer List 
> > Cc: Gabe Black , Matteo Andreozzi <
> matteo.andreo...@arm.com>
> > Subject: Protobuf compilation errors
> >
> > Hi Everyone,
> >
> > We have been experiencing some issues with some combinations of
> > different versions of protobuf and gcc/clang. Most of the issues seem to
> > be related to undefined macros (-Wundef), but I have some vague memories
> > of other issues as well (unclear indentation?).
> >
> > In the short term, it seems like we need to disable -Werror for files
> > that are generated by protoc. Another option would be to add
> > -Wno-error=undef to the global environment. What would be the preferred
> > solution here? I think I'm in favour of the former, but don't understand
> > the build system well enough to implement it.
> >
> > Cheers,
> > Andreas
> >
> >
> > 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
> > http://m5sim.org/mailman/listinfo/gem5-dev
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Protobuf compilation errors

2018-03-21 Thread Matthias Jung

Hey,

by the way, when we talk about protobuf, I recently found this:

https://capnproto.org

Its claimed, that capnproto is faster than protobuf,
However, I cannot confirm that because I have not tried it.

Has somebody else experience with capnproto?

Best,
Matthias

> Am 21.03.2018 um 16:37 schrieb Matteo Andreozzi :
> 
> Hi Andreas,
> Thanks for sending this out. I’ve been experiencing issues on Mac using 
> clang, the issue in detail is:
> 
> Scons tries to build a test program including message.h from protobuf to 
> check if the protobuf C libraries are present
> Protobuf versions later than 3.3.0 use the LANG_CXX11 macro without defining 
> it first, in at least one of their files (atom.h).
> This causes the compilation of the test program to fail , due to the -Wundef 
> directive being set, and scons assuming that no protobuf is available in the 
> system.
> 
> The quick and dirty fix which I have on my local workspace is to remove 
> -Wundef from Sconstruct, which anyway never triggered before with the 
> exception of protobuf (on MSC_VER in the past, now on LANG_CXX11), see below:
> 
> main.Append(CCFLAGS=['-fno-strict-aliasing'])
> # Enable -Wall and -Wextra and then disable the few warnings that
> # we consistently violate
> -main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
> +main.Append(CCFLAGS=['-Wall', '-Wextra',
>  '-Wno-sign-compare', '-Wno-unused-parameter'])
> # We always compile using C++11
> main.Append(CXXFLAGS=['-std=c++11'])
> 
> 
> From: Andreas Sandberg 
> Date: Wednesday, 21 March 2018 at 15:25
> To: gem5 Developer List 
> Cc: Gabe Black , Matteo Andreozzi 
> 
> Subject: Protobuf compilation errors
> 
> Hi Everyone,
> 
> We have been experiencing some issues with some combinations of
> different versions of protobuf and gcc/clang. Most of the issues seem to
> be related to undefined macros (-Wundef), but I have some vague memories
> of other issues as well (unclear indentation?).
> 
> In the short term, it seems like we need to disable -Werror for files
> that are generated by protoc. Another option would be to add
> -Wno-error=undef to the global environment. What would be the preferred
> solution here? I think I'm in favour of the former, but don't understand
> the build system well enough to implement it.
> 
> Cheers,
> Andreas
> 
> 
> 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
> http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Protobuf compilation errors

2018-03-21 Thread Matteo Andreozzi

Hi Andreas,
Thanks for sending this out. I’ve been experiencing issues on Mac using clang, 
the issue in detail is:

Scons tries to build a test program including message.h from protobuf to check 
if the protobuf C libraries are present
Protobuf versions later than 3.3.0 use the LANG_CXX11 macro without defining it 
first, in at least one of their files (atom.h).
This causes the compilation of the test program to fail , due to the -Wundef 
directive being set, and scons assuming that no protobuf is available in the 
system.

The quick and dirty fix which I have on my local workspace is to remove -Wundef 
from Sconstruct, which anyway never triggered before with the exception of 
protobuf (on MSC_VER in the past, now on LANG_CXX11), see below:

 main.Append(CCFLAGS=['-fno-strict-aliasing'])
 # Enable -Wall and -Wextra and then disable the few warnings that
 # we consistently violate
-main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
+main.Append(CCFLAGS=['-Wall', '-Wextra',
  '-Wno-sign-compare', '-Wno-unused-parameter'])
 # We always compile using C++11
 main.Append(CXXFLAGS=['-std=c++11'])


From: Andreas Sandberg 
Date: Wednesday, 21 March 2018 at 15:25
To: gem5 Developer List 
Cc: Gabe Black , Matteo Andreozzi 

Subject: Protobuf compilation errors

Hi Everyone,

We have been experiencing some issues with some combinations of
different versions of protobuf and gcc/clang. Most of the issues seem to
be related to undefined macros (-Wundef), but I have some vague memories
of other issues as well (unclear indentation?).

In the short term, it seems like we need to disable -Werror for files
that are generated by protoc. Another option would be to add
-Wno-error=undef to the global environment. What would be the preferred
solution here? I think I'm in favour of the former, but don't understand
the build system well enough to implement it.

Cheers,
Andreas


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
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Protobuf compilation errors

2018-03-21 Thread Andreas Sandberg


Hi Everyone,

We have been experiencing some issues with some combinations of
different versions of protobuf and gcc/clang. Most of the issues seem to
be related to undefined macros (-Wundef), but I have some vague memories
of other issues as well (unclear indentation?).

In the short term, it seems like we need to disable -Werror for files
that are generated by protoc. Another option would be to add
-Wno-error=undef to the global environment. What would be the preferred
solution here? I think I'm in favour of the former, but don't understand
the build system well enough to implement it.

Cheers,
Andreas

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
http://m5sim.org/mailman/listinfo/gem5-dev

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

2018-03-21 Thread Andreas Sandberg

Hi Gabe,

There are issues with the IDE model that prevent it from working with in-kernel 
GIC emulation. I believe the model doesn't clear interrupts correctly, which 
confuses the host kernel. I tried to debug this at some point, but wasn't able 
to do much immaediate progress and decided it wasn't worth the effort. The 
VirtIO block devices doesn't suffer from this problem.

Using the VirtIO device by default seems like a good idea to me. It doesn't 
simulate any timing, but that might not be a huge deal since the IDE device 
doesn't provide realistic timing anyway. It would be really awesome if we had a 
modern storage controller (e.g., NVMe or AHCI) and proper storage timing models.

Cheers,
Andreas

On 20/03/2018 23:38, Gabe Black wrote:
My next question is about disks. I see that the fs_bigLITTLE.py script uses 
PciVirtIO to set up its disks, where I'm using IDE which I inherited from the 
fs.py scripts I used as reference. The problem I'm seeing is that the IDE 
controllers seem to be mangling commands and dropping interrupts, so this 
difference looks particularly suspicious. Is there a KVM related reason you're 
using PciVirtIO? Is this something that *should* work with IDE bug doesn't, or 
do I have to use PciVirtIO for things to work properly? I'm not familiar with 
PciVirtIO beyond briefly skimming the source for it in gem5. Is this something 
we should consider using globally as a replacement for IDE, even in simulations 
where we're trying to be really realistic?

Thanks again for all the help.

Gabe

On Tue, Mar 20, 2018 at 3:14 PM, Gabe Black 
> wrote:
Ok, that (multiple event queues) made things way better. There are still some 
glitches to figure out, but at least it makes good forward progress at a 
reasonable speed. Thanks!

Gabe

On Mon, Mar 19, 2018 at 5:12 PM, Gabe Black 
> wrote:
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)

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

2018-03-21 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/o3-timing: 
FAILED!
* 
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-rv64c/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: 
FAILED!
* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
FAILED!
* 
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/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED!
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED!
* 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-two-level:
 CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 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-ruby: 
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-timing: CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: 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/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: 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/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED!
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/minor-timing: 
CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-atomic: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-atomic: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing-ruby:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-timing-ruby:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/minor-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-timing-ruby:
 CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-atomic: 
CHANGED!
*

[gem5-dev] Change in public/gem5[master]: learning_gem5: Add a simple Ruby protocol

[gem5-dev] Change in public/gem5[master]: learning_gem5: Add config files for MSI protocol

[gem5-dev] Change in public/gem5[master]: mem-cache: Allow clean operations when block allocation fails

Re: [gem5-dev] Protobuf compilation errors

Re: [gem5-dev] Protobuf compilation errors

Re: [gem5-dev] Protobuf compilation errors

[gem5-dev] Protobuf compilation errors

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

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

9 matches

Site Navigation

Mail list logo

Footer information