[gem5-dev] Migrating to git and gerrit

[Jason Lowe-Power]

Hi all,

We've been talking about this for a while, but now it's time! Special
thanks to Andreas Sandberg for all of his hard work for putting this
together.

We will be migrating our infrastructure from the self-hosted mercurial repo
at repo.gem5.org and reviewboard to git and gerrit hosted on Google's new
googlesource website. You can find a live version (not ready for primetime)
of this at https://gem5.googlesource.com/.

We are planning on flipping the switch on *March 1st*, unless there is an
objection from the community. Note: I'm announcing this on gem5-dev before
announcing on gem5-users and gem5-announce in case there's any details
we've missed.

I've posted a patch on reviewboard that contains a new CONTRIBUTING
document that details the new contribution process. Please review that
document so it can be pushed before we transition. (
http://reviews.gem5.org/r/3814/)

The major changes are detailed below:
1. REPOSITORIES
  * The canonical version of gem5 will now live at
https://gem5.googlesource.com/, not repo.gem5.org
  * The mercurial repository at repo.gem5.org will be a read-only mirror of
the googlesource repo.
  * We will keep the github mirror
2. CODE REVIEWS
  * All reviews will happen on https://gem5-review.googlesource.com/.
  * No new patches will be accepted on reviewboard after March 1. Any
patches still on reviewboard will be discussed/reviewed there, but
committers will have to manually commit them to the git repo (not unlike
our current situation).

Main differences for developers:
1. You will have to learn to use git, if you haven't already
2. Developers who submit patches will be able to *commit their own patches*
after review. No more waiting for me to push patches for you!
3. Continuous integration tests are coming soon, and must pass before a
patch is committed.
4. Gerrit has a different user-interface than reviewboard... sorry for the
change.
5. Many of the policies we have for commits will be *strictly enforced*
automatically by gerrit. E.g., it will no longer be possible to post a
patch that has a non-conforming commit message.
6. Instead of using postreview, patches will be posted by pushing to
special git branches on our gerrit instance.

*Please let me know if you have any questions or concerns. I'd like to iron
all of this out in the next few days so we can post the announcement on
gem5-users and gem5-announce.*

I would also like to thank the team at Google that has generously donated
their time to set up this infrastructure. This include Rahul Thakur, Jason
Buberel, Haihong Zhuo, and many others.

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

Re: [gem5-dev] Review Request 3815: sim: fix out-of-bounds error in syscall_desc

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3815/#review9435
---

Ship it!


Minor thing below. Since this is confusing, I think it could use more comments.


src/sim/syscall_desc.cc (line 55)
<http://reviews.gem5.org/r/3815/#comment7955>

Can you add a comment here. This is very confusing code. Maybe something 
like 

// RHS is evaluated before LHS and getSyscallArg increments index (passed 
by reference).

Note: you should also add braces, if you add this inline comment.


- Jason Lowe-Power


On Feb. 16, 2017, 5:39 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3815/
> ---
> 
> (Updated Feb. 16, 2017, 5:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11849:9152df7d2747
> ---
> sim: fix out-of-bounds error in syscall_desc
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_desc.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 
> 
> Diff: http://reviews.gem5.org/r/3815/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3814/
---

(Updated Feb. 21, 2017, 5:34 p.m.)


Review request for Default.


Repository: gem5


Description
---

changesets:
11849:b5f456096b51 "misc: Add a CONTRIBUTING document

This document details how to contribute to gem5 based on our new
contribution flow with git and gerrit.

Signed-off-by: Jason Lowe-Power "


Diffs (updated)
-

  CONTRIBUTING.md PRE-CREATION 

Diff: http://reviews.gem5.org/r/3814/diff/


Testing
---


Thanks,

Jason Lowe-Power

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

Re: [gem5-dev] Review Request 3819: python: Add a generalized mechanism to configure stats

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3819/#review9443
---


I really like this interface! Cool idea. Just some comments on the 
implementation below.


src/python/m5/stats/__init__.py (line 102)
<http://reviews.gem5.org/r/3819/#comment7968>

Can we make this a little more explicit? I think using decorators is a 
little clearer. Like:

@_url_wrapper
def initText(filename, desc=True):
return _m5.stats.initText(filename, desc)

In fact, you could even implicitly generate the factories dictionary. 
Though, this would be counter to my "more explicit" request ;).

I'm pretty sure that _url_wrapper is already a correctly implemented 
decorator, but I don't have a ton of experience with them, so I could be wrong.


- Jason Lowe-Power


On Feb. 21, 2017, 6:53 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3819/
> ---
> 
> (Updated Feb. 21, 2017, 6:53 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11873:c509be206026
> ---
> python: Add a generalized mechanism to configure stats
> 
> Add a mechanism to configure the stat output format using a URL-like
> syntax. This makes it possible to specify both an output format
> (currently, only text is supported) and override default
> parameters.
> 
> On the Python-side, this is implemented using a helper function
> (m5.stats.addStatVisitor) that adds a visitor to the list of active
> stat visitors. The helper function parses a URL-like stat
> specification to determine the stat output type. Optional parameters
> can be specified to change how stat visitors behave.
> 
> For example, to output stats in text format without stat descriptions:
> 
> m5.stats.appendStatVisitor("text://stats.txt?desc=False")
> 
> From the command line:
> 
> gem5.opt --stats-file="text://stats.txt?desc=False"
> 
> Internally, the stat framework uses the _url_wrapper() helper function
> to wrap a Python function with the fn(path, **kwargs) signature in a
> function that takes a parsed URL as its only argument. The path and
> keyword arguments are automatically derived from the URL in the
> wrapper function.
> 
> New output formats can be registered in the m5.stats.factories
> dictionary. This dictionary contains a mapping between format names
> (URL schemes) and factory methods.
> 
> To retain backwards compatibility, the code automatically assumes that
> the user wants text output if no format has been specified (i.e., when
> specifying a plain path).
> 
> Change-Id: Ic4dce93ab4ead07ffdf71e55a22ba0ae5a143061
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Curtis Dunham 
> Reviewed-by: Sascha Bischoff 
> Reviewed-by: Ilias Vougioukas 
> 
> 
> Diffs
> -
> 
>   src/python/m5/main.py ba90ffa751b6 
>   src/python/m5/stats/__init__.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3819/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3820: tests: Disable descriptions in stat files

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3820/#review9444
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 21, 2017, 6:53 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3820/
> ---
> 
> (Updated Feb. 21, 2017, 6:53 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11874:40cd0a543902
> ---
> tests: Disable descriptions in stat files
> 
> Don't output verbose text descriptions in stat files when running
> tests. This saves a lot of space when storing reference data.
> 
> Change-Id: I2a7ead4843586e800ecf83846694b73f0c356373
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> Reviewed-by: Sascha Bischoff 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   tests/testing/units.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3820/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3821: base: Refactor logging to make log level selection cleaner

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3821/#review9446
---

Ship it!


LGTM (+1). Quick question: Where is the default set? It wasn't obvious to me in 
skimming this, so maybe a comment somewhere?

- Jason Lowe-Power


On Feb. 21, 2017, 6:54 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3821/
> ---
> 
> (Updated Feb. 21, 2017, 6:54 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11875:aee0628e5698
> ---
> base: Refactor logging to make log level selection cleaner
> 
> It's currently possible to change the log level in gem5 by tweaking a
> set of global variables. These variables are currently exposed to
> Python using SWIG. This mechanism is far from ideal for two reasons:
> First, changing the log level requires that the Python world enables
> or disables individual levels. Ideally, this should be a single call
> where a log level is selected. Second, exporting global variables is
> poorly supported by most Python frameworks. SWIG puts variables in
> their own namespace and PyBind doesn't seem to support it at all.
> 
> This changeset refactors the logging code to create a more abstract
> interface. Each log level is associated with an instance of a Logger
> class. This class contains common functionality, an enable flag, and a
> verbose flag.
> 
> Available LogLevels are described by the LogLevel class. Lower log
> levels are used for more critical messages (PANIC being level 0) and
> higher levels for less critical messages. The highest log level that
> is printed is controlled by calling Logger:setLevel().
> 
> Change-Id: I31e44299d242d953197a8e62679250c91d6ef776
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Gabor Dozsa 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   src/base/misc.hh ba90ffa751b6 
>   src/base/misc.cc ba90ffa751b6 
>   src/python/swig/core.i ba90ffa751b6 
>   tests/configs/switcheroo.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3821/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3823: arch: Include generated decoder header after normal headers

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3823/#review9447
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 21, 2017, 6:55 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3823/
> ---
> 
> (Updated Feb. 21, 2017, 6:55 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11877:0d512e211833
> ---
> arch: Include generated decoder header after normal headers
> 
> The generated decoder header defines macros that represent bit fields
> within instructions. These fields typically have short names that
> conflict with names in other header files. Include the generated
> header after all normal header to avoid this issue.
> 
> Change-Id: I53d149b75432c20abdbf651e32c3c785d897973b
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   src/arch/generic/memhelpers.hh ba90ffa751b6 
>   src/arch/isa_parser.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3823/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3822: power: Avoid forward declarations that confuse wrappers

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3822/#review9448
---


Why the name change ThermalNode -> thermal_entity? Wouldn't it be more clear to 
call the new files "thermal_node.\*"?

- Jason Lowe-Power


On Feb. 21, 2017, 7:02 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3822/
> ---
> 
> (Updated Feb. 21, 2017, 7:02 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11876:0e18f230c540
> ---
> power: Avoid forward declarations that confuse wrappers
> 
> The Python wrappers get confused by the forward declarations in the
> power framework. This changeset restructures the code slightly to
> avoid the troublesome forward declarations.
> 
> Change-Id: Id8c93224f1988edb5fdf9d3abc6237f2f688c02d
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Andreas Hansson 
> Reviewed-by: Curtis Dunham 
> Reviewed-by: Sascha Bischoff 
> 
> 
> Diffs
> -
> 
>   src/sim/power/SConscript ba90ffa751b6 
>   src/sim/power/ThermalModel.py ba90ffa751b6 
>   src/sim/power/thermal_domain.hh ba90ffa751b6 
>   src/sim/power/thermal_entity.hh ba90ffa751b6 
>   src/sim/power/thermal_entity.cc PRE-CREATION 
>   src/sim/power/thermal_model.hh ba90ffa751b6 
>   src/sim/power/thermal_model.cc ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3822/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3819: python: Add a generalized mechanism to configure stats

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3819/#review9454
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 22, 2017, 10:02 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3819/
> ---
> 
> (Updated Feb. 22, 2017, 10:02 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11873:97acd467f793
> ---
> python: Add a generalized mechanism to configure stats
> 
> Add a mechanism to configure the stat output format using a URL-like
> syntax. This makes it possible to specify both an output format
> (currently, only text is supported) and override default
> parameters.
> 
> On the Python-side, this is implemented using a helper function
> (m5.stats.addStatVisitor) that adds a visitor to the list of active
> stat visitors. The helper function parses a URL-like stat
> specification to determine the stat output type. Optional parameters
> can be specified to change how stat visitors behave.
> 
> For example, to output stats in text format without stat descriptions:
> 
> m5.stats.addStatVisitor("text://stats.txt?desc=False")
> 
> From the command line:
> 
> gem5.opt --stats-file="text://stats.txt?desc=False"
> 
> Internally, the stat framework uses the _url_factory decorator
> to wrap a Python function with the fn(path, **kwargs) signature in a
> function that takes a parsed URL as its only argument. The path and
> keyword arguments are automatically derived from the URL in the
> wrapper function.
> 
> New output formats can be registered in the m5.stats.factories
> dictionary. This dictionary contains a mapping between format names
> (URL schemes) and factory methods.
> 
> To retain backwards compatibility, the code automatically assumes that
> the user wants text output if no format has been specified (i.e., when
> specifying a plain path).
> 
> Change-Id: Ic4dce93ab4ead07ffdf71e55a22ba0ae5a143061
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Curtis Dunham 
> Reviewed-by: Sascha Bischoff 
> Reviewed-by: Ilias Vougioukas 
> 
> 
> Diffs
> -
> 
>   src/python/m5/main.py ba90ffa751b6 
>   src/python/m5/stats/__init__.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3819/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3821: base: Refactor logging to make log level selection cleaner

[Jason Lowe-Power]

> On Feb. 21, 2017, 7:18 p.m., Jason Lowe-Power wrote:
> > LGTM (+1). Quick question: Where is the default set? It wasn't obvious to 
> > me in skimming this, so maybe a comment somewhere?
> 
> Andreas Sandberg wrote:
> Logger instances are enabled by default when they are instantiated (see 
> Logger:Logger), which all log levels are enabled by default. We could make 
> this more explicit by making the enabled flag a parameter to the constructor 
> and setting it in Logger::get(). Would that make it cleaner?

I see. No need to change anything. I think the current solution is fine.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3821/#review9446
---


On Feb. 21, 2017, 6:54 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3821/
> ---
> 
> (Updated Feb. 21, 2017, 6:54 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11875:aee0628e5698
> ---
> base: Refactor logging to make log level selection cleaner
> 
> It's currently possible to change the log level in gem5 by tweaking a
> set of global variables. These variables are currently exposed to
> Python using SWIG. This mechanism is far from ideal for two reasons:
> First, changing the log level requires that the Python world enables
> or disables individual levels. Ideally, this should be a single call
> where a log level is selected. Second, exporting global variables is
> poorly supported by most Python frameworks. SWIG puts variables in
> their own namespace and PyBind doesn't seem to support it at all.
> 
> This changeset refactors the logging code to create a more abstract
> interface. Each log level is associated with an instance of a Logger
> class. This class contains common functionality, an enable flag, and a
> verbose flag.
> 
> Available LogLevels are described by the LogLevel class. Lower log
> levels are used for more critical messages (PANIC being level 0) and
> higher levels for less critical messages. The highest log level that
> is printed is controlled by calling Logger:setLevel().
> 
> Change-Id: I31e44299d242d953197a8e62679250c91d6ef776
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Gabor Dozsa 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   src/base/misc.hh ba90ffa751b6 
>   src/base/misc.cc ba90ffa751b6 
>   src/python/swig/core.i ba90ffa751b6 
>   tests/configs/switcheroo.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3821/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3832: style: local variable name correction

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3832/#review9462
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 23, 2017, 7:56 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3832/
> ---
> 
> (Updated Feb. 23, 2017, 7:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11885:33cd29b5e7c5
> ---
> style: local variable name correction
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3832/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

Re: [gem5-dev] Review Request 3833: style: change NULL to nullptr in syscall files

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3833/#review9463
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 23, 2017, 7:58 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3833/
> ---
> 
> (Updated Feb. 23, 2017, 7:58 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11890:74ef725af658
> ---
> style: change NULL to nullptr in syscall files
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/syscall_emul.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3833/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

Re: [gem5-dev] Review Request 3836: x86: remove unnecessary parameter from functions

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3836/#review9471
---

Ship it!


Ship It!

- Jason Lowe-Power


On Feb. 23, 2017, 10:17 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3836/
> ---
> 
> (Updated Feb. 23, 2017, 10:17 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11892:15f4547c339b
> ---
> x86: remove unnecessary parameter from functions
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3836/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

Re: [gem5-dev] Review Request 3838: ext: Update DRAMPower

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3838/#review9480
---

Ship it!


Going forward, I think we should reconsider how we link other projects in the 
ext folder. Especially since we're moving to git, I wonder if we could use 
something like sub repos to get a similar effect without having to pull all of 
this code into the gem5 repo. I guess the downside to this would be an extra 
step for users to have to recursively clone the repo.

This comment is not on topic for this patch, sorry. This patch is fine as it is 
:).

- Jason Lowe-Power


On Feb. 24, 2017, 9:56 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3838/
> ---
> 
> (Updated Feb. 24, 2017, 9:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11881:910b9376009a
> ---
> ext: Update DRAMPower
> 
> This patch syncs the DRAMPower library of gem5 to the external
> one on github (https://github.com/ravenrd/DRAMPower) of which
> I am one of the maintainers.
> 
> The version used is the commit:
> 90d6290f802c29b3de9e10233ceee22290907ce6
> from 30. Oct. 2016.
> 
> The new version features a bank-wise power estimation.
> Furthermore, PASR and Per-Bank Refresh is supported.
> 
> More Informtation can be found in the following papers:
> 
> A Bank-Wise DRAM Power Model for System Simulations
> Deepak M. Mathew, Eder F. Zulian, Subash. Kannoth, Matthias Jung, Christian 
> Weis, Norbert Wehn.
> International Conference on High-Performance and Embedded Architectures and 
> Compilers 2016 (HiPEAC), Workshop on: Rapid Simulation and Performance 
> Evaluation: Methods and Tools (RAPIDO), Stockholm, 2017.
> 
> A New Bank Sensitive DRAMPower Model for Efficient Design Space Exploration
> Matthias Jung, Deepak M. Mathew, Eder F. Zulian, Christian Weis, Norbert Wehn.
> International Workshop on Power And Timing Modeling, Optimization and 
> Simulation (PATMOS 2016), September, 2016, Bremen, Germany
> 
> 
> Diffs
> -
> 
>   ext/drampower/README.md 5ea85692a53e 
>   ext/drampower/SConscript 5ea85692a53e 
>   ext/drampower/src/CAHelpers.cc PRE-CREATION 
>   ext/drampower/src/CmdHandlers.cc PRE-CREATION 
>   ext/drampower/src/CommandAnalysis.h 5ea85692a53e 
>   ext/drampower/src/CommandAnalysis.cc 5ea85692a53e 
>   ext/drampower/src/MemBankWiseParams.h PRE-CREATION 
>   ext/drampower/src/MemBankWiseParams.cc PRE-CREATION 
>   ext/drampower/src/MemCommand.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.h 5ea85692a53e 
>   ext/drampower/src/MemPowerSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.h 5ea85692a53e 
>   ext/drampower/src/MemTimingSpec.cc 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.h 5ea85692a53e 
>   ext/drampower/src/MemoryPowerModel.cc 5ea85692a53e 
>   ext/drampower/src/TraceParser.h 5ea85692a53e 
>   ext/drampower/src/TraceParser.cc 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.h 5ea85692a53e 
>   ext/drampower/src/libdrampower/LibDRAMPower.cc 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/Makefile 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/commands.trace 5ea85692a53e 
>   ext/drampower/test/libdrampowertest/lib_test.cc 5ea85692a53e 
> 
> Diff: http://reviews.gem5.org/r/3838/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

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

Re: [gem5-dev] ISA Deprecation

[Jason Lowe-Power]

Hi Brandon,

See this discussion for some of the history here:
http://comments.gmane.org/gmane.comp.emulators.m5.devel/30510

Let me try to summarize for everyone.

There are a number of reasons to deprecate/phase out most of the supported
ISAs. Briefly:
 - Less work for contributors especially when updating SE mode
 - Less testing time
 - Some ISAs have no maintainer
 - Some ISAs have (basically) no tests, or the tests are proprietary
 - Causes confusion for users (e.g., they run experiments with an
incomplete ISA, or worse)

However, some people *do* use the code for ISAs other than x86, ARM,
RISC-V, and HSAIL. For instance:
 - From Jakub "[gem5 is] the only existing and basically working open
source sun4v simulator.
 - Boris uses gem5's support for MIPS and POWER to do retargetable compiler
research, and "dropping them would be pretty much equivalent to
discontinuing GEM5 altogether"

I think Steve makes one of the best arguments both for and against this in
this message: http://www.mail-archive.com/gem5-dev@gem5.org/msg19429.html.

-- My opinions below:

From our discussion at HPCA, I think it comes down to "what does the
community want gem5 to be?" Right now, gem5 has a wide variety of different
use cases. I think we need to decide as a community what use cases we want
to support and focus our limited developer time on those use cases. For
instance, do we think it is worth it to support MIPS emulation?

Maybe someone can come up with a list of "gem5 use cases" for us to look at
and discuss. I don't have time in the next week or so, but after that I'll
put it on my to do list.

At a higher level, I strongly believe we need to take a step back and make
sure that gem5 is serving its users as best as it can. There's a lot of
unmaintained code in gem5 that is hurting and not helping. For instance, it
would be great if Brandon could focus his time purely on improving x86 SE
mode, which many people use, and not fixing bugs with SPARC.

Cheers,
Jason

On Thu, Feb 23, 2017 at 4:47 PM Potter, Brandon 
wrote:

Hello all,

A colleague mentioned that ISA deprecation was discussed during the recent
gem5 meeting. I am wondering what the community's feelings are toward the
idea and which ISAs would be on the chopping block. Personally, I'd like to
kill ALPHA, MIPS, POWER, and SPARC. This means that we'd retain X86, ARM,
RISCV, and HSAIL-X86.

I can help out with the removal if we decide that we want to kill some of
them. We might wait until March 1st to start the process since we're
supposed to transition to fully transition to Git on that day; we could
create a tag for the ISA deprecation in case someone wants to revive one of
them in the future (i.e. MIPS or POWER if someone wants to maintain them).

Regards,
Brandon


___
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] Migrating to git and gerrit

[Jason Lowe-Power]

Hi Brandon,

You can make your changes to the code, then run "git commit --amend" to
amend the most recent commit. Basically, you want to update the same commit
that you pushed before. After that, you can push it using the same command
and gerrit will figure it out.

Does this answer your question about the commit log? Basically, the main
difference between hg and git is that git allows you to easily change
history. Whereas hg makes it impossible (or very hard) to change history.
There are arguments for both sides, but let's be honest, git won.

I'm not git expert, so maybe others have better answers (and it looks like
Gabe replied while I was writing this anyway).

Cheers,
Jason

On Wed, Mar 1, 2017 at 4:31 PM Potter, Brandon 
wrote:

> Hello Andreas,
>
> Newbie gerrit/git questions here:
>
> If someone requests a modification to a changeset in a review (or I
> realize something is wrong with the changeset myself), how do I update the
> posted review on Gerrit for the specified changeset? Mercurial/Reviewboard
> would be something like hg qref followed by hg postreview -oue  and the
> patch on Reviewboard would be updated to reflect the changes. How do we
> achieve a similar behavior here?
>
> Furthermore, what does the resulting commit log look like given whatever
> workflow you use? Ideally, we'd like the commit log to reflect coherent,
> atomic changes that implement one specific feature at a time. I don't want
> to public many incoherent changesets that are iterating to the
> right/accepted solution to implement a feature.
>
> Regards,
> Brandon
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
> Sandberg
> Sent: Wednesday, March 1, 2017 8:44 AM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] Migrating to git and gerrit
>
> Hi Everyone,
>
> The new Gerrit-based infrastructure is now live with the old Mercurial
> repository as a read-only mirror. Mirroring is currently done using a cron
> job that executes every 15 minutes, which means that there is some amount
> of lag between the gerrit master version and the mirrors.
>
> Those of you with commit access who plan to submit patches that have been
> on reviewed using the old infrastructure will need to convert these patches
> to git and push them to the main repository. It is highly recommended that
> patches without reviews are discarded and re-posted using the Gerrit flow
> to reduce the maintenance overhead of committing patches.
>
> Existing Mercurial patches (e.g., from patch queues) can be converted
> using the hg-patch-to-git-patch [1] script from Mozilla. The patch
> conversion script makes sure that the commit message and author information
> can be understood by git. Before converting your patches, make sure they
> apply cleanly on the current master branch. The best way to check this is
> by qpop:ing your patch queue, pulling in new changes, and then reapplying
> it. If you get warnings when applying patches, you need to qrefresh them to
> make sure that the diffs are up to date.
> Failing to do so will result in git refusing the patch.
>
> Once you have a patch queue that applies cleanly, you can import it into a
> new git branch using the following commands:
>
> # Create a new clone of the master repository git clone
> https://gem5.googlesource.com/public/gem5 gem5 cd gem5 # Install Gerrit's
> commit message hook. This is done automatically by scons when you build
> gem5.
> cp ext/git-commit-msg .git/hooks/commit-msg
>
> # Create a new branch for the outgoing changes git checkout -b fixes
> origin/master
>
> hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patch1.patch | git am
> # Run the commit message hook to generate a Change-id by amending the
> commit git commit --amend ...
> hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patchN.patch | git am
> git commit --amend
>
> To push the branch for review (remember to test it and verify that the
> commit log looks OK first!), execute the following command:
>
> git push origin HEAD:refs/for/master
>
> It's sometimes useful to set a patch series topic if you're submitting
> multiple patches. To do that when you submit patches for review, use this
> command instead:
>
> git push origin HEAD:refs/for/master%topic=my/topic
>
> Some users can bypass reviews and push changes straight into the master
> branch. This should only be done for code that has been reviewed using the
> ReviewBoard-based flow. If you're one of the select few, you can use the
> following push command to bypass review:
>
> git push origin HEAD:refs/heads/master
>
>
> Cheers,
> Andreas
>
> [1]
> https://github.com/mozilla/moz-git-to

[gem5-dev] Best method for adding code to ext/

[Jason Lowe-Power]

Hi all,

There are a couple of patches in review that add a large chunk of code from
other repositories to gem5 in ext/. Andreas S. has a patch that adds
PyBind11 and Matthias is updating DRAMPower. And we're thinking about
including SystemC in a similar way.

Is there a better way for us to include these other projects in gem5's
source tree? For instance, we could use subrepos. What is the community's
thoughts on this?

A few things I don't like about including the code in gem5:
1) It increases the amount of code in our repository
2) It is hard to track updates to these systems
3) The code cannot be GPL.

Good thing about including the code in gem5:
1) Updates to external code won't break our system
2) It's easy to build gem5 without having to download other software

Any other opinions or options for this?

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

Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3814/#review9504
---


I went ahead and pushed this to the mainline this morning. Sorry I was so slow 
to do this. There are some outstanding issues, but we can modify the document 
to fix them as we go.

To follow up on Brad's comments about maintainers: We need to add a new 
MAINTAINERS file. For now, we'll assume that the PMC is responsible for 
everything, and we can add maintainers as we go. If someone has a suggestion 
for how to assign maintainers, let us know (probably in a new email chain).

- Jason Lowe-Power


On Feb. 21, 2017, 5:34 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3814/
> ---
> 
> (Updated Feb. 21, 2017, 5:34 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> changesets:
>   11849:b5f456096b51 "misc: Add a CONTRIBUTING document
> 
> This document details how to contribute to gem5 based on our new
> contribution flow with git and gerrit.
> 
> Signed-off-by: Jason Lowe-Power "
> 
> 
> Diffs
> -
> 
>   CONTRIBUTING.md PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

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

Re: [gem5-dev] fallocate() not found for old Linux

[Jason Lowe-Power]

Hi Paul,

Contrary to what I've said in the past, I think it's time to retire support
for RHEL5. The end of life for RHEL5 is the end of this month (
https://access.redhat.com/support/policy/updates/errata). We already have a
large number of systems that must be tested (most of which we don't
actually test), and if we can constrain the environment we support even
just a little it will make life easier for gem5 developers.

Other thoughts?

Jason

On Sat, Mar 18, 2017 at 10:53 AM Paul Rosenfeld (prosenfeld) <
prosenf...@micron.com> wrote:

> Hello all,
>
> I recently tried to build gem5 on RHEL5 (I know, I know) and it complained
> about missing the fallocate() system call added in
> https://gem5.googlesource.com/public/gem5/+/cc84eb81
>
> The current hardcoded assumption is that Linux will have access to this
> system call (
> https://gem5.googlesource.com/public/gem5/+/93d8e6b898a70a3f6dba9da385d5933683bf325f/src/sim/syscall_emul.hh#55
> ), but ancient Linux does not. Does it make sense to add a scons
> configuration check for this so the define can be set dynamically or is
> RHEL5 too old to worry about for most users?
>
> Regards,
> Paul
> ___
> 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] adding reviewers in gerrit?

[Jason Lowe-Power]

Hi Gabe,

Hmm... It works for me. It's possible that we don't have the permissions
set up correctly to allow anyone to add reviewers. I just tested with a
non-admin account and it doesn't work for that account either. I'll look
into it.

Cheers,
Jason

On Sat, Mar 25, 2017 at 5:32 AM Gabe Black  wrote:

> Hi folks. I've uploaded a few CLs to gerrit now, and I notice that I can't
> add reviewers since it claims everyone I try to add isn't a registered
> user. That's very odd, because I'm trying to add people who have given me
> review feedback on earlier changes, and people who I can look up activity
> for on gerrit. Does anybody know why it's not behaving for me? My other CL
> got reviewed so it's not a problem yet, but it would be nice if I could
> direct my CLs to the appropriate people instead of hoping they see them.
>
> Gabe
> ___
> 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] PyBind11 as a SWIG replacement

[Jason Lowe-Power]

Hi Andreas,

I think it's OK for us to ignore the warnings. It isn't like SWIG didn't
dump out 1000s of warnings before.

I'll take a close look at the patch next Wed. or Thurs. Sorry for the delay.

Jason

On Wed, Mar 29, 2017 at 6:08 AM Andreas Sandberg 
wrote:

> Hi Everyone,
>
> Some time ago, I posted a series of changes [1] to switch from SWIG to
> PyBind for our Python wrappers. I'd like to know what people think about
> this move at a high level. Do we want to make this change?
>
> These are the main benefits I have identified:
>
>* PyBind11 can be redistributed with gem5, which means that we have
> full control of the version used. This avoid a large number of
> hard-to-debug SWIG issues we have seen in the past.
>
>* PyBind11 doesn't rely on a custom C++ parser, instead it relies on
> wrappers being explicitly declared in C++. The leads to slightly more
> boiler-plate code in manually created wrappers, but doesn't doesn't
> increase the overall code size. A big benefit is that this avoids
> strange compilation errors when SWIG doesn't understand modern language
> features.
>
>* Unlike SWIG, there is no risk that the wrapper code incorporates
> incorrect type casts (this has happened on numerous occasions in the
> past) since these will result in compile-time errors.
>
>* It fixes a compiler error we have been experiencing with some some
> SWIG versions when compiled using clang 3.8.
>
> * It becomes easier to export new methods to Python. In the simplest
> case, a place holder method can be declared in Python and decorated with
> @cxxMethod, which inherits the doc string from the place holder.
>
> The new wrappers have the following known issues:
>
>* Global events can't be memory managed correctly. This was the case
> in SWIG as well.
>
>* GCC 5.x seems to generate C++ ODR warnings in some cases when
> compiling the fast binary. See Pierre's comment on [2].
>
>* It changes the way custom methods are exported to Python (the
> export_methods class method is disappearing), which breaks the current API.
>
> Do we consider the ODR warnings to be serious enough to block this if we
> think the change is a good idea? I have been trying to reproduce them
> using PyBind's test suite, but without success so far.
>
> Cheers,
> Andreas
>
>
> [1]
>
> https://gem5-review.googlesource.com/#/q/topic:pybind11+(status:open+OR+status:merged)
> [2] https://gem5-review.googlesource.com/#/c/2231/
> 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] nightly regressions

[Jason Lowe-Power]

Hi Gabe,

I think you've interpreted everything correctly. I think the only context
you're missing is that we're planning to change the regressions such that
there is no dependence on proprietary binaries. This will allow all
users/developers to run the regressions before committing code. We haven't
made any progress in this direction, yet. We've just talked about it.

I think the biggest implication of this is that we'd drop the SPARC full
system tests completely. This also means we'd drop the EIO tests (which I
think we already have).

Slightly off topic:
One of my biggest gripes with the current regressions is that it is
incredibly hard for a user or a developer who commits code every once in a
while to run and understand the regression output. It's a good step for you
to be able to find the fishy stats changes and pin them to a commit, but I
really wish it was easier for our users to do that themselves.

Cheers,
Jason

On Sat, Apr 1, 2017 at 6:27 AM Gabe Black  wrote:

> Hi folks. I'm working through the nightly regressions to get them to a good
> point for a rebase of our internal branch of gem5, and I've noticed a few
> things:
>
> 1. The stats have been changed but not updated a bunch of times. I've
> identified almost all the points this has happened since the references
> were last updated, and have patches which fix them. Some stat changes are a
> little fishy, but I'll at least identify the guilty change(s) so that their
> authors can look them over.
> 2. The SPARC FS regression were just plain not running because its
> configuration had been broken. I'll have a patch to fix this.
> 3. The nightly regressions are still checking gem5 out from mercurial.
> 4. The "encumbered" repository has, as far as I can tell, not be converted
> from mercurial to git. Probably this isn't a problem because this code is
> mostly unchanging and becoming less relevant over time, especially since
> EIO support was removed from the process classes (it was, right?).
> 5. The EIO code is also broken, because it tries to call "fatal" with a
> "(void)" cast in front of it in a ternary operation. Something like "foo ?
> (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
> happened")". What "fatal" expands to now is apparently not compatible with
> this usage. Since I can access the encumbered repository, I can attempt to
> fix this.
>
> I can (and in at least in some cases will) fix most of these issues, except
> maybe 4 if we still want encumbered to exist. Please speak up if I've
> misinterpreted something or am missing some important bit of context.
>
> Gabe
> ___
> 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] adding reviewers in gerrit?

[Jason Lowe-Power]

Hi Paul and Gabe,

It should be working now. Let me know if you're still having issues.

Cheers,
Jason

On Tue, Apr 4, 2017 at 10:30 AM Paul Rosenfeld (prosenfeld) <
prosenf...@micron.com> wrote:

> Hi Jason,
>
> I don't know if you had a chance to look into this, but I just uploaded my
> first patch to gerrit and I also seem to be missing the ability to add
> reviewers. When I type someone into the reviewers box there is no auto
> complete and when I add someone manually and click OK, the reviewer field
> is still blank.
>
> Regards,
> Paul
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason
> Lowe-Power
> Sent: Saturday, March 25, 2017 11:38 AM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] adding reviewers in gerrit?
>
> Hi Gabe,
>
> Hmm... It works for me. It's possible that we don't have the permissions
> set up correctly to allow anyone to add reviewers. I just tested with a
> non-admin account and it doesn't work for that account either. I'll look
> into it.
>
> Cheers,
> Jason
>
> On Sat, Mar 25, 2017 at 5:32 AM Gabe Black  wrote:
>
> > Hi folks. I've uploaded a few CLs to gerrit now, and I notice that I
> > can't add reviewers since it claims everyone I try to add isn't a
> > registered user. That's very odd, because I'm trying to add people who
> > have given me review feedback on earlier changes, and people who I can
> > look up activity for on gerrit. Does anybody know why it's not
> > behaving for me? My other CL got reviewed so it's not a problem yet,
> > but it would be nice if I could direct my CLs to the appropriate people
> instead of hoping they see them.
> >
> > Gabe
> > ___
> > 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
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] nightly regressions

[Jason Lowe-Power]

Hi Gabe,

Thanks for going through and updating the stat files for all of the recent
changes. The people who used to volunteer to do that haven't had time
lately.

Is there any reason I shouldn't just check off on all of the stats changes?
Is there anything in the changesets to review?

Cheers,
Jason

On Tue, Apr 4, 2017 at 11:29 AM Steve Reinhardt  wrote:

> Here's the changeset Andreas was referring to:
>
> http://repo.gem5.org/gem5?cmd=changeset;node=b2720503a978
>
>
> On Tue, Apr 4, 2017 at 9:20 AM, Gabe Black  wrote:
>
> > I can't add reviewers due to a known issue, but here is the stack of CLs
> > which fix the regressions:
> >
> > https://gem5-review.googlesource.com/#/c/2641/
> >
> > Gabe
> >
> > On Tue, Apr 4, 2017 at 3:35 AM, Gabe Black  wrote:
> >
> > > Oh, also, the problem with EIO I think is not because there are EIO
> > > regressions, it's that the EIO code is being added in with EXTRAS and
> > > breaking the build for certain targets. Excluding it would be fairly
> > > trivial if I had write permission for the regression script on zizzer.
> > >
> > > Gabe
> > >
> > > On Tue, Apr 4, 2017 at 3:32 AM, Gabe Black 
> wrote:
> > >
> > >> Yeah, there are a lot of problems with the current system. It has
> three
> > >> real functions:
> > >>
> > >> 1. Making sure things run from end to end without crashing.
> > >> 2. Checking for inadvertent changes to the stats.
> > >> 3. Checking for non-determinstic behavior.
> > >>
> > >> Unfortunately it takes a really long time to run, doesn't distinguish
> > >> between trivial and non-trivial divergence in behavior, is really hard
> > to
> > >> merge, doesn't tell you what's not working if something is broken, has
> > >> dependencies with major complications, isn't very useful when people
> > >> diverge from upstream, etc.
> > >>
> > >> I think there is definitely a role for that sort of test since those
> are
> > >> meaningful, but then there are lots and lots of potential testing that
> > >> we're not doing. We should have the few unit tests that already exist
> > all
> > >> either pass or fail, not just output something, and then make them
> > >> easy/automatic to run, and we should have more of them. There are vast
> > >> swathes of functionality that really should be tested with unit tests
> > like:
> > >>
> > >> 1. The CPU models.
> > >> 2. All the instructions for all the ISAs.
> > >> 3. All the Device models.
> > >> etc. etc.
> > >>
> > >> The amount of work it would/will take to cover the gap in testing is
> > >> enormous, but in my opinion that's the technical debt that has to be
> > paid
> > >> down to straighten things out.
> > >>
> > >> Gabe
> > >>
> > >> On Tue, Apr 4, 2017 at 2:55 AM, Andreas Sandberg <
> > >> andreas.sandb...@arm.com> wrote:
> > >>
> > >>> On 01/04/2017 12:27, Gabe Black wrote:
> > >>>
> >  Hi folks. I'm working through the nightly regressions to get them
> to a
> >  good
> >  point for a rebase of our internal branch of gem5, and I've noticed
> a
> >  few
> >  things:
> > 
> >  1. The stats have been changed but not updated a bunch of times.
> I've
> >  identified almost all the points this has happened since the
> > references
> >  were last updated, and have patches which fix them. Some stat
> changes
> >  are a
> >  little fishy, but I'll at least identify the guilty change(s) so
> that
> >  their
> >  authors can look them over.
> > 
> > >>>
> > >>> This is really hard to get right with the current system of "push to
> > >>> submit". I would really like to avoid including stat updates in
> normal
> > >>> code submissions. It would make it really hard to automatically
> submit
> > >>> code (there would be stat conflicts for every single non-trivial
> > change)
> > >>> and it'd make cherry-picking really annoying.
> > >>>
> > >>> Ideally, the CI system should compare the stat output after applying
> a
> > >>> CL to the previous stat update. That way, you can easily spot the
> > >>> difference when submitting new code.
> > >>>
> > >>> 2. The SPARC FS regression were just plain not running because its
> >  configuration had been broken. I'll have a patch to fix this.
> >  3. The nightly regressions are still checking gem5 out from
> mercurial.
> > 
> > >>>
> > >>> We should obviously fix this. However, the repo is kept in sync with
> > the
> > >>> golden git repo using a cron, so it's not quite as bad as it seems.
> > >>>
> > >>> 4. The "encumbered" repository has, as far as I can tell, not be
> >  converted
> >  from mercurial to git. Probably this isn't a problem because this
> code
> >  is
> >  mostly unchanging and becoming less relevant over time, especially
> > since
> >  EIO support was removed from the process classes (it was, right?).
> >  5. The EIO code is also broken, because it tries to call "fatal"
> with
> > a
> >  "(void)" cast in front of it in a ternary operation. Something like
> >  "foo ?
> >  (void)fat

Re: [gem5-dev] RISC-V Patches False Dependencies

[Jason Lowe-Power]

Hi Alec,

I believe you can "cherry-pick" the change in the gerrit UI. Although, it
could just be something that admins are allowed to do... Also, I won't
comment on how cherry picking the change will affect your local branch.

Jason

On Wed, Apr 5, 2017 at 2:45 PM Alec Roelke  wrote:

> Hi Everyone,
>
> I have several RISC-V patches that have sufficient reviews that I'd like to
> submit them, but it seems that I can't because gerrit thinks they have
> dependencies on some other patches that do not have sufficient reviews
> yet.  They don't actually have any dependencies, so is it possible to
> remove those dependencies in gerrit?
>
> Also, two of the patches (#2341
>  and #2304
> ) have been sitting for a
> while with only +1 review.  Even if the other patches don't have explicit
> dependencies on them, they are important for the functioning of RISC-V
> (especially #2341).  Could someone review them?
>
> Thanks,
> Alec Roelke
> ___
> 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] Should we reduce testing for poorly supported architectures?

[Jason Lowe-Power]

Hi Andreas,

My thoughts are inline below.

On Thu, Apr 6, 2017 at 4:04 AM Andreas Sandberg 
wrote:

> Hi Everyone,
>
> Gabe's heroic effort to refresh the reference stats (thanks Gabe!) have
> once again highlighted issues in the current test regime.
>
> My impression is that some of the affected tests are only marginally
> useful. Especially for architecture that are largely unmaintained. I
> don't want to rekindle the discussion about retiring ISAs. However, I
> would suggest that we reduce the amount of time we spend testing these
> ISAs. In particular, I would like to see these changes:
>
> 1. Remove all SPEC-based tests for poorly supported ISAs
>

Yes. In fact, I think that in the medium-term we should remove all
spec-based tests since we can't distribute the binaries.

>
> 2. Remove stat diffing for all remaining tests for poorly supported ISAs.
>

Sure. The stats for each component should be ISA-independent and covered by
other, better supported, ISAs. The only thing we would lose here is stats
diffing when these ISAs are updated (very rarely).


> 3. Remove stat diffing for the learning gem5 tests. We mainly want to
> make sure that these scripts can be run.
>

Definitely! I thought this was already done...

>
> 4. Consider removing O3 (and minor?) tests for poorly supported ISAs
>

We've said this many times... we should construct the matrix of what ISAs x
CPU models x coherence protocols we support. If it's marked as supported on
the matrix, we should test it. I don't know if these models are currently
"supported" for any of these ISAs.

>
> I would argue that "poorly supported ISAs" would be the following:
>* SPARC
>* POWER
>* MIPS
>* ALPHA?
>

Seems reasonable to me.


>
> Thoughts?
>
> //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] scons question

[Jason Lowe-Power]

Hi Gabe,

Just today I was looking at incremental linking and breaking gem5 into
"components". I was specifically looking at it as a stepping stone to use
Bazel (https://bazel.build/) as the build system instead of Scons. On a
side note, it looks like Bazel has a lot of features that we could take
advantage of. There are a couple of downsides, but that's a conversation
for another time.

What makes it hard to break gem5 into components is that everything is very
tightly coupled. For instance, I was trying to compile just "base" thinking
it was the simplest. But it depends on debug (which is everywhere, and
nowhere), serializable (which depends on stuff in sim/), the event queue
logic, and some stuff in ext/! Similarly, almost everything somehow depends
on the ISA. There are also a number of circular dependencies. It's far from
straightforward to get any one directory to compile without all of the
others.

Overall, I think what we would need to do to make this happen is completely
reorganize gem5's source. I think this would be good in the long run, but
it would take me at least 2-4 weeks. Maybe I'm slower than others, though.
There is a huge downside to this, too. All internal patches would be very
hard to apply after making a change like this.

Just a few thoughts.

Cheers,
Jason

PS: For error 127, I would just do something hacky, personally. In the long
run, we should do something to make gem5 more modular and move away from
SCons. But I don't think it's worth it just for this one issue.

On Thu, Apr 13, 2017 at 3:10 PM Gabe Black  wrote:

> Ok, I think we're all pretty much in agreement then, since I was thinking
> about incremental linking too. What about it looked non-trivial, Steve? I
> haven't dug into it very much yet, but as long as it doesn't turn into too
> much of an ordeal I'd like to take care of it.
>
> Potentially less ideal solutions which might also be easier would be to
> override the env['SPAWN'] setting so that it would skip going through the
> shell if it could, and seeing if we could load some things that are
> currently on the command line from files of options/input files.
>
> I think the reason scons is purposefully going through the shell is to make
> things like redirection, etc., work. We take advantage of that in at least
> one place I've seen, but it might be feasible to remove that and specialize
> env['SPAWN'] in a way that breaks redirection but allows arbitrarily long
> command lines.
>
> But I still think incremental linking would be nicer for a number of other
> reasons, as long as it's implementable.
>
> Gabe
>
> On Thu, Apr 13, 2017 at 10:16 AM, Steve Reinhardt 
> wrote:
>
> > #3 is the traditional solution :)
> >
> > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony <
> > anthony.gutier...@amd.com> wrote:
> >
> > > There are a three ways to fix this as far as I can tell:
> > >
> > > 1) Modify our Scons setup to use staged linking.
> > > 2) Recompile your kernel to allow for larger ARG_MAX.
> > > 3) Modify your paths etc to avoid long names
> > >
> > > 1) seems to be the best option, but seems like it could be a lot of
> work.
> > >
> > > -Original Message-
> > > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
> > Black
> > > Sent: Thursday, April 13, 2017 9:50 AM
> > > To: gem5 Developer List 
> > > Subject: Re: [gem5-dev] scons question
> > >
> > > Oh, I bet you're right. They actually spawn something like 'sh', '-c',
> '
> > > '.join(args), and I bet sh (which is symlinked to /bin/bash) is blowing
> > up
> > > because the command line is very long. I remember my terminal asking
> if I
> > > really wanted to copy/paste something like 129K characters when trying
> to
> > > copy the command line to run it outside of scons.
> > >
> > > Now to figure out how to fix it...
> > >
> > > On Thu, Apr 13, 2017 at 8:02 AM, Beckmann, Brad  >
> > > wrote:
> > >
> > > > Have you investigated the length of the linker command when building
> > > > from outside the gem5 directory?  In the past, we've seen that
> > > > mysterious error
> > > > 127 because the linker stage uses a shell command length that exceeds
> > > > the length supported by the OS.  64KB I believe.  I suspect that the
> > > > filenames are longer when building outside of gem5, thus it only
> > > > happens in that situation.  The linker command may be shorter using
> > > clang as well.
> > > >
> > > > Brad
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
> > > > Black
> > > > Sent: Thursday, April 13, 2017 1:53 AM
> > > > To: gem5 Developer List 
> > > > Subject: [gem5-dev] scons question
> > > >
> > > > Hi folks. I'm fighting with a very confusing problem with scons at
> the
> > > > moment. For reasons I haven't determined, when I have things set up
> to
> > > > build when scons is run from outside the gem5 directory (using -C),
> it
> > > > fails the final linker step with error 127 and no other ou

[gem5-dev] Changes to commit keywords

[Jason Lowe-Power]

Hi all,

I have a patch on Gerrit right now (
https://gem5-review.googlesource.com/c/2760/) which heavily modifies the
commit keywords (and assigns some maintainers to different gem5
subsystems). In case it was missed when the gerrit notification went out, I
wanted to make sure that everyone has had a chance to review it before I
pushed it in.

The new commit keywords are flexible. Please let me know (by reviewing the
patch) if you have any suggestions!

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

Re: [gem5-dev] Review Request 3790: x86: fixed branching computation for branch uops that only changes nupc and not npc

[Jason Lowe-Power]

> On Jan. 25, 2017, 7:45 a.m., Gabe Black wrote:
> > Ship It!
> 
> Santi Galan wrote:
> Let me comment on this review request to bring it to live since it seems 
> like it has not been applied yet. Is there anything missing in order to be 
> applied?
> 
> Thanks,
> Santi Galan

No. I'll pull it into the repository. Thanks for pinging me on it.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3790/#review9314
---


On Jan. 23, 2017, 3:39 p.m., Santi Galan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3790/
> ---
> 
> (Updated Jan. 23, 2017, 3:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11801:80af6a1e6beb
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> x86: fixed branching() computation for branch uops that only changes nupc and 
> not npc
> 
> When a branch micro-op belongs to a flow and the micro-op does not change the 
> nPC and just updates the nuPC
> (like a 'rep movs' flow), `branching()` function always returns not-taken no 
> matter  actual
> micro-branch outcome. Provided fix adds to the equation  nuPC attribute 
> checking since these kind of branch
> micro-op only updates that pointer.
> 
> This issue has been found while debugging the performance of a copy-loop 
> implemented with `memcopy` function. Without the fix, 'rep movss' internal 
> micro-branch was always predicted as not-taken causing an squash event after 
> every branch micro-branch execution.
> 
> Using the provided test, branch mispredition went from *1922* without the fix 
> to *7*.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/types.hh e47703369039 
> 
> Diff: http://reviews.gem5.org/r/3790/diff/
> 
> 
> Testing
> ---
> 
> I used this command line to evaluate the performance:
> 
> ```
> ./build/X86/gem5.opt configs/example/se.py --cpu-type=detailed --caches 
> --l2cache -c /path/to/binary
> ```
> 
> This is the source code of the binary:
> ```
> #include 
> #include "m5op.h"
> 
> #define SIZE 15*1024
> 
> //arrays are cache aligned
> char a [SIZE] __attribute__((aligned(0x40)));
> char b [SIZE] __attribute__((aligned(0x40)));
> 
> int main ()
> {
> //some warmup
> int i;
> for (i = 0; i < SIZE; ++i)
> {
> a[i] = 1;
> b[i] = 2;
> }
> 
> m5_reset_stats(0, 0);
> memcpy(a, b, SIZE);
> m5_exit(0);
> 
> //keep compiler happy
> return 0;
> }
> ```
> 
> Which was compiled with this makefile:
> 
> ```
> GEM5_PATH=/path/to/gem5
> 
> binary: binary.c $(GEM5_PATH)/util/m5/m5op_x86.S
>   gcc -o $@ $^ -static -I$(GEM5_PATH)/util/m5
> ```
> 
> 
> Thanks,
> 
> Santi Galan
> 
>

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

Re: [gem5-dev] m5 utility in KVM mode on arm

[Jason Lowe-Power]

Hi Gabe,

I'm not sure about ARM, but for x86, when running with KVM the "magic
instructions" use MMIO. Most of them work fine for x86, except readfile,
which I need to post a patch for. I'm pretty sure that ARM works the same
way, but maybe Andreas S. can answer better.

Cheers,
Jason

On Wed, Apr 19, 2017 at 6:09 PM Gabe Black  wrote:

> Hi everybody. Weiping is a colleague of mine at Google, and he's trying to
> use the m5 utility to take a checkpoint from within a simulation on aarch64
> which is running in KVM mode. The utility was causing an illegal
> instruction fault, and so I started looking into it for him.
> Unsurprisingly, the illegal instruction actually is an illegal instruction
> which would trigger the checkpointing pseudo instruction if gem5 had seen
> it, but I believe everything stayed within kvm land and so no checkpoint
> was taken.
>
> I remember a while ago there being an effort to switch the pseudo
> instructions over to be a magical device with the same behavior so that it
> could trap reads/writes when in KVM mode. I see some evidence that support
> was added for that in the 32 bit version of the m5 utility, but then later
> removed because it caused other problems. I don't see any evidence that
> that support was added to the 64 bit version.
>
> What's the current state of this? Is this something we could get working
> with a reasonably small amount of effort, or is there a workaround, or...?
>
> Gabe
> ___
> 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] Meeting notes about internal vs external Python code

[Jason Lowe-Power]

Hi all,

In the spirit of openness, I've included the notes from the meeting a few
of us had earlier today.

This was spawned from the conversation on this changeset on Gerrit:
https://gem5-review.googlesource.com/c/2860/.

https://docs.google.com/document/d/1cOOLxEpOK9t8zEtj6SKqYdlw2_GDS81t0BurUHwFxuQ/edit?usp=sharing


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

Re: [gem5-dev] Ruby support for Address Ranges and ARM systems

[Jason Lowe-Power]

Hi Nikos,

Wow! Thanks for this contribution. I'm excited that you've enabled
ARM+Ruby! It's something we (I?) should have done long ago.

I've gone through most of the changes except for the big one enabling
AddrRanges for the directories. I'll sit down and try to grok that change
tomorrow morning and probably follow up with some questions.

Thanks again!

Cheers,
Jason

On Thu, Apr 27, 2017 at 6:05 AM Nikos Nikoleris 
wrote:

> Hi Everyone,
>
> I've just posted a set of patches that allow ARM Realview systems to boot
> Linux with Ruby.
>
> The major change in these patches is the added support for address ranges
> in the Directory. Systems like ARM that don't assume a continuous memory
> range starting from 0 used to be a problem for the Ruby Directory. This
> change addresses this issue and adds more flexibility in the address range
> of a Directory. We still support interleaving and now we can specify
> hashing too.
>
> There is also a small patch that fixes an issue with the LL/SC memory
> requests and finally changes that add regressions for arm-ruby systems.
>
> This set of changes allows a basic ARM system to boot Linux with Ruby but
> your mileage may vary.
>
> I am looking forward to your reviews and thoughts. For anyone interested
> you the changes are here:
>
>
> https://gem5-review.googlesource.com/q/topic:%2522arm-ruby%2522+(status:open%20OR%20status:merged)
>
> Thanks,
>
> Nikos
>
>
> 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] update ARM Full-System Files (aarch-system-2014-10.tar.xz)

[Jason Lowe-Power]

Hi Pau and Andreas,

I've uploaded the file to the server. You can add a link on the wiki page
to http://www.gem5.org/dist/current/arm/aarch-system-20170421.tar.xz. Let
me know if you need me to move it somewhere else or if you need anything
else uploaded.

Cheers,
Jason

On Fri, Apr 28, 2017 at 11:51 AM Andreas Sandberg 
wrote:

> Hi Pau,
>
> It seems like this is a bit more complicated than I anticipated. The
> dist files are too big to be handled by the wiki, so they are apparently
> stored as static files in the file system on the web server. I'll have
> to make some enquiries and get back to you.
>
> I think putting the script in util would make a lot of sense.
>
> Cheers,
> Andreas
>
>
> On 28/04/2017 14:08, Pau Cabre wrote:
> > Hi Andreas,
> >
> > My username for the gem5 wiki is Pcabre
> >
> > I agree that it makes sense to have something that gets distributed with
> gem5 that automatically builds the kernels, the bootloaders and the DTBs
> (disk images may be another story though).
> > Were you thinking about something like a python script in the "util"
> directory? If yes, I should be able to do it.
> >
> > Thanks,
> > Pau
> >
> > -Original Message-
> > From: Andreas Sandberg [mailto:andreas.sandb...@arm.com]
> > Sent: jueves, 27 de abril de 2017 15:17
> > To: gem5 Developer List 
> > Subject: Re: [gem5-dev] update ARM Full-System Files
> (aarch-system-2014-10.tar.xz)
> >
> > Hi Pau,
> >
> > Thanks for creating these instructions and Dockerfiles! This is
> something that has been on my todo/wish list for a very long time.
> >
> > I should be able to give you the permissions necessary to upload the
> system image to the wiki. Do you have a user name that I can bless?
> >
> > It'd be nice if we could standardise and automate the process of
> updating the distribution binaries using a set of scripts that get
> distributed with gem5. Docker is very convenient, but is a bit of overkill
> if you already have the necessary environment up and running on your
> workstation. The Docker script could then reuse these scripts for
> automation. This would be a much appreciated contribution. How would you
> feel about contributing these scripts in that way?
> >
> > Cheers,
> > Andreas
> >
> > On 21/04/2017 15:10, Pau Cabre wrote:
> >> Hi all,
> >>
> >> I made some changes to the Dockerfile in order to generated DTBs and
> kernel filenames more in accordance with the current names in
> aarch-system-2014-10.tar.xz.
> >> The newly generated files can be found here:
> >> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/releas
> >> es/download/20170421/aarch-system-20170421.tar.xz
> >>
> >> I have also just pushed a changeset to gerrit in order to use these
> >> new files: https://gem5-review.googlesource.com/2841
> >> With these changes, if the new filenames are not found, the old ones
> will be used.
> >>
> >> If the changes get accepted, it would be good to copy the
> aarch-system-20170421.tar.xz file to somewhere in the gem5.org wiki.
> >>
> >> Thanks,
> >> Pau
> >>
> >> -Original Message-
> >> From: Pau Cabre [mailto:pau.ca...@metempsy.com]
> >> Sent: jueves, 13 de abril de 2017 0:41
> >> To: gem5-dev@gem5.org
> >> Subject: Re: [gem5-dev] update ARM Full-System Files
> >> (aarch-system-2014-10.tar.xz)
> >>
> >> Hi Mohammad,
> >>
> >> I have posted a Dockerfile to generate up-to-date arm full system
> >> files (to the best of my knowledge) in this repository:
> >> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/
> >> You can also directly access the generated files here:
> >> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/releas
> >> es/download/201704/aarch-system-2017-04.tar.xz
> >>
> >> The README.md has some information and command line examples for using
> the new files.
> >>
> >> Please feel free to try/modify them and provide any feedback.
> >>
> >> If everybody agrees with these new files, ideally we should upload the
> released .tar.xz file to the gem5.org wiki and do some small changes to
> FSConfig.py in order to use the new files by default.
> >>
> >> Thank you very much!
> >> Pau
> >>
> >>
> >> -Original Message-
> >> From: Mohammad Alian [mailto:m.alian1...@gmail.com]
> >> Sent: martes, 11 de abril de 2017 21:19
> >> To: gem5 Developer List 
> >> Subject: Re: [gem5-dev] update ARM Full-System Files
> >> (aarch-system-2014-10.tar.xz)
> >>
> >> Thanks a lot for bringing this up. I wanted to start such conversation
> for a long time as all the full system files in the webpage are deprecated.
> >>
> >> Thank you,
> >> Mohammad
> >>
> >> On Fri, Apr 7, 2017 at 9:59 AM, Pau Cabre 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> I would like to start a discussion about updating the
> >>> http://www.gem5.org/dist/current/arm/aarch-system-2014-10.tar.xz
> >>> file, which should contain the necessary files for running arm
> >>> FullSystem simulations.
> >>>
> >>> To the best of my knowledge, it has at least a couple of deprecated
> f

Re: [gem5-dev] site_scons

[Jason Lowe-Power]

Hi Gabe,

Reorganizing the SCons files would undoubtedly improve the build system.
Before you get started down this road, I thought you'd might like to know
some of the discussions we've been having about the gem5 build system.

We've been musing a move away from SCons. I think Andreas has done some
initial work in getting cmake support, and we've been talking to some
Google people about the pros/cons of moving to Bazel. We don't have any
short-term plans, and I haven't done anything more than look at it and
become overwhelmed. So take this information however you like :).

Cheers,
Jason

On Tue, May 2, 2017 at 4:04 AM Andreas Sandberg 
wrote:

> Hi Gabe,
>
> I'm planning to push the pybind patches today. I'm currently re-running
> the full regression suite to ensure that there are no rebasing issues.
> Once that completes, I'll hit the blue button and submit it.
>
> //Andreas
>
> On 02/05/2017 06:31, Gabe Black wrote:
> > Hi folks. I've been working on our scons setup a lot in the last week or
> > so, and having everything in one or two really long files makes it really
> > easy to lose track of where things are, what you're working on, where
> > values came from, etc. scons has a mechanism called site_scons which
> sounds
> > like a way to group things into python packages, etc., so that they can
> > have some organization.
> >
> > Would anybody oppose moving to that sort of arrangement? I wouldn't want
> to
> > start doing anything like that pre move away from swig since that might
> > make merging, etc., very painful. Any ETA on the pybind stuff getting in?
> >
> > Gabe
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
>
> 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] update ARM Full-System Files (aarch-system-2014-10.tar.xz)

[Jason Lowe-Power]

The file is uploaded to the same place as the previous one.

Cheers,
Jason

On Wed, May 3, 2017 at 10:55 AM Pau Cabre  wrote:

> Hi Jason/Andreas,
>
> Thank you very much for the upload.
> Could you also upload the newer release which uses kernel 4.4 instead of
> 4.3 for the VExpress_GEM5_V1 platforms?
>
> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/releases/download/20170426/aarch-system-20170426.tar.xz
>
> Now we need to think about how to make the transition from the old files
> to the new ones. I am relatively new to gem5 and I do not know how this has
> been done before, but I would say that it is worth considering something
> like what I did in https://gem5-review.googlesource.com/c/2841/
> Any other idea?
>
> Regarding updating the links in the gem5 wiki, I do not have permissions
> for editing http://gem5.org/Download nor for creating new pages, so
> somebody else will have to do it.
>
> Thanks again,
> Pau
>
>
> -Original Message-
> From: Jason Lowe-Power [mailto:ja...@lowepower.com]
> Sent: lunes, 1 de mayo de 2017 16:36
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] update ARM Full-System Files
> (aarch-system-2014-10.tar.xz)
>
> Hi Pau and Andreas,
>
> I've uploaded the file to the server. You can add a link on the wiki page
> to http://www.gem5.org/dist/current/arm/aarch-system-20170421.tar.xz. Let
> me know if you need me to move it somewhere else or if you need anything
> else uploaded.
>
> Cheers,
> Jason
>
> On Fri, Apr 28, 2017 at 11:51 AM Andreas Sandberg <
> andreas.sandb...@arm.com>
> wrote:
>
> > Hi Pau,
> >
> > It seems like this is a bit more complicated than I anticipated. The
> > dist files are too big to be handled by the wiki, so they are
> > apparently stored as static files in the file system on the web
> > server. I'll have to make some enquiries and get back to you.
> >
> > I think putting the script in util would make a lot of sense.
> >
> > Cheers,
> > Andreas
> >
> >
> > On 28/04/2017 14:08, Pau Cabre wrote:
> > > Hi Andreas,
> > >
> > > My username for the gem5 wiki is Pcabre
> > >
> > > I agree that it makes sense to have something that gets distributed
> > > with
> > gem5 that automatically builds the kernels, the bootloaders and the
> > DTBs (disk images may be another story though).
> > > Were you thinking about something like a python script in the "util"
> > directory? If yes, I should be able to do it.
> > >
> > > Thanks,
> > > Pau
> > >
> > > -Original Message-
> > > From: Andreas Sandberg [mailto:andreas.sandb...@arm.com]
> > > Sent: jueves, 27 de abril de 2017 15:17
> > > To: gem5 Developer List 
> > > Subject: Re: [gem5-dev] update ARM Full-System Files
> > (aarch-system-2014-10.tar.xz)
> > >
> > > Hi Pau,
> > >
> > > Thanks for creating these instructions and Dockerfiles! This is
> > something that has been on my todo/wish list for a very long time.
> > >
> > > I should be able to give you the permissions necessary to upload the
> > system image to the wiki. Do you have a user name that I can bless?
> > >
> > > It'd be nice if we could standardise and automate the process of
> > updating the distribution binaries using a set of scripts that get
> > distributed with gem5. Docker is very convenient, but is a bit of
> > overkill if you already have the necessary environment up and running
> > on your workstation. The Docker script could then reuse these scripts
> > for automation. This would be a much appreciated contribution. How
> > would you feel about contributing these scripts in that way?
> > >
> > > Cheers,
> > > Andreas
> > >
> > > On 21/04/2017 15:10, Pau Cabre wrote:
> > >> Hi all,
> > >>
> > >> I made some changes to the Dockerfile in order to generated DTBs
> > >> and
> > kernel filenames more in accordance with the current names in
> > aarch-system-2014-10.tar.xz.
> > >> The newly generated files can be found here:
> > >> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/rel
> > >> eas es/download/20170421/aarch-system-20170421.tar.xz
> > >>
> > >> I have also just pushed a changeset to gerrit in order to use these
> > >> new files: https://gem5-review.googlesource.com/2841
> > >> With these changes, if the new filenames are not found, the old
> > >> ones
> > wi

Re: [gem5-dev] Review Request 3800: x86: fix Mul1u instruction

[Jason Lowe-Power]

> On Feb. 4, 2017, 4:21 p.m., Jason Lowe-Power wrote:
> > Lol, that code is hard to understand. But, LGTM.
> > 
> > What are you using to test this? Any chance you can commit the test so we 
> > don't accidentally break this again in the future?
> 
> Tony Gutierrez wrote:
> This bug was manifesting in the ROCr runtime while it is loading 
> libraries, it manifested as a segfualt (unmapped addr panic) because an 
> address calculation was corrupted due to this instruction. I manually tested 
> this instruction by comparing its output to the result of 64b multiplication 
> using __uint128_t. This is a perfect example of where instruction tests would 
> be useful. It only seemed to give bad output with certain inputs, which gave 
> the error the appearance of being non-deterministic.

Resurecting this from the grave... does anyone have any objections to me just 
pushing this? I spent all day tracking down a bug, which was fixed by this 
patch.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3800/#review9400
---


On Feb. 4, 2017, 12:13 a.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3800/
> ---
> 
> (Updated Feb. 4, 2017, 12:13 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11778:c76b78110490
> ---
> x86: fix Mul1u instruction
> 
> the Mul1uFlags and Mul1u instructions perform
> the 64b multiplication using only 64b registers, however the
> method used causes the high 64b to be corrupted for certain
> inputs. here we fix the computation.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/microops/regop.isa 
> ed89cb178ecd7586296d2a2e83595174474db554 
> 
> Diff: http://reviews.gem5.org/r/3800/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

Re: [gem5-dev] Patch Submission Responsibility

[Jason Lowe-Power]

Hi Alec,

Sorry this isn't clear (maybe we need to update the CONTRIBUTING document).
Once you have the required reviews, the "submit" button will become active.
At that time, you can just push it to submit your own code.

Cheers,
Jason

On Mon, May 15, 2017 at 2:24 PM Alec Roelke  wrote:

> Hello Everyone,
>
> I have a patch that fixes a problem with forwarding memory requests and
> locked loads that has received the required reviews from reviewers and the
> maintainer (who isn't me) but hasn't been committed for a couple of weeks.
> Is it my responsibility now to commit the patch, or the maintainer's?
>
> Thanks,
> Alec
> ___
> 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] Review Request 3800: x86: fix Mul1u instruction

[Jason Lowe-Power]

Gabe: Do you want me to wait to push this patch? We can have Tony re-post
to gerrit if you want to review it. That would be way easier for me anyway.

We need a way to test for these kinds of errors. It's quite upsetting that
we've had this error in multiply for so long.

Jason

On Mon, May 15, 2017 at 2:50 PM Gabe Black  wrote:

> Please give me a chance to look at it. I think the checker CPU is for
> comparing, say, the O3 CPU against what's effectively the simple CPU. If an
> instruction doesn't do the right thing, it will do the wrong thing no
> matter which CPU is executing it. You can compare against actual execution
> on a real CPU using the statetrace tool, although I saw that somebody
> rearranged all the process startup code which I'd originally carefully
> matched against actual Linux process startup, so that tool probably doesn't
> give any useful information any more.
>
> Gabe
>
> On Mon, May 15, 2017 at 12:45 PM, Joe Gross  wrote:
>
>>
>>
>> > On Feb. 4, 2017, 10:21 a.m., Jason Lowe-Power wrote:
>> > > Lol, that code is hard to understand. But, LGTM.
>> > >
>> > > What are you using to test this? Any chance you can commit the test
>> so we don't accidentally break this again in the future?
>> >
>> > Tony Gutierrez wrote:
>> > This bug was manifesting in the ROCr runtime while it is loading
>> libraries, it manifested as a segfualt (unmapped addr panic) because an
>> address calculation was corrupted due to this instruction. I manually
>> tested this instruction by comparing its output to the result of 64b
>> multiplication using __uint128_t. This is a perfect example of where
>> instruction tests would be useful. It only seemed to give bad output with
>> certain inputs, which gave the error the appearance of being
>> non-deterministic.
>> >
>> > Jason Lowe-Power wrote:
>> > Resurecting this from the grave... does anyone have any objections
>> to me just pushing this? I spent all day tracking down a bug, which was
>> fixed by this patch.
>>
>> This is an important patch for x86, I say push it. Also it would be nice
>> if we were eventually able to use the CheckerCpu for x86 (I believe it's
>> ARM-only right now), as there might be more hard-to-find bugs like this one.
>>
>>
>> - Joe
>>
>
>>
>> ---
>
>
>> This is an automatically generated e-mail. To reply, visit:
>>
> http://reviews.gem5.org/r/3800/#review9400
>> ---
>>
>>
>> On Feb. 3, 2017, 6:13 p.m., Tony Gutierrez wrote:
>> >
>> > ---
>
>
>> > This is an automatically generated e-mail. To reply, visit:
>> > http://reviews.gem5.org/r/3800/
>>
> > ---
>> >
>> > (Updated Feb. 3, 2017, 6:13 p.m.)
>> >
>> >
>> > Review request for Default.
>> >
>> >
>> > Repository: gem5
>> >
>> >
>> > Description
>> > ---
>>
>
>> >
>> > Changeset 11778:c76b78110490
>> > ---
>> > x86: fix Mul1u instruction
>> >
>> > the Mul1uFlags and Mul1u instructions perform
>> > the 64b multiplication using only 64b registers, however the
>> > method used causes the high 64b to be corrupted for certain
>> > inputs. here we fix the computation.
>> >
>> >
>> > Diffs
>> > -
>> >
>> >   src/arch/x86/isa/microops/regop.isa
>> ed89cb178ecd7586296d2a2e83595174474db554
>> >
>> > Diff: http://reviews.gem5.org/r/3800/diff/
>> >
>> >
>> > Testing
>> > ---
>> >
>> >
>> > Thanks,
>> >
>> > Tony Gutierrez
>> >
>> >
>>
>> ___
>> 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] Review Request 3800: x86: fix Mul1u instruction

[Jason Lowe-Power]

We should definitely look into the statetrace tool. I'll put it on my giant
gem5 list of things to do.

Those of you in industry: There must be some test harnesses for hardware
and internal simulators. How do you test to make sure instructions are
implemented correctly?

We've thought about using llvm or gcc tests, but they don't really test
what we need, IIRC.

Maybe this would be a good summer project for an intern: hint, hint.

Jason

On Mon, May 15, 2017 at 3:04 PM Gross, Joe  wrote:

> Probably we all agree that x86 could use some automated error checking,
> but I’m not sure of any way to do this without a ton of work. CheckerCPU
> seemed good, but as Gabe points out, this may not be comparing against the
> host hardware.
>
>
>
> Jason, do you know any way that’s partially or mostly implemented that we
> could reuse?
>
>
>
> Joe
>
>
>
> *From:* Jason Lowe-Power [mailto:ja...@lowepower.com]
> *Sent:* Monday, May 15, 2017 2:54 PM
> *To:* Gabe Black ; gem5 Developer List <
> gem5-dev@gem5.org>
> *Cc:* Gutierrez, Anthony ; Gross, Joe <
> joseph.gr...@amd.com>
> *Subject:* Re: [gem5-dev] Review Request 3800: x86: fix Mul1u instruction
>
>
>
> Gabe: Do you want me to wait to push this patch? We can have Tony re-post
> to gerrit if you want to review it. That would be way easier for me anyway.
>
>
>
> We need a way to test for these kinds of errors. It's quite upsetting that
> we've had this error in multiply for so long.
>
>
>
> Jason
>
>
>
> On Mon, May 15, 2017 at 2:50 PM Gabe Black  wrote:
>
> Please give me a chance to look at it. I think the checker CPU is for
> comparing, say, the O3 CPU against what's effectively the simple CPU. If an
> instruction doesn't do the right thing, it will do the wrong thing no
> matter which CPU is executing it. You can compare against actual execution
> on a real CPU using the statetrace tool, although I saw that somebody
> rearranged all the process startup code which I'd originally carefully
> matched against actual Linux process startup, so that tool probably doesn't
> give any useful information any more.
>
>
>
> Gabe
>
>
>
> On Mon, May 15, 2017 at 12:45 PM, Joe Gross  wrote:
>
>
>
> > On Feb. 4, 2017, 10:21 a.m., Jason Lowe-Power wrote:
> > > Lol, that code is hard to understand. But, LGTM.
> > >
> > > What are you using to test this? Any chance you can commit the test so
> we don't accidentally break this again in the future?
> >
> > Tony Gutierrez wrote:
> > This bug was manifesting in the ROCr runtime while it is loading
> libraries, it manifested as a segfualt (unmapped addr panic) because an
> address calculation was corrupted due to this instruction. I manually
> tested this instruction by comparing its output to the result of 64b
> multiplication using __uint128_t. This is a perfect example of where
> instruction tests would be useful. It only seemed to give bad output with
> certain inputs, which gave the error the appearance of being
> non-deterministic.
> >
> > Jason Lowe-Power wrote:
> > Resurecting this from the grave... does anyone have any objections
> to me just pushing this? I spent all day tracking down a bug, which was
> fixed by this patch.
>
> This is an important patch for x86, I say push it. Also it would be nice
> if we were eventually able to use the CheckerCpu for x86 (I believe it's
> ARM-only right now), as there might be more hard-to-find bugs like this one.
>
>
> - Joe
>
>
>
> ---
>
>
> This is an automatically generated e-mail. To reply, visit:
>
> http://reviews.gem5.org/r/3800/#review9400
> ---
>
>
> On Feb. 3, 2017, 6:13 p.m., Tony Gutierrez wrote:
> >
> > ---
>
>
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviews.gem5.org/r/3800/
>
> > ---
> >
> > (Updated Feb. 3, 2017, 6:13 p.m.)
>
> >
> >
> > Review request for Default.
> >
> >
> > Repository: gem5
> >
> >
> > Description
> > ---
>
>
> >
> > Changeset 11778:c76b78110490
> > ---
> > x86: fix Mul1u instruction
> >
> > the Mul1uFlags and Mul1u instructions perform
> > the 64b multiplication using only 64b registers, however the
> > method used causes the high 64b to be corrupted for certain
> > inputs. here we fix the computation.
> >
> >
> > Diffs
> > -
> >
> >   src/arch/x86/isa/microops/regop.isa
> ed89cb178ecd7586296d2a2e83595174474db554
> >
> > Diff: http://reviews.gem5.org/r/3800/diff/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > Tony Gutierrez
> >
> >
>
> ___
> 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] Review Request 3800: x86: fix Mul1u instruction

[Jason Lowe-Power]

Something that's really easy to test is printf("%lu\n", (unsigned long)-1);
This is what I ran into today.

This gives an unmapped memory error because of an incorrect multiply (which
is how itoa is implemented). This example works with the patch provided.

I think you could come up with many other examples. I think it's the
upper-order bit calculation that's wrong. So unsigned multiplies near 2^64
give wrong answers. Other examples are hard to write since printf causes a
crash.

Jason

On Mon, May 15, 2017 at 4:38 PM Gabe Black  wrote:

> I'm a bit suspicious of this new version and how it has fixed width masks
> and extra terms in the addition at the end. Could you please give me an
> example of where the original code got the wrong answer?
>
> Gabe
>
> On Mon, May 15, 2017 at 1:09 PM, Jason Lowe-Power 
> wrote:
>
>> We should definitely look into the statetrace tool. I'll put it on my
>> giant gem5 list of things to do.
>>
>> Those of you in industry: There must be some test harnesses for hardware
>> and internal simulators. How do you test to make sure instructions are
>> implemented correctly?
>>
>> We've thought about using llvm or gcc tests, but they don't really test
>> what we need, IIRC.
>>
>> Maybe this would be a good summer project for an intern: hint, hint.
>>
>> Jason
>>
>> On Mon, May 15, 2017 at 3:04 PM Gross, Joe  wrote:
>>
>>> Probably we all agree that x86 could use some automated error checking,
>>> but I’m not sure of any way to do this without a ton of work. CheckerCPU
>>> seemed good, but as Gabe points out, this may not be comparing against the
>>> host hardware.
>>>
>>>
>>>
>>> Jason, do you know any way that’s partially or mostly implemented that
>>> we could reuse?
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> *From:* Jason Lowe-Power [mailto:ja...@lowepower.com]
>>> *Sent:* Monday, May 15, 2017 2:54 PM
>>> *To:* Gabe Black ; gem5 Developer List <
>>> gem5-dev@gem5.org>
>>> *Cc:* Gutierrez, Anthony ; Gross, Joe <
>>> joseph.gr...@amd.com>
>>> *Subject:* Re: [gem5-dev] Review Request 3800: x86: fix Mul1u
>>> instruction
>>>
>>>
>>>
>>> Gabe: Do you want me to wait to push this patch? We can have Tony
>>> re-post to gerrit if you want to review it. That would be way easier for me
>>> anyway.
>>>
>>>
>>>
>>> We need a way to test for these kinds of errors. It's quite upsetting
>>> that we've had this error in multiply for so long.
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> On Mon, May 15, 2017 at 2:50 PM Gabe Black  wrote:
>>>
>>> Please give me a chance to look at it. I think the checker CPU is for
>>> comparing, say, the O3 CPU against what's effectively the simple CPU. If an
>>> instruction doesn't do the right thing, it will do the wrong thing no
>>> matter which CPU is executing it. You can compare against actual execution
>>> on a real CPU using the statetrace tool, although I saw that somebody
>>> rearranged all the process startup code which I'd originally carefully
>>> matched against actual Linux process startup, so that tool probably doesn't
>>> give any useful information any more.
>>>
>>>
>>>
>>> Gabe
>>>
>>>
>>>
>>> On Mon, May 15, 2017 at 12:45 PM, Joe Gross 
>>> wrote:
>>>
>>>
>>>
>>> > On Feb. 4, 2017, 10:21 a.m., Jason Lowe-Power wrote:
>>> > > Lol, that code is hard to understand. But, LGTM.
>>> > >
>>> > > What are you using to test this? Any chance you can commit the test
>>> so we don't accidentally break this again in the future?
>>> >
>>> > Tony Gutierrez wrote:
>>> > This bug was manifesting in the ROCr runtime while it is loading
>>> libraries, it manifested as a segfualt (unmapped addr panic) because an
>>> address calculation was corrupted due to this instruction. I manually
>>> tested this instruction by comparing its output to the result of 64b
>>> multiplication using __uint128_t. This is a perfect example of where
>>> instruction tests would be useful. It only seemed to give bad output with
>>> certain inputs, which gave the error the appearance of being
>>> non-deterministic.
>>> >
>

Re: [gem5-dev] Reviving EtherTap

[Jason Lowe-Power]

Hi Gabe,

I also did some work trying to revive ethertap recently. I think it would
be *really cool* to get gem5 to be able to easily talk to the outside
world. I think that it is worth it for this to only work on one platform.
If someone else comes along and wants to extend it to other, they can do
that then.

Overall, I came to similar conclusions as you did. Piping everything
through socat is at least mildly broken, and it makes more sense go
straight through the tap/tun device.

My initial thought was to copy the way qemu sets up a network bridge. But I
never really dug into it enough to fully understand how the qemu code works.

Below are the notes that I took while I was trying to get it to work
(mostly just a knowledge dump so you may or may not be able to get anything
new out of it). The code I have is based on the old mercurial repo, so it
will take me a little time to clean it up so it applies cleanly and works
with the current mainline. I'll try to do that this weekend.

I ended up getting it mostly working, except for the socat issues that you
have run into. If I ran socat in a while loop (shown below) the
gem5->internet connection would eventually get all of the data since the
socat link re-established itself.

Cheers,
Jason


Getting networking going


To do
-
Figure out why it works with fs.py but not with my config files. Ugh!


Disk changes

To get things to work in ubuntu, you have to add the device to
/etc/network/interfaces.

To find the device name, run ifconfig -a

.. code-block:: sh

ifconfig -a

.. code-block::

enp0s0Link encap:Ethernet  HWaddr 00:90:00:00:00:01
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:3420 (3.4 KB)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:1760 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1760 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:130240 (130.2 KB)  TX bytes:130240 (130.2 KB)

Mine was "enp0s0".

Update /etc/network/interfaces with the right device name:

.. code-block::

auto enp0s0
iface enp0s0 inet dhcp


On the host to enable a bridge
--
Create a bridge. This is the script I used.
Saved the script as qemu-ifup, and I ran "sudo ./qemu-ifup".

.. code-block:: sh

#!/bin/sh
#
# Copyright IBM, Corp. 2010
#
# Authors:
#  Anthony Liguori 
#
# This work is licensed under the terms of the GNU GPL, version 2.  See
# the COPYING file in the top-level directory.

# Set to the name of your bridge
BRIDGE=br0

# Network information
NETWORK=192.168.53.0
NETMASK=255.255.255.0
GATEWAY=192.168.53.1
DHCPRANGE=192.168.53.2,192.168.53.254

# Optionally parameters to enable PXE support
TFTPROOT=
BOOTP=

do_brctl() {
brctl "$@"
}

do_ifconfig() {
ifconfig "$@"
}

do_dd() {
dd "$@"
}

do_iptables_restore() {
iptables-restore "$@"
}

do_dnsmasq() {
dnsmasq "$@"
}

check_bridge() {
if do_brctl show | grep "^$1" > /dev/null 2> /dev/null; then
return 1
else
return 0
fi
}

create_bridge() {
do_brctl addbr "$1"
do_brctl stp "$1" off
do_brctl setfd "$1" 0
do_ifconfig "$1" "$GATEWAY" netmask "$NETMASK" up
}

enable_ip_forward() {
echo 1 | do_dd of=/proc/sys/net/ipv4/ip_forward > /dev/null
}

add_filter_rules() {
do_iptables_restore < wrote:

> One other possible use for the bridge might be to adapt a non-ethernet
> network in gem5 to the ethernet network tap expects? I suppose it could do
> other forms of translation too, as necessary.
>
> Gabe
>
> On Wed, May 31, 2017 at 8:44 PM, Gabe Black  wrote:
>
> > Hello folks, I think specifically Nate. I have a need to get EtherTap
> > working again, and after a lot of digging around and looking at this
> > conversation from 5 years ago:
> >
> > http://thread.gmane.org/gmane.comp.emulators.m5.devel/14675
> >
> > I've made some progress understanding how to do that. I think one of the
> > big remaining questions I have is why there was an extra program which
> > opened the tap device and sent the packets to gem5 over a TCP socket
> > instead of gem5 just opening the tap device itself and doing the reading
> on
> > its own. That would certainly be simpler, at least as far as I can tell
> > with admittedly not a great deal of expertise to work with.
> >
> > There are a couple potential reasons I could think of. First, it could
> > have been a permissions thing. It 

Re: [gem5-dev] Restructuring Wiki wrt. Citation Credit

[Jason Lowe-Power]

I think it's a great idea. You can also add the same info to the readme. I
think the main page of the wiki may be locked down, so we might have to
figure out who has the key.

Jason

On Thu, Jun 8, 2017, 6:38 PM Matthias Jung  wrote:

> Hey,
>
> I want to ask: why not restructuring the main page and the publication
> page a little wrt. citation credits ?
>
> http://gem5.org/Main_Page
> http://gem5.org/Publications
>
> Hi have observed that, for example, people are using gem5 to wok on a
> memory specific topic and cite only the original gem5 paper and do not add
> the relevant citations to the DRAM controller paper or DRAMPower etc.
>
> What I suppose is to restructure the paper page according to specific
> features, e.g. DRAM, KVM, GPU … and write a sentence that people should
> cite the original gem5 paper and additionally the listed papers when they
> used specific features: If you use X, please cite Y etc.
>
> Of course this will not guarantee that people do it right in the future,
> but at least it will help or make them aware of it.
>
> What do you think? If you guys agree I would start to update the pages.
> Regards
> Matthias
> ___
> 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] potential better config paradigm

[Jason Lowe-Power]

Hi Gabe,

I agree with your overall problem "like X except". Why wouldn't subclassing
and overriding certain components solve this use case, though? In my
opinion, I would like to just write a new script from scratch, subclass
"DefaultX86System" or something like that. Then, if I want to use different
caches, just import MyCaches that has an L1/L2. If I want to make a new
cache topology, I would override "createCaches", etc.

For running, there should be some simple functions that execute the
simulation. If I want to do something more complex, say sampling, I could
override those functions or somehow provide my own.

That's been my vision for a while. I've developed a set of scripts that
does this for my x86 system I've  been using, but they aren't easily
generalizable. Which is some of the problem with this.

Another thing David Wood and I have been thinking about is providing a set
of "known good" configurations with gem5. Provide a "Skylake-like" or an
"atom-like" or a "ARM-like" configuration. I think this already
exists for ARM, BTW. These kinds of systems would then be a good starting
point for "like X except...". Of course, building these configurations and
testing them against real hardware is a huge undertaking, so we haven't
done anything other than talk about it.

Cheers,
Jason

On Wed, Jun 7, 2017 at 8:52 PM Gabe Black  wrote:

> Hey folks. This isn't a completely formed idea yet, but I was thinking
> about how to improve the config situation and wanted to throw an idea I had
> out there.
>
> It seems to me that a lot of things people want to set up are "like X
> except" where they take, for instance, an x86 PC like setup, or something
> like some android phone, or etc., etc., and then want to tweak it some way
> to use a different CPU, or to use a different disk layout, or whatever.
> Currently, there are three ways to do that.
>
> 1. Copy the whole config and modify the copy. This is impractical since
> there are a lot of dependencies that would need to be copied too.
> 2. Modify the config in place, likely with a new option in front of it to
> preserve existing behavior. This isn't great because the complexity
> accumulates, probably non-linearly, and we end up somewhere like where we
> are today.
> 3. Copy fs.py (or equivalent), do the standard stuff with the standard
> helper functions, and then go back and patch up the config to be what you
> actually wanted. This is a bit fragile and not very user friendly.
>
> None of these options are great, and I was thinking if there was a way to
> avoid them. What if we had a sort of environment or namespace or the like
> where you could set properties, and then various canned objects were
> constructed in the context of that environment? For instance, what if there
> was an ambient setting which said CPU == SimpleAtomicCPU, and then the
> thing putting the system together would just dereference "CPU" when it
> wanted to add a CPU? I don't know how far this could be extended, but
> perhaps we could have lists of peripherals we wanted, like sets of disks or
> network devices or... and?
>
> With a mechanism like that, you could tweak the context things were built
> in to get your special adjustment in there, there could still be generic
> constructs so you wouldn't have to build everything from scratch, and you
> could even potentially fold together more than one of those contexts to
> have, say, one that added in KVM CPUs and one that added in bridging the
> network to the real world, all without having to have a cross product of
> configs or some elaborate series of scripts to run.
>
> Anyway, like I said, not fully thought out, but I wanted to mention it
> before I forgot about it.
>
> Gabe
> ___
> 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] update ARM Full-System Files (aarch-system-2014-10.tar.xz)

[Jason Lowe-Power]

Uploaded!

You can find the new version at
http://www.gem5.org/dist/current/arm/aarch-system-20170616.tar.xz.

Jason

On Fri, Jun 16, 2017 at 9:28 AM Nikos Nikoleris 
wrote:

> Hi Pau,
>
> Thanks for updating this. Can we also add it in the Downloads section
> on the wiki? Is Jason the person with the access rights for this?
>
> Thanks,
>
> Nikos
>
> On 16 June 2017 at 12:27, Pau Cabre  wrote:
> > Hi Nikos,
> >
> > Thanks for finding this out. I guess that my tests did not fail because
> there still was the old m5 in /sbin.
> > I have merged your pull request and generated a new release. You can
> find the files here:
> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/releases/download/20170616/aarch-system-20170616.tar.xz
> >
> > Thanks again,
> > Pau
> >
> > -Original Message-
> > From: Nikos Nikoleris [mailto:nikos.nikole...@gmail.com]
> > Sent: Thursday, June 15, 2017 14:19
> > To: gem5 Developer List 
> > Subject: Re: [gem5-dev] update ARM Full-System Files
> (aarch-system-2014-10.tar.xz)
> >
> > Hi Pau,
> >
> > Thanks again for providing the scripts and the binaries for the new ARM
> system files.
> >
> > I was trying them today and it seems that for the 32bit ARM (aarch32)
> system files, the m5 util is copied to /sbin/m5.aarch32 rather than
> /sbin/m5. This will likely break bootscripts that expect the m5 utility to
> be at /sbin/m5. Is this intentional? It seems that for the 64bit version
> the docker script does the right thing.
> >
> > Thanks,
> >
> > Nikos
> >
> > On 3 May 2017 at 17:29, Jason Lowe-Power  wrote:
> >> The file is uploaded to the same place as the previous one.
> >>
> >> Cheers,
> >> Jason
> >>
> >> On Wed, May 3, 2017 at 10:55 AM Pau Cabre 
> wrote:
> >>
> >>> Hi Jason/Andreas,
> >>>
> >>> Thank you very much for the upload.
> >>> Could you also upload the newer release which uses kernel 4.4 instead
> >>> of
> >>> 4.3 for the VExpress_GEM5_V1 platforms?
> >>>
> >>> https://github.com/metempsy/gem5_arm_fullsystem_files_generator/relea
> >>> ses/download/20170426/aarch-system-20170426.tar.xz
> >>>
> >>> Now we need to think about how to make the transition from the old
> >>> files to the new ones. I am relatively new to gem5 and I do not know
> >>> how this has been done before, but I would say that it is worth
> >>> considering something like what I did in
> >>> https://gem5-review.googlesource.com/c/2841/
> >>> Any other idea?
> >>>
> >>> Regarding updating the links in the gem5 wiki, I do not have
> >>> permissions for editing http://gem5.org/Download nor for creating new
> >>> pages, so somebody else will have to do it.
> >>>
> >>> Thanks again,
> >>> Pau
> >>>
> >>>
> >>> -Original Message-
> >>> From: Jason Lowe-Power [mailto:ja...@lowepower.com]
> >>> Sent: lunes, 1 de mayo de 2017 16:36
> >>> To: gem5 Developer List 
> >>> Subject: Re: [gem5-dev] update ARM Full-System Files
> >>> (aarch-system-2014-10.tar.xz)
> >>>
> >>> Hi Pau and Andreas,
> >>>
> >>> I've uploaded the file to the server. You can add a link on the wiki
> >>> page to
> >>> http://www.gem5.org/dist/current/arm/aarch-system-20170421.tar.xz.
> >>> Let me know if you need me to move it somewhere else or if you need
> anything else uploaded.
> >>>
> >>> Cheers,
> >>> Jason
> >>>
> >>> On Fri, Apr 28, 2017 at 11:51 AM Andreas Sandberg <
> >>> andreas.sandb...@arm.com>
> >>> wrote:
> >>>
> >>> > Hi Pau,
> >>> >
> >>> > It seems like this is a bit more complicated than I anticipated.
> >>> > The dist files are too big to be handled by the wiki, so they are
> >>> > apparently stored as static files in the file system on the web
> >>> > server. I'll have to make some enquiries and get back to you.
> >>> >
> >>> > I think putting the script in util would make a lot of sense.
> >>> >
> >>> > Cheers,
> >>> > Andreas
> >>> >
> >>> >
> >>> > On 28/04/2017 14:08, Pau Cabre wrote:
> >>> > > Hi Andreas,
> >>> > >
> 

Re: [gem5-dev] Vector registers patch series

[Jason Lowe-Power]

Sounds good. I'm not very familiar with that code, so I'll defer to others'
judgement.

It would be nice if we had some tests that exercised this code. Especially
for non-ARM ISAs (mostly I'm talking about x86). Have you done any tests,
or can you think of something simple that I could use to test this out? I
(well, Sean, who's working with us this summer) have some time to do
testing, if there's something easy for us to do.

Thanks,
Jason

On Fri, Jun 16, 2017 at 11:48 AM Curtis Dunham 
wrote:

> Hello gem5 community,
> Just a gentle reminder on this patch series - it's been more two months
> and no activity.   We will be pushing these soon.
>
>
> Thanks,
> Curtis
>
> From: Curtis Dunham
> Sent: Friday, April 21, 2017 12:28 PM
> To: gem5-dev@gem5.org
> Subject: Vector registers patch series
>
>
> Hello all,
>
> We have a very nice $SUBJECT posted on Gerrit (for over 2 weeks now):
>
>
>
> https://gem5-review.googlesource.com/c/2700/
>
> https://gem5-review.googlesource.com/c/2701/
> https://gem5-review.googlesource.com/c/2702/
> https://gem5-review.googlesource.com/c/2703/
> https://gem5-review.googlesource.com/c/2704/
> https://gem5-review.googlesource.com/c/2705/
> https://gem5-review.googlesource.com/c/2706/
>
>
>
> These are very mature and were posted on the old ReviewBoard too, where
> some reached Ship-It status.  I have tagged reviewers who had reviewed it
> before to get a fresh "reviewed-by" tag in Gerrit.
>
>
>
> Please have a look!  We are keen to move these changes into mainline as
> soon as possible.
>
>
>
> Thanks,
>
> Curtis
>
> 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] EventWrapper patch series

[Jason Lowe-Power]

Hi all,

Sean posted a series of patches on Gerrit before the weekend that removed
most of the subclasses of Event and replaced them with
EventFunctionWrapper. These patches removed a significant amount of
boilerplate code! Most of the Event subclasses only subclassed event so
they could capture *this*. Overall, these patches shouldn't have any
functional changes. However, the current regression tests don't necessarily
exercise all of the changes. We'd appreciate it if others would quickly
look over the patches in code they're knowledgeable on to make sure we
didn't make any silly mistakes.

The patches are currently broken up into separate commits for
(semi-)related modules. However, if people prefer, we can squash all of
this into a single commit after review.

Thanks!
Jason & Sean

https://gem5-review.googlesource.com/q/topic:%22event-refactor%22+(status:open%20OR%20status:merged)









ruby: Refactor some Event
subclasses to lambdas 
arm: Refactor some Event subclasses to lambdas

dev: Refactor some Event subclasses to lambdas

net: Refactor some Event subclasses to lambdas

testers: Refactor some Event subclasses to lambdas

cpu/minor: Remove extraneous access specifiers

kvm, mem: Refactor some Event subclasses into lambdas

cpu: Refactor some Event subclasses to lambdas

gpu-compute: Refactor some Event subclasses to lambdas

sim, gdb: Refactor some Event subclasses into lambdas

mips, x86: Refactor some Event subclasses into lambdas









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

Re: [gem5-dev] Python Execution Error

[Jason Lowe-Power]

After digging into this way too much the issue isn't really with PyBind11,
but with Python 2.x and the way Simulation.run() works.

If you don't use Simulation.run() things work just fine. For instance,
running the following gives an exit code of 0:
> build/X86/gem5.opt configs/learning_gem5/part1/simple.py

The problem is Simulation.run() calls sys.exit(exit_event.getCode()). It
turns out that getCode() returns a long, not an int. From the Python
documentation: https://docs.python.org/2/library/sys.html#sys.exit, "If
another type of object is passed, None is equivalent to passing zero, and
any other object is printed to stderr and results in an exit code of 1. In
particular, sys.exit("some error message") is a quick way to exit a program
when an error occurs."

This is a known "issue" in PyBind11 that all ints are returned as longs:
https://github.com/pybind/pybind11/issues/432. Plus, Python fixed all of
these issues in Python 3.0+ by not having both int and long types.

The easiest solution is to make a one line change in Simulation.py:
-sys.exit(exit_event.getCode())
+sys.exit(int(exit_event.getCode()))

Another solution is to not rely on the event's exit code for Python's exit
code. Honestly I don't think it makes much sense to return the exit code of
the guest application as the exit code of gem5. gem5 exits "correctly"
whether or not the guest application has a return code of 0. I would argue
for making the following change:
-sys.exit(exit_event.getCode())
+print "Guest application exit code:", exit_event.getCode()

Additionally, I don't think it makes sense for Simulation.run() to call
sys.exit! What if you wanted to do more processing after calling
Simulation.run()?

Joe and Brad: If this is causing issues for your internal regressions, feel
free to post a patch that fixes the issue. I've spent too much of my Sunday
trying to track this down :).

Jason

On Fri, Jul 28, 2017 at 5:00 PM Beckmann, Brad 
wrote:

> Thanks Joe for confirming this is a problem with the public repo.
>
> Andreas S., since you added the PyBind support, can you look into this?
> This seems to be an issue that slipped through the regression tester, but
> obviously we don't want gem5 returning a non-zero error code for successful
> runs.
>
> Thanks,
>
> Brad
>
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gross, Joe
> Sent: Friday, July 28, 2017 2:56 PM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] Python Execution Error
>
> Also, I've tested when running on the public master branch, SHA1=
> dcb9334b94d14ccdc4ce42e1082e53d6d600e570, built for X86.
>
> I tried a small hello world program:
> #include 
>
> int main() {
>
>   std::cerr << "hello world" << std::endl;
>   return 0;
> }
>
>
> /usr/bin/time -v ./build/X86/gem5.opt ./configs/example/se.py -c ./test ...
> Exit status: 1
>
> > echo $?
> 1
>
> So it seems that the public gem5 also is giving an error exit when the
> application seems to work successfully. Maybe this has to do with PyBind11
> and the python library?
>
> Joe
>
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gross, Joe
> Sent: Thursday, July 27, 2017 6:01 PM
> To: gem5 Developer List 
> Subject: [gem5-dev] Python Execution Error
>
> Hello,
>
> We recently updated our internal repo to be based on a recent rev of the
> public gem5 repo which includes PyBind. After this change, amongst others
> from the public repo, I noticed that the simulator was exiting with return
> code 1, although the simulations seem to run and complete.
>
> What I found is that gem5 seems to be calling the python interpreter to
> run python statements, such as "import m5" and they work fine, but when it
> gets to "m5.main()", this fails to execute for some reason and
> PyErr_Print() is called. This also seems to fail and thus the simulator
> exits with error code 1. This happens after the simulation completes and
> the simulated application returns. Below is the stack trace:
>
> #0  __GI__exit (status=status@entry=1) at
> ../sysdeps/unix/sysv/linux/_exit.c:28
> #1  0x766f3a0b in __run_exit_handlers (status=status@entry=1,
> listp=, run_list_atexit=run_list_atexit@entry=true) at
> exit.c:92
> #2  0x766f3a95 in __GI_exit (status=status@entry=1) at exit.c:99
> #3  0x774f08cf in Py_Exit (sts=sts@entry=1) at
> /usr/src/debug/Python-2.7.5/Python/pythonrun.c:1783
> #4  0x774f0a07 in handle_system_exit () at
> /usr/src/debug/Python-2.7.5/Python/pythonrun.c:1155
> #5  0x774f0ccd in handle_system_exit () at
> /usr/src/debug/Python-2.7.5/Python/pythonrun.c:1177
> #6  PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars@entry=1) at
> /usr/src/debug/Python-2.7.5/Python/pythonrun.c:1165
> #7  0x774f0eca in PyErr_Print () at
> /usr/src/debug/Python-2.7.5/Python/pythonrun.c:1068
> #8  0x0141ed9c in m5Main (argc=argc@entry=7, 
> argv=argv@entry=0x7fffb158)
> at build/X86/sim/init.cc:280
> #9  0x

Re: [gem5-dev] Python Execution Error

[Jason Lowe-Power]

I thought of that solution, too, but I wasn't sure how to do it with
PyBind11. I think it is the best solution to the problem. Thanks for coding
it up, Andreas!

The sys.exit(exit_event.getCode()) is wrapped in "if not interactive" so it
doesn't completely break that usage. But it's still ugly and confusing!

Jason

On Mon, Jul 31, 2017 at 5:22 AM Andreas Sandberg 
wrote:

> Hi Guys,
>
> Thanks for the thorough analysis!
>
> I have a patch that fixes the issue by adding an explicit type
> conversion to the wrapper. I'll post the patch as soon as the CI system
> has determined that it is worthy.
>
> However, I agree with Jason, calling sys.exit(exit_event.getCode())
> should be considered an anti-pattern. My main issue with that
> (anti-)pattern is that it breaks gem5's interactive mode (-i).
>
> Cheers,
> Andreas
>
>
> On 30/07/2017 17:57, Jason Lowe-Power wrote:
> > After digging into this way too much the issue isn't really with
> PyBind11,
> > but with Python 2.x and the way Simulation.run() works.
> >
> > If you don't use Simulation.run() things work just fine. For instance,
> > running the following gives an exit code of 0:
> >> build/X86/gem5.opt configs/learning_gem5/part1/simple.py
> > The problem is Simulation.run() calls sys.exit(exit_event.getCode()). It
> > turns out that getCode() returns a long, not an int. From the Python
> > documentation: https://docs.python.org/2/library/sys.html#sys.exit, "If
> > another type of object is passed, None is equivalent to passing zero, and
> > any other object is printed to stderr and results in an exit code of 1.
> In
> > particular, sys.exit("some error message") is a quick way to exit a
> program
> > when an error occurs."
> >
> > This is a known "issue" in PyBind11 that all ints are returned as longs:
> > https://github.com/pybind/pybind11/issues/432. Plus, Python fixed all of
> > these issues in Python 3.0+ by not having both int and long types.
> >
> > The easiest solution is to make a one line change in Simulation.py:
> > -sys.exit(exit_event.getCode())
> > +sys.exit(int(exit_event.getCode()))
> >
> > Another solution is to not rely on the event's exit code for Python's
> exit
> > code. Honestly I don't think it makes much sense to return the exit code
> of
> > the guest application as the exit code of gem5. gem5 exits "correctly"
> > whether or not the guest application has a return code of 0. I would
> argue
> > for making the following change:
> > -sys.exit(exit_event.getCode())
> > +print "Guest application exit code:", exit_event.getCode()
> >
> > Additionally, I don't think it makes sense for Simulation.run() to call
> > sys.exit! What if you wanted to do more processing after calling
> > Simulation.run()?
> >
> > Joe and Brad: If this is causing issues for your internal regressions,
> feel
> > free to post a patch that fixes the issue. I've spent too much of my
> Sunday
> > trying to track this down :).
> >
> > Jason
> >
> > On Fri, Jul 28, 2017 at 5:00 PM Beckmann, Brad 
> > wrote:
> >
> >> Thanks Joe for confirming this is a problem with the public repo.
> >>
> >> Andreas S., since you added the PyBind support, can you look into this?
> >> This seems to be an issue that slipped through the regression tester,
> but
> >> obviously we don't want gem5 returning a non-zero error code for
> successful
> >> runs.
> >>
> >> Thanks,
> >>
> >> Brad
> >>
> >>
> >> -Original Message-
> >> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gross,
> Joe
> >> Sent: Friday, July 28, 2017 2:56 PM
> >> To: gem5 Developer List 
> >> Subject: Re: [gem5-dev] Python Execution Error
> >>
> >> Also, I've tested when running on the public master branch, SHA1=
> >> dcb9334b94d14ccdc4ce42e1082e53d6d600e570, built for X86.
> >>
> >> I tried a small hello world program:
> >> #include 
> >>
> >> int main() {
> >>
> >>std::cerr << "hello world" << std::endl;
> >>return 0;
> >> }
> >>
> >>
> >> /usr/bin/time -v ./build/X86/gem5.opt ./configs/example/se.py -c ./test
> ...
> >> Exit status: 1
> >>
> >>> echo $?
> >> 1
> >>
> >> So it seems that the public gem5 also is giving an error exit when the
> >> 

Re: [gem5-dev] weird argument-less format string in Simulation.py

[Jason Lowe-Power]

Hi Gabe,

It's not a bug. curTick() gets magically inserted when serializeAll() is
called. I'd be OK if you wanted to pull this out into Python instead of
hiding it in the C++ implementation. There are a couple of other things
that do this, I think. fork() is one example, but it does the string
replace in Python.

https://gem5.googlesource.com/public/gem5/+/master/src/sim/serialize.cc#667.

Jason

On Fri, Aug 4, 2017 at 7:04 PM Gabe Black  wrote:

> Hi folks. I'm doing some work on our internal config scripts, and I notice
> in Simulation.py in scriptCheckpoints, there are some format strings
> ("cpt.%d" specifically) which don't have any arguments. I *think* this code
> is being called, and I also think that somehow %d is being substituted with
> curTick, but I don't see where that's done and this looks like a bug. Does
> anybody know of any magical something or another which is doing the
> substitution? Or maybe I'm not actually running that code and have traced
> the calls incorrectly?
>
> Gabe
> ___
> 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] New testing infrastructure

[Jason Lowe-Power]

Hi Gabe,

Thanks for the feedback, and we look forward to hearing your thoughts on
the code.

Two replies to your comment:
1. I would argue that our current infrastructure isn't much better than
nothing. It sounds like internally at ARM and AMD (maybe other companies?),
they have a customized version that tests what is important to them.
However, for all of us not at a company, it's *very* hard to run the tests.
So hard, in fact, that I personally never run them, and I have 7 years of
gem5 experience! I've talked to a lot of gem5 users, and as it stands very
few feel comfortable executing and understanding the output of the current
framework.

2. The above doesn't really matter. It was just a rant :). We plan on
porting over most of the current tests before pushing the new framework.
Once we feel comfortable that the community is accepting of the new
framework, we'll start working on porting more tests.

We were thinking of keeping most of the tests that execute unique things.
Importantly, we were going to drop all SPEC tests. Hopefully we will have a
replacement for them, but probably not in the very short term. The only
time SPEC tests were run was on zizzer, so it was very difficult for our
users to get feedback about how their change affected those tests.

It would be great if we had more tests like insttest for RISC-V that
actually tests the functionality of specific simulator components. We are
also hoping the increased flexibility of the new infrastructure will
encourage the creation of unittests and other tests that are not full
integration tests.

Cheers,
Jason

On Fri, Aug 4, 2017 at 7:20 PM Gabe Black  wrote:

> I haven't had a chance to look at any of the documentation you referenced
> and am generally in favor of improvements to our testing setup, but it
> might be a bit premature to delete the old system if the new one is still a
> work in progress. That would take us from a not that great testing system
> to essentially not having one...
>
> Gabe
>
> On Fri, Aug 4, 2017 at 2:31 PM, Sean Wilson  wrote:
>
> > Hi all,
> >
> > I’ve just pushed a patchset which removes the current testing
> > implementation and replaces it with a work in progress test framework.
> This
> > framework is meant to be a strong starting point for a new testing
> > infrastructure which would allow for more test coverage and an
> > easier/better user experience. The new framework is completely functional
> > as it stands, but I am open to suggestions, criticism and change requests
> > that might improve it further.
> >
> >
> > Just to briefly motivate this patch, there are quite a few reasons I
> > believe the current testing framework is not suitable and is worth
> > completely replacing. The main reason is that there are too many
> different
> > ways to access the testing system, each of which is documented
> separately.
> > The biggest cause of this is the reliance on SCons to enumerate and
> provide
> > the dependencies for the tests. This proposed framework removes that
> > dependency and provides its own method for tracking dependencies -
> > fixtures. (These are described in more detail in the documentation.)
> >
> >
> > In addition to the patch directly applied to gem5 found
> > https://gem5-review.googlesource.com/c/4420. You can find the library in
> > its own development branch on github here https://github.com/spwilson2/
> > whimsy. The documentation has already been generated and can be browsed
> > here https://spwilson2.github.io/whimsy/. In case the paragraph above
> > wasn’t enough, the first few sections of the documentation provide some
> > more motivation for this library before introducing the framework in
> full.
> >
> > Finally, I only have a week left that I will have dedicated to
> development
> > on this project, so I appreciate hearing comments sooner rather than
> later!
> >
> > Thanks all!
> >
> >
> > - Sean Wilson
> >
> >
> > ___
> > 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] Failing RISC-V Regressions

[Jason Lowe-Power]

I'm not sure. I can look into it, but I'm not sure when I'll get the
chance. I'll try to do it in the next week or so. If I haven't gotten to it
by 9/11, send me another email reminder ;).

Jason

On Wed, Aug 30, 2017 at 11:24 AM Alec Roelke  wrote:

> Hi Everyone,
>
> I've noticed that all of the RISC-V regression tests have been failing
> every day.  They all pass when I run them on my machine with the latest
> gem5.  Is the machine running the regressions running the correct binaries?
>
> Thanks,
> Alec Roelke
> ___
> 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] Failing RISC-V Regressions

[Jason Lowe-Power]

Hi Alec,

The binaries seem to be up-to-date. They are what is in the gem5 repo as of
Sept. 3. The error is "fatal: readBlob(0x0, ...) failed".

If I run the test without the test script, it works. If I run the test on
my local machine it works. The only thing that's failing is running the
test with the test scripts on zizzer.

Anyone else have an idea?

Jason

On Wed, Aug 30, 2017 at 2:55 PM Jason Lowe-Power 
wrote:

> I'm not sure. I can look into it, but I'm not sure when I'll get the
> chance. I'll try to do it in the next week or so. If I haven't gotten to it
> by 9/11, send me another email reminder ;).
>
> Jason
>
> On Wed, Aug 30, 2017 at 11:24 AM Alec Roelke  wrote:
>
>> Hi Everyone,
>>
>> I've noticed that all of the RISC-V regression tests have been failing
>> every day.  They all pass when I run them on my machine with the latest
>> gem5.  Is the machine running the regressions running the correct
>> binaries?
>>
>> Thanks,
>> Alec Roelke
>> ___
>> 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] Failing RISC-V Regressions

[Jason Lowe-Power]

The strange thing about this error is that it works fine either a) on any
machine but zizzer or b) on zizzer with se.py. I don't think the problem is
with the binaries, but that's about as far as I've gotten.

Jason

On Wed, Sep 6, 2017, 9:07 AM Alec Roelke  wrote:

> My understanding was that gem5 uses libelf to read the segments of the
> program, which correctly identifies the program header table, entry point,
> and data, text, and bss segments (among other things).  Are you saying that
> the test scripts cause it to do something different?
>
> On Wed, Sep 6, 2017 at 5:35 AM, Gabe Black  wrote:
>
> > The loader is using the readBlob function of the SE translating port
> proxy
> > which converts a virtual address into a physical one before sending out
> the
> > request. It's being fed the address 0, and that, as you might expect,
> > doesn't map to anything. It gets that address from where the ELF loader
> > tells it the ELF program header table is. The reason it thinks it's at
> > address 0 is that it didn't actually find an address for it, since the
> > program header isn't mapped into the only loadable segment. That segment
> > starts at file offset 0x1000, but the ELF program header starts at offset
> > 64 (maybe in hex?). That's a little unusual because in my experience the
> > linker likes to put the headers in a loadable segment, but that's what's
> on
> > zizzer right now.
> >
> > So basically, I would totally expect it to fail, and I'm surprised that
> it
> > works for you guys at all unless you're using binaries which are
> different
> > and have the headers within the loadable segment. I looked specifically
> at
> > hello world.
> >
> > Gabe
> >
> > On Tue, Sep 5, 2017 at 4:43 PM, Jason Lowe-Power 
> > wrote:
> >
> > > Hi Alec,
> > >
> > > The binaries seem to be up-to-date. They are what is in the gem5 repo
> as
> > of
> > > Sept. 3. The error is "fatal: readBlob(0x0, ...) failed".
> > >
> > > If I run the test without the test script, it works. If I run the test
> on
> > > my local machine it works. The only thing that's failing is running the
> > > test with the test scripts on zizzer.
> > >
> > > Anyone else have an idea?
> > >
> > > Jason
> > >
> > > On Wed, Aug 30, 2017 at 2:55 PM Jason Lowe-Power 
> > > wrote:
> > >
> > > > I'm not sure. I can look into it, but I'm not sure when I'll get the
> > > > chance. I'll try to do it in the next week or so. If I haven't gotten
> > to
> > > it
> > > > by 9/11, send me another email reminder ;).
> > > >
> > > > Jason
> > > >
> > > > On Wed, Aug 30, 2017 at 11:24 AM Alec Roelke 
> > wrote:
> > > >
> > > >> Hi Everyone,
> > > >>
> > > >> I've noticed that all of the RISC-V regression tests have been
> failing
> > > >> every day.  They all pass when I run them on my machine with the
> > latest
> > > >> gem5.  Is the machine running the regressions running the correct
> > > >> binaries?
> > > >>
> > > >> Thanks,
> > > >> Alec Roelke
> > > >> ___
> > > >> 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
> >
> ___
> 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] Minor changes to gerrit review rules

[Jason Lowe-Power]

Hi all,

Currently, if there is a change to a patch on gerrit, all of the previous
tags are cleared. For instance, if you upload a patch and receive a +2
review, then you make a minor update (or any update) the +2 is lost.

I'm proposing changing this rule to only clear Maintainer +1 and keep all
+2's. Thus, for small changes you will no longer need to re-review the
patch.

The only downside to this is if someone makes a major change after you have
given a +2, you will have to notice and remove your +2 if you disagree.
Otherwise, I am hoping this will change will make things a little easier on
reviewers.

Anyone have any objections (or other opinions)?

If I don't hear anything for a week we'll go ahead and make the change.

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

Re: [gem5-dev] Failing RISC-V Regressions

[Jason Lowe-Power]

; table
> > > as
> > > > > it's
> > > > > > > been loaded into memory. If the header table doesn't overlap
> with
> > > any
> > > > > > > segment, it records its address as 0. The RISCV process loader
> > code
> > > > > > > attempts to read out the program header by using that address.
> > > > Because
> > > > > 0
> > > > > > > isn't mapped to anything, it blows up.
> > > > > > >
> > > > > > > $ readelf -l /dist/m5/regression/test-
> > progs/hello/bin/riscv/linux/
> > > > > hello
> > > > > > >
> > > > > > > Elf file type is EXEC (Executable file)
> > > > > > > Entry point 0x1
> > > > > > > There are 1 program headers, starting at offset 64
> > > > > > >
> > > > > > > Program Headers:
> > > > > > >   Type   Offset VirtAddr   PhysAddr
> > > > > > >  FileSizMemSiz  Flags
> > > Align
> > > > > > >   LOAD   0x1000 0x0001
> > > > > 0x0001
> > > > > > >  0x4b80 0x4c10  RWE
> > 1000
> > > > > > >
> > > > > > >  Section to Segment mapping:
> > > > > > >   Segment Sections...
> > > > > > >00 .text .rodata .init_array .fini_array .eh_frame .jcr
> > > .data
> > > > > > .sdata
> > > > > > > .sbss .bss
> > > > > > >
> > > > > > >
> > > > > > > $ md5sum /dist/m5/regression/test-progs/hello/bin/riscv/linux/
> > > hello
> > > > > > > f6a3aabca242749aecb543fe95abfa73
> > > > > > >  /dist/m5/regression/test-progs/hello/bin/riscv/linux/hello
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 6, 2017 at 8:30 AM, Alec Roelke <
> ar...@virginia.edu>
> > > > > wrote:
> > > > > > >
> > > > > > > > My understanding was that gem5 uses libelf to read the
> segments
> > > of
> > > > > the
> > > > > > > > program, which correctly identifies the program header table,
> > > entry
> > > > > > > point,
> > > > > > > > and data, text, and bss segments (among other things).  Are
> you
> > > > > saying
> > > > > > > that
> > > > > > > > the test scripts cause it to do something different?
> > > > > > > >
> > > > > > > > On Wed, Sep 6, 2017 at 5:35 AM, Gabe Black <
> > gabebl...@google.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > The loader is using the readBlob function of the SE
> > translating
> > > > > port
> > > > > > > > proxy
> > > > > > > > > which converts a virtual address into a physical one before
> > > > sending
> > > > > > out
> > > > > > > > the
> > > > > > > > > request. It's being fed the address 0, and that, as you
> might
> > > > > expect,
> > > > > > > > > doesn't map to anything. It gets that address from where
> the
> > > ELF
> > > > > > loader
> > > > > > > > > tells it the ELF program header table is. The reason it
> > thinks
> > > > it's
> > > > > > at
> > > > > > > > > address 0 is that it didn't actually find an address for
> it,
> > > > since
> > > > > > the
> > > > > > > > > program header isn't mapped into the only loadable segment.
> > > That
> > > > > > > segment
> > > > > > > > > starts at file offset 0x1000, but the ELF program header
> > starts
> > > > at
> > > > > > > offset
> > > > > > > > > 64 (maybe in hex?). That's a little unusual because in my
> > > > > experience
> > > > > > > the
> > > > &

Re: [gem5-dev] storing stats in a database?

[Jason Lowe-Power]

Hi Gabe,

There's currently no functionality for that. However, I believe there have
been some efforts in the past to get something like this to work, though
none of them were committed.

I've heard that there may be some people working on better stats support.
So, if you're thinking about improving the stats I would make sure that
there aren't duplicate efforts :). Personally, I would *love* to see
something like database support. Pandas (http://pandas.pydata.org/) would
be even cooler, IMO.

Cheers,
Jason

On Fri, Sep 15, 2017 at 3:42 PM Gabe Black  wrote:

> Hi folks. This may be documented somewhere already, but is there a way to
> collect stats to a database rather than to a text file? That would be
> helpful when collecting stats periodically to get a graph over time, which
> tends to produce a lot of output that needs to be processed before it's
> useful.
>
> Gabe
> ___
> 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] move away from INI files

[Jason Lowe-Power]

Hi Gabe,

Seems OK to me. The code is in the public domain (no explicit copyright)
except where that isn't allowed, in which case it's under MIT. So I think
it's fine to incorporate into gem5. You're planning on using the
amalgamated source (
https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated)? That
seems the most reasonable.

Cheers,
Jason

On Mon, Sep 18, 2017 at 4:26 PM Gabe Black  wrote:

> Hi folks. I know I've proposed a lot of things I haven't sent any patches
> for yet, but here's one more. I recently debugged a problem where some
> names had changed from the system a checkpoint was taken from and the one
> it was loaded into. This left some objects uninitialized, and the
> simulation didn't work. What I'd like to do is print some sort of warning
> if there are unconsumed sections in the checkpoint (I think generally
> checkpoints go from less to more or equal levels of complexity). It looks
> like there's some very vestigial support for this sort of thing in the ini
> parser code, but the only thing that used it was removed from the code base
> sometime back in I think 2006.
>
> While digging around, it occurred to me how fairly crusty the old INI
> support is, and how it would be nice to simplify/streamline the checkpoint
> and config system and move it over to something which is truly hierarchical
> like json. I found that we're already outputting a config.json, so that
> will bring us a lot of the way there all on its own.
>
> One complication with this approach is that C++ doesn't have a built in
> mechanism to parse json files. In some other work we've been doing, this
> library seems to be doing the job pretty well.
>
> https://github.com/open-source-parsers/jsoncpp
>
> Would anybody object strongly if I went made this a dependency and
> retrofitted things which produce/consume INI files to use json files
> instead?
>
> Gabe
> ___
> 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] Failing RISC-V Regressions

[Jason Lowe-Power]

Thanks for pinging me. It's been a busy few weeks. I'll plan on getting to
this today or tomorrow. I'm in the process of getting set up on a new
computer, so I'll work on this whenever it's set up.

Cheers,
Jason

On Wed, Sep 20, 2017 at 8:47 AM Alec Roelke  wrote:

> Hi Jason,
>
> Have you had the chance to push test replacements?
>
> -Alec
>
> On Wed, Sep 13, 2017 at 12:15 PM, Alec Roelke  wrote:
>
> > Thanks for your help on this.  If there's anything I can do to help, let
> > me know.
> >
> > On Wed, Sep 13, 2017 at 4:12 AM, Jason Lowe-Power 
> > wrote:
> >
> >> I'm going to push a replacement for these tests next week. Hopefully
> that
> >> will fix things.
> >>
> >> I'll *try* to test things on zizzer, but it's hard since I wasn't around
> >> when it was set up, and I don't have all of the necessary permissions.
> We
> >> need to move away from zizzer for testing. We're working on it, but it's
> >> slow going.
> >>
> >> Jason
> >>
> >> On Wed, Sep 13, 2017 at 8:58 AM Gabe Black 
> wrote:
> >>
> >> > To follow up, any binaries checked into the gem5 repository are not
> >> used by
> >> > the regressions. The M5_PATH variable isn't set, so it looks for
> >> binaries
> >> > in a default location which is what I have in my earlier email. If you
> >> want
> >> > to change what it's using for hello world, somebody with appropriate
> >> access
> >> > will need to replace that binary on zizzer.
> >> >
> >> > Gabe
> >> >
> >> > On Wed, Sep 6, 2017 at 11:26 AM, Alec Roelke 
> >> wrote:
> >> >
> >> > > Sorry, I meant the hello-world binary, not gem5 itself.  The one
> >> that's
> >> > > included along with the rest of the test binaries is the same as
> what
> >> I
> >> > > have on my system, but different than what the regression server is
> >> > > running.
> >> > >
> >> > > On Wed, Sep 6, 2017 at 2:10 PM, Gabe Black 
> >> wrote:
> >> > >
> >> > > > Nope, and I wasn't aware there was a binary repository either.
> >> > > >
> >> > > > Gabe
> >> > > >
> >> > > > On Sep 6, 2017 11:02 AM, "Alec Roelke" 
> wrote:
> >> > > >
> >> > > > > So the problem must be that the binary is the wrong version.  I
> >> just
> >> > > > cloned
> >> > > > > a new copy of gem5 and the binary is the same as what I had in
> my
> >> > first
> >> > > > > copy.  Are you sure the one on the regression server is
> >> up-to-date?
> >> > > > >
> >> > > > > On Wed, Sep 6, 2017 at 12:41 PM, Gabe Black <
> gabebl...@google.com
> >> >
> >> > > > wrote:
> >> > > > >
> >> > > > > > Note that in your version, there's a segment that starts at
> file
> >> > > offset
> >> > > > > 0,
> >> > > > > > hence including the program header which starts at offset 64.
> >> > > > > >
> >> > > > > > Gabe
> >> > > > > >
> >> > > > > > On Wed, Sep 6, 2017 at 9:30 AM, Alec Roelke <
> ar...@virginia.edu
> >> >
> >> > > > wrote:
> >> > > > > >
> >> > > > > > > When I run readelf on my copy of
> >> > > > > > > tests/test-progs/hello/bin/riscv/linux/hello, this is the
> >> output
> >> > I
> >> > > > > get:
> >> > > > > > >
> >> > > > > > > Elf file type is EXEC (Executable file)
> >> > > > > > > > Entry point 0x102a4
> >> > > > > > > > There are 5 program headers, starting at offset 64
> >> > > > > > > > Program Headers:
> >> > > > > > > >   Type   Offset VirtAddr
> >>  PhysAddr
> >> > > > > > > >  FileSizMemSiz
> >> Flags
> >> > > > Align
> >> > > > > > > >   LOAD   0x 0x0001
> >> > > 

[gem5-dev] ARM hello return code 13?

[Jason Lowe-Power]

Hi all,

I'm working on getting the new testing infrastructure out and ran into an
"interesting" problem. Right now, gem5's return code is the same as the
return code of the application it is executing (in SE mode). Strangely, the
'hello' binary for ARM has a return code of 13. I verified this with a
fresh binary on qemu as well. Any idea why the return code isn't 0?

Also, does anyone have an objection to changing the default behavior to
*print* the return code if it is not 0 and always have gem5 exit with 0
regardless of the return code of the simulated binary?

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

Re: [gem5-dev] ARM hello return code 13?

[Jason Lowe-Power]

Thanks for the feedback! This makes sense.

Cheers,
Jason

On Thu, Sep 21, 2017 at 4:21 PM Boris Shingarov 
wrote:

> Jason,
>
> > does anyone have an objection to changing the default behavior to
> > *print* the return code if it is not 0 and always have gem5 exit
> > with 0 regardless of the return code of the simulated binary?
>
> That would be a very welcome change.
> We have a demo called "Nano" which I stopped showing because having to
> "echo @?" after gem5 exits, confuses people and completely kills the demo's
> effectiveness.  Printing the return code at the end of the guest would be
> very cool.
>
> Boris
>
>
> -"gem5-dev"  wrote: -
> To: gem5 Developer List 
> From: Jason Lowe-Power
> Sent by: "gem5-dev"
> Date: 09/21/2017 06:27PM
> Subject: [gem5-dev] ARM hello return code 13?
>
> Hi all,
>
> I'm working on getting the new testing infrastructure out and ran into an
> "interesting" problem. Right now, gem5's return code is the same as the
> return code of the application it is executing (in SE mode). Strangely, the
> 'hello' binary for ARM has a return code of 13. I verified this with a
> fresh binary on qemu as well. Any idea why the return code isn't 0?
>
> Also, does anyone have an objection to changing the default behavior to
> *print* the return code if it is not 0 and always have gem5 exit with 0
> regardless of the return code of the simulated binary?
>
> Thanks,
> Jason
> ___
> 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

[gem5-dev] Fwd: Sad news about Nate Binkert

[Jason Lowe-Power]

I thought this community might want to hear the news as well.

-- Forwarded message -
From: DAVID A WOOD 
Date: Fri, Sep 22, 2017 at 1:41 PM
Subject: [Multifacet] Sad news about Nate Binkert

Dear all,

It is with a heavy heart that I share the news that my academic grandchild,
Nate Binkert, passed away yesterday while exercising at the gym. Nate was
Steve Reinhardt’s fourth PhD student and a driving force behind the
creation of gem5. Nate's infectious passion about gem5’s potential to
improve the quality of research has impacted almost the entire architecture
community.

They say that you should never outlive your children, and by transitivity,
your grandchildren. And I have to say that losing an academic grandchild
feels about as terrible as I imagine it must feel to lose a biological
grandchild.

Nate was a gifted researcher, a great programmer, and a genuinely nice
person. He leaves behind his wife, Amity, and three young children. He will
be sorely missed.

— david

David A. Wood, Professor
Sheldon B. Lubar Chair in Computer Sciences
Amar and Balinder Sohi Professor in Computer Science
Computer Sciences Department
University of Wisconsin, Madison
da...@cs.wisc.edu
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] How to use ethertap?

[Jason Lowe-Power]

Hi all (and Gabe specifically),

It sounds like you got the ethertap object to work, Gabe. (
https://gem5-review.googlesource.com/c/public/gem5/+/3646/4)

What was necessary to do this? I *think* I have gem5 configured correctly,
and I've created a tun device. However, the next step of somehow connecting
the gem5 tap device to my "real" ethernet device is a mystery to me.

If someone has a set of scripts or maybe just an example of how to get this
feature to work, I'd really appreciate it.

I would like to be able to use gem5 more like qemu. I.e., boot gem5 and
then connect to the outside world to install new packages, etc. Is this
possible with the tun/tap interface?

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

[gem5-dev] Learning gem5 patches to review

[Jason Lowe-Power]

Hi all,

Last week I posted some patches for including the code from Learning gem5
into mainline gem5. These patches add a new source directory
(src/learning_gem5) and add a few new objects. All of this code is
self-contained and doesn't modify any existing gem5 code. I would like to
have this code in mainline gem5 so changes to gem5 can be reflected easily
(instead of me paying attention and keeping the code up to date).

Most of the patches are very small. Over 50% of the lines are comments. The
only patch that may take a little thought to review is the SimpleCache code.

All of the code is for Learning gem5 Part II, which you can find here:
http://learning.gem5.org/book/part2/.

Thanks!
Jason

Patches:
https://gem5-review.googlesource.com/c/public/gem5/+/5020/1
https://gem5-review.googlesource.com/c/public/gem5/+/5021/1
https://gem5-review.googlesource.com/c/public/gem5/+/5022/1
https://gem5-review.googlesource.com/c/public/gem5/+/5023/3
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] How to use ethertap?

[Jason Lowe-Power]

Thanks, Gabe. I think I'm getting closer to getting it to work.

I also needed to run the following:
sudo ifconfig gem5-tap up
sudo ifconfig gem5_bridge up

After that, I can see data arriving on gem5's EtherTap device. However, no
data is arriving on the simulated Linux device. I think it's probably an
issue with my setup (I have a static IP on the host). I'll keep digging and
make sure to writeup a document with how to get this to work when I have it
figured out.

Cheers,
Jason

On Thu, Oct 12, 2017 at 5:11 PM Gabe Black  wrote:

> Hi Jason. To get this to work, you can either use the little utility in
> util/tap which will connect you sort of like wireshark using EtherTapStub,
> or you can use the tup/tap interface directly using EtherTap. I've used the
> later more or less successfully. It will (with default configuration)
> create a tap device on your host called gem5-tap. Then you need to create a
> bridge which will connect that device to a real device so that it can get
> out onto the real network. Something like these commands will probably make
> that happen:
>
> sudo ip link add name gem5_bridge type bridge
> sudo ip link set eth0 master gem5_bridge
> sudo tunctl -u `whoami` -g `whoami` -t gem5-tap
> sudo ip link set gem5-tap master gem5_bridge
>
> You'll want to give up the IP assigned to your eth0, or otherwise things
> get confused and your connection may drop. You should be able to do that
> with these commands, although exactly what's happening is still a little
> mysterious to me. I think the IP address is assumed by the bridge somehow
> maybe?
>
> sudo ifconfig eth0 down
> sudo ifconfig eth0 0.0.0.0 up
>
> You'll probably also want to stop dhcp from running on eth0 so it doesn't
> get a new IP later on.
>
> Also, if you're going to be running multiple simulations bridged to the
> network, you'll want to make sure you set the MAC address of each simulated
> NIC to something unique.
>
> Gabe
>
> On Thu, Oct 12, 2017 at 4:25 PM, Jason Lowe-Power 
> wrote:
>
>> Hi all (and Gabe specifically),
>>
>> It sounds like you got the ethertap object to work, Gabe. (
>> https://gem5-review.googlesource.com/c/public/gem5/+/3646/4)
>>
>> What was necessary to do this? I *think* I have gem5 configured
>> correctly, and I've created a tun device. However, the next step of somehow
>> connecting the gem5 tap device to my "real" ethernet device is a mystery to
>> me.
>>
>> If someone has a set of scripts or maybe just an example of how to get
>> this feature to work, I'd really appreciate it.
>>
>> I would like to be able to use gem5 more like qemu. I.e., boot gem5 and
>> then connect to the outside world to install new packages, etc. Is this
>> possible with the tun/tap interface?
>>
>> Thanks,
>> Jason
>>
>
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Change in public/gem5[master]: util, scripts: helpful scripts, patches and doc.

[Jason Lowe-Power]

Moving this off gerrit so it's publicly visible.

One problem is that the wiki isn't very easy to use. There's a lot of good
documentation there, but it's hard to find and many people miss it. Part of
the problem is probably bad SEO making it hard for Google to return good
results (if only we knew someone on this inside ;)).

How do people feel about the idea of having a new googlesource "project"
titled "gem5 utilities" that contains repos like this one. Then, we can
prominently point to that project. (I think) We could set it up so that
Eder is the maintainer for that project and has control over others
submitting as well.

I wouldn't mind seeing some of the other stuff in util/ moved out of the
main gem5 repo into some other place as well.

Are there other suggestions? We could leverage our github group as well for
this, if we want to split things between googlesource and github.

Jason

On Tue, Oct 17, 2017 at 4:34 PM Gabe Black (Gerrit) <
noreply-gerritcodereview-0odfogtxitwjotgcull...@google.com> wrote:

> Patch Set 1:
>
> Hi Jason,
>
> I think Éder has already a new repository:
> https://github.com/tukl-msd/gem5.TnT
> The question is, if it should be close to the gem5 source or if we keep
> the source clean and create another project here on googlesource or github
> where we could have all the meta-tools centralised...
>
> It's much easier to find the scripts inside gem5's repo.
>
> I like the idea of having meta-tools centralized *outside* of the gem5
> repo. IMO, it's not very easy to find these things in gem5/util because
> there are so many little scripts people have added already.
>
> But, I'm open to whatever the consensus is. If most people think this
> should be in util/ I'm happy to have it there!
>
> I agree with you, Jason. I think it's great to have tools available for
> people who want them to use or reference, but we have to make sure we're
> not creating a situation where there's lots of stuff which is only useful
> to certain people or in certain circumstances which obscures the stuff
> that's useful to everybody right now.
>
> Without digging into this too deeply, it looks like an implementation of a
> particular workflow and tools for particular circumstances which, without
> making any judgement of it's value, is probably specific to its author.
> That also means that there won't be somebody to really review it properly,
> and it will probably stop working without being tested regularly through
> use.
>
> Maybe we should have a page on the wiki or a doc in the tree which has
> URLs of repositories having to do with gem5 out in the world that could be
> useful?
>
> View Change <https://gem5-review.googlesource.com/5101>
>
>
> To view, visit change 5101 <https://gem5-review.googlesource.com/5101>.
> To unsubscribe, or for help writing mail filters, visit settings
> <https://gem5-review.googlesource.com/settings>.
> Gerrit-Project: public/gem5
> Gerrit-Branch: master
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ifb4055bac5427789bcd15f9d57f57955274994d7
> Gerrit-Change-Number: 5101
> Gerrit-PatchSet: 1
> Gerrit-Owner: Éder F. Zulian 
> Gerrit-Reviewer: Andreas Sandberg 
> Gerrit-Reviewer: Anthony Gutierrez 
> Gerrit-Reviewer: Gabe Black 
> Gerrit-Reviewer: Éder F. Zulian 
> Gerrit-CC: Jason Lowe-Power 
> Gerrit-CC: Matthias Jung 
> Gerrit-Comment-Date: Tue, 17 Oct 2017 23:15:24 +
> Gerrit-HasComments: No
> Gerrit-HasLabels: No
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Incorrectly decoded VEX-128 instruction

[Jason Lowe-Power]

Hey Sam,

I've got some bad news... I don't think we've implemented any of the AVX
instructions in gem5. In fact, many of the SSE instructions are still
unimplemented.

Overall, the SIMD support for x86 is pretty awful, as of the last time I
checked (some can correct me if things have changed significantly). It's
much better for ARM. I believe most, if not all, of the NEON instructions
are implemented.

It would be great for someone to tackle the SIMD instructions on x86! In
fact, since the ARM SIMD instructions were implemented there is a new
vector register interface that we should migrate the x86 ISA to use. It's
possible that AMD has some of this code internally that's not pushed out
yet. Brad, Tony, care to comment?

Sorry this isn't better news. This has been a pain point for me for a
while, but I haven't had any time to work on it.

Cheers,
Jason

On Fri, Oct 27, 2017 at 12:38 PM Sam Xi  wrote:

> Hi all,
>
> I ran into a problem today involving an incorrectly decoded AVX
> instruction. Hoping someone can tell me of a workaround or a quick fix
> other than disabling AVX (unless that's the only solution).
>
> Here's a basic testcase.
>
>  int main() {
>   float x;
>   __asm__("vxorps %0, %0, %0" : "=x"(x) : "x"(x) :);
>
>   return x == 0;
> }
>
> Compiled with gcc 5.4:
>   gcc -static -O3 -o test -mavx test.c
>
> Produces the following assembly:
>
> 004005f0 :
>   4005f0: 66 0f ef c9   pxor   xmm1,xmm1
>   4005f4: 31 c0 xoreax,eax
>   4005f6: 66 0f ef c0   pxor   xmm0,xmm0
>   4005fa: ba 00 00 00 00movedx,0x0
>   4005ff: c5 f8 57 c0   vxorps xmm0,xmm0,xmm0
>   400603: 0f 2e c1  ucomiss xmm0,xmm1
>   400606: 0f 9b c0  setnp  al
>   400609: 0f 45 c2  cmovne eax,edx
>   40060c: c3ret
>   40060d: 0f 1f 00  nopDWORD PTR [rax]
>
> gem5 decodes the instruction as XORPS_XMM_M, instead of (something more
> like) VXORPS_XMM_XMM_XMM. This leads to a segfault in the simulated program
> when it attempts to access an unmapped address
>
> Here is the relevant section of the debug trace.
>
> 416293000: system.cpu: Fetch
> 416293000: system.cpu: Translating address 0x4005f0
> 416293000: system.cpu: Sending fetch for addr 0x4005f0(pa: 0x5f0)
> 416293000: system.cpu:  -- pkt addr: 0x5f0
> 416348000: system.cpu.icache_port: Received fetch response 0x5f0
> 416348000: system.cpu: Complete ICache Fetch for addr 0x5f0
> 416348000: global: Getting more bytes.
> 416348000: global: Setting origPC to 0x4005f0
> 416348000: global: Found VEX two-byte prefix 0xc5.
> 416348000: global: Found VEX opcode 0x57.
> 416348000: global: Found modrm byte 0x57.
> 416348000: global: Collecting 1 byte displacement, got 1 bytes.
> 416348000: global: Collected displacement 0xffc9.
> 416348000: global: Calculating the instruction size: basePC: 0x4005f0
> offset: 0x4 origPC: 0x4005f0 size: 4
> 416348000: global: XORPS_XMM_M : ldfp: The address is 0xffca
> 416348000: system.cpu: Fault occured, scheduling fetch event
> panic: Tried to read unmapped address 0xffca.
>
>
> Toolchain information
> =
>
> samxi $ gcc --version
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
>
>
> samxi $ as --version
> GNU assembler (GNU Binutils for Ubuntu) 2.26.1
>
> gem5 revision: e79c4c6f033581f84072ddb45d2ec9543c31af55
>
> Thanks,
> Sam
>
> --
> Thanks,
>
> Sam Xi
> Harvard University
> Computer Science, Ph.D. Candidate
> http://www.samxi.org
> ___
> 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] SPARC cls and statute of limitation on reviews

[Jason Lowe-Power]

Hey Gabe,

I'll *try* to find some time this weekend to skim them. I'll aim for giving
at least +1, after which I'm fine with you taking responsibility for any
bugs and pushing :).

I'll also try to catch up on all of the gem5 things that have been flying
past my inbox. We'll see how that goes, though.

Cheers,
Jason

---
Jason Lowe-Power
Assistant Professor, Computer Science Department
University of California, Davis
3049 Kemper Hall
https://faculty.engineering.ucdavis.edu/lowepower/


On Fri, Nov 17, 2017 at 3:39 PM Gabe Black  wrote:

> Hi folks. I have a series of CLs for the SPARC ISA (
> https://gem5-review.googlesource.com/c/public/gem5/+/5421/2, etc.) which
> haven'b gotten reviews in a while. I realize there may not be anyone to
> jump in and review SPARC changes, and I even chose to tinker with SPARC
> since it's a relatively quite corner where I'm not likely to disrupt
> anybody.
>
> I do, however, want to get those changes checked in at some point. Does
> anyone want to review them? Is there a point where there's been enough time
> for anybody who was sufficiently motivated to look at them, and I can go
> ahead and check them in unreviewed?
>
> Gabe
> ___
> 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] [EXT] Re: testing framework

[Jason Lowe-Power]

I'm all for unit tests. GTest seems fine, but I'm not a huge fan of its
syntax. Although, that shouldn't stop us from having unit tests!!

What's the state of getting whimsy pushed in? From my side, it's ready to
go. The only thing on my to do list that I would have liked to finish up
before pushing is better integration with the current test infrastructure.
It would be good for whoever is running with the old test infrastructure to
be able to run both the old-style and new-style tests with one command.
Unfortunately, I don't have the time to dig into this for the foreseeable
future.

Jason

On Fri, Nov 17, 2017 at 3:19 PM Paul Rosenfeld (prosenfeld) <
prosenf...@micron.com> wrote:

> Even without the complexities of setting up SystemC+gem5 it's pretty
> painful to "unit" test SystemC because the SystemC runtime has a lot of
> global state that comes along with it (for example: you can't "uncall"
> sc_start() to go back and re-do elaboration with different modules). The
> only (not very elegant) workaround we have discussed for unit testing
> SystemC modules is to just to build each set of related SystemC unit tests
> into their own independent GTest binaries.
>
> On the whole, though, GTest is pretty great.
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
> Sent: Friday, November 17, 2017 5:51 PM
> To: Matthias Jung 
> Cc: gem5 Developer List 
> Subject: [EXT] Re: [gem5-dev] testing framework
>
> As far as a high level framework, I think whimsy should help there since
> it's a bit more decoupled and will let you run arbitrary things as tests,
> at least as far as I can tell. Since the systemC integration is just that,
> an integration of two systems, I don't think unit tests would be as
> applicable generally speaking. You could have one for some things though,
> like the ports that translate between gem5's and systemC's memory protocol.
>
> GTest claims to be BSD, so the license should be compatible.
>
> Gabe
>
> On Fri, Nov 17, 2017 at 10:14 AM, Matthias Jung 
> wrote:
>
> > Hey,
> >
> > It would be also nice if we have something that we could also use for
> > test the SystemC stuff. Right now this is not possible with the
> > current framework. Because we have to build gem5 without python as a
> > library for the SystemC stuff... and then build again with linking of
> the gem5 library.
> >
> > Regards
> > Matthias
> >
> > > Am 17.11.2017 um 17:43 schrieb Andreas Sandberg <
> > andreas.sandb...@arm.com>:
> > >
> > > I'm generally in favour of switching to an existing unit test
> framework.
> > > I haven't surveyed the C++ test framework landscape, but judging by
> > > the users (Chromium, LLVM, ...) GTest seems pretty solid.
> > >
> > > As far as I can tell, GTest is all BSD. Is that correct?
> > >
> > > Cheers,
> > > Andreas
> > >
> > >> On 16/11/2017 05:04, Gabe Black wrote:
> > >> Hi folks. How is the test framework integration coming along? Is
> > >> there anything I can do to help?
> > >>
> > >> Also, looking at the whimsy documentation and talking to some other
> > folks
> > >> at Google, it looks like the framework is good at running tests,
> > >> but doesn't itself really implement, for instance, unit tests which
> > >> have
> > their
> > >> own C++ main function, etc.
> > >>
> > >> Does anyone have an opinion about using the google gtest library
> > >> for writing C++ unit tests? I've only worked with it a little bit
> > >> superficially, but so far it seems pretty nice and seems like it
> > >> would
> > fit
> > >> into whimsy fairly well.
> > >>
> > >> Gabe
> > >> ___
> > >> gem5-dev mailing list
> > >> gem5-dev@gem5.org
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >
> > > 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
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] gem5.opt => opt/gem5?

[Jason Lowe-Power]

Hey Gabe,

I don't have any strong feelings on this, just a couple of points.

1) I think we should support "backwards compatibility" if we do this by
having symlinks from the old names to the new names. This way we don't
break all of the scripts people have been using.
2) How much effort is this and would it be better worth your time to
replace SCons with a better build system (e.g., cmake or bazel)?
Additionally, a lot of our build headaches stem from the high level of
coupling between all of the source directories which makes it impossible to
build a subset of gem5 into a library. Would it make sense to tackle this
instead of shoehorning it into SCons?

I don't mean to discourage you from taking our current system and making it
incrementally better!

Cheers,
Jason

On Tue, Nov 21, 2017 at 6:01 AM Andreas Sandberg 
wrote:

> Hi Gabe,
>
> I can definitely see the reasoning behind this. I think revisiting this
> is a good idea. However, I'm a bit reluctant since it affects a lot of
> existing build scripts and test infrastructure.
>
> Another benefit that you didn't mention is that this avoid some annoying
> "issues" when the build system runs tests. We currently run tests using
> the build/ARM/tests/opt/** targets. This would all become consistent
> with the rest of the build system.
>
> Another change we should consider making while we are doing this is to
> swap architecture and optimisation levels. The opt Arm target would then
> become build/opt/ARM/gem5.opt. That would be a lot nicer for code (e.g.,
> libraries) that we share between different targets. Ideally, we should
> only rebuild the src/cpu and src/arch/ directories when switching
> targets, but that's a more ambitious goal.
>
> Cheers,
> Andreas
>
>
> On 21/11/2017 05:28, Gabe Black wrote:
> > Hi folks. I've been digging around in the scons files, and I was thinking
> > about the possibility of treating opt, fast, debug, etc., as actual
> > variants from the scons perspective instead of having them all live in
> the
> > same directory but with different extensions. I think the biggest
> > difference this might make is that, for instance, the opt version of the
> > gem5 X86 binary would be build/X86/opt/gem5 and not build/X86/gem5.opt.
> >
> > There wouldn't be any amazing direct benefit from doing things that way
> > that I can see at the moment, but it would make our build structure fit a
> > little more naturally into the way scons wants to do things. It might
> also
> > make it more feasible to use real scons builders for things like Source,
> > etc., instead of wrapper classes. Another benefit would be if you wanted
> to
> > compile all the files in a particular part of the source tree (like the
> > unit tests, although those shouldn't be lumped together anyway), you
> could
> > just give scons the path and it wouldn't build all possible versions of
> the
> > sources in that directory, just the one in the variant you gave it. Using
> > the unit tests as an example, you could run 'scons
> build/ARM/opt/unittest'
> > and get the opt versions of all the unit tests.
> >
> > Any objections?
> >
> > Gabe
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
>
> 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] Ruby failure

[Jason Lowe-Power]

Hi Giacomo,

How many CPUs/caches/directories are you trying to simulate? This looks
like you might be hitting a limit on the number of simulated components
(controllers/machines).

Another possibility is that somehow the protocol is not constructing a
machine id correctly. Did you make any changes to the protocol?

Cheers,
Jason

On Fri, Sep 21, 2018 at 1:36 PM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi all,
>
> I am debugging a configuration error I get when I try to run ruby with a
> personal platform:
>
> gem5.debug: build/ARM_MOESI/mem/ruby/common/NetDest.cc:41: void
> NetDest::add(MachineID): Assertion `bitIndex(newElement.num) <
> m_bits[vecIndex(newElement)].getSize()' failed.
>
> I don't have any experience on ruby and the code seems a little bit
> cryptic (like the Set class in src/mem/ruby/common/Set.hh, I don't really
> know what it models)
>
> Does anybody know what this means?
>
> Thanks,
>
> Giacomo
> 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] RFC: Command line param overrides

[Jason Lowe-Power]

Hey Andreas,

I also apologize for ignoring this for a while. I need to get back in the
habit of responding to dev list emails and reviews :/...

My personal opinion, and what I've been telling my students, is that when
running research experiments for papers/presentations, there should be at
most 2 command line parameters to your run script: One for the workload to
run and one to specify the configuration under test. Everything else should
be in the python run script or python config scripts (which are two
different scripts, too). However, I understand that when exploring things
before running careful experiments it's useful to have command line
parameters. I (again, personally) think that all of these command line
parameters should be things the user (experimenter) explicitly decides is
important to vary. As such, I've been discouraging everyone from using
scripts like se/fs.py which are the antithesis to this outlook.

That said, I can see how this feature could be useful. And I appreciate how
you've separated structure from parameters. Although, there's cases where
this isn't clear cut. E.g., the branch predictor isn't really structure,
but it's not a simple parameter, either.

I also want to echo Gabe's point on building brittle hierarchies of
scripts. I've seen some gem5 script script scripts that haunt my
nightmares. I think, as a community project we should try to steer our
users towards good development practices. However, we also shouldn't
dictate to them how to use the tool.

In conclusion, I think this idea is a huge improvement over se/fs.py.
However, it does have the chance to be abused, but I don't think it's
necessarily our responsibility to build a tool that is impossible to use
incorrectly. Instead, I think it's our responsibility to document how to
use the tool correctly. I definitely won't block this change going in, but
I might still discourage people from using it ;).

I'll try to set aside some time tomorrow to catch up on these patches and
other patches on gerrit. I'll probably have more specific things to say
after digging into the code.

Cheers,
Jason

On Thu, Oct 4, 2018 at 2:37 PM Gabe Black  wrote:

> Hi, sorry for taking a while to reply to this.
>
> I think this is a good idea if kept small/limited, but has a lot of
> potential for abuse. gem5 seems to oscillate (over long periods of time)
> between command line arguments and languages/files to configure itself.
> People want command line options because they're easy to adjust from the
> command line, but then they're too limited and there are too many of them,
> so then the add a layer of scripts on top of that to set all the options.
> But then they want to be able to adjust what they're scripts do, and so
> they add command line arguments. And then somebody else comes along and
> doesn't want to mess with any of the things that exist, so they add a
> script on top of the arguments on top of the script on top of the arguments
> on top of gem5, perhaps in the form of a Makefile, local bash script, etc.
> The tower gets taller and taller, and more and more fragile, etc.
>
> However, I think this idea has the potential to short circuit that cycle a
> bit by making it possible to have a very simple but very general purpose
> command line argument that lets you make small adjustments to a script
> without having to add a knob for every little thing. If, however, it gets
> to be more and more powerful (filters, wildcards, then small lambdas, etc.)
> it just turns into a tortured little scripting language in and of itself
> which is even worse than just using a real language like python. If you're
> doing something more complicated, you should just bite the bullet and
> modify the underlying script.
>
> So, after some thought, I think this is an idea worth pursuing, and its
> scope should be carefully limited and controlled.
>
> Gabe
>
> On Wed, Sep 26, 2018 at 7:01 AM Andreas Sandberg  >
> wrote:
>
> > Hi Everyone,
> >
> > One of my colleagues just posted a couple of RFC patches [1, 2] that
> > introduce functionality to override SimObject param values from the
> > command line. These patches aim to solve the explosion of command line
> > arguments that tend to build up in example scripts when people want to
> > tune various parameters. I'd like to start a discussion around these
> > features and some feedback from the wider gem5 community.
> >
> > There has been talk about adding this type of functionality, both on
> > the dev list and offline, for quite some time. I am of the opinion that
> > there should be a clear distinction between structural configuration
> > (instantiating objects and wiring ports) and parameter tuning. For that
> > reason, these changes don't provide a mechanism to instantiate new
> > SimObjects. Structural configuration is left to the configuration script.
> >
> > It supports simple statements like "test_sys.cpu[0].socket_id = 2".
> > Unlike "normal" Python statements, you can operate on multiple
> > Si

Re: [gem5-dev] state of systemc

[Jason Lowe-Power]

Hey Gabe,

TBH, I've been ignoring most of the SystemC stuff for a while now... you've
really been doing a lot of work! :). We should be looking into this more
closely soon. I have a student who is going to be trying to use your
SystemC integration this quarter. Some other comments inline below.

Cheers,
Jason

On Tue, Oct 9, 2018 at 3:26 PM Gabe Black  wrote:

> Hi folks! Since the systemc implementation seems to be nearing an
> interesting point, I thought it would be a good idea to let everyone know
> what's going on.
>
> 1. Even though I've been checking in a batch of 40 CLs a week, the list of
> pending CLs still sits at 92. Since the previous CLs haven't been reviewed,
> I'm hoping it will be fine to just wait a week (without annotating all 92
> CLs as such), and then checking them all in to get everything up to date.
>
>
Is there anything of particular interest to look at in these last 92? I
assume not... but if there is, let me know and I can take a look early next
week.


>
> 2. I'm planning to make some examples to show how you can run a systemc
> simulation based on sc_main, or one which has systemc objects instantiated
> by gem5 and built into a gem5 hierarchy. I asked about this in an earlier
> email, but I'm assuming putting these in a new directory called "examples"
> at the top level of the repository is ok. CLs will of course be available
> for review if people want to object and/or suggest alternatives.
>

I saw the other email, and I meant to respond. Maybe util/ would be a good
place to put this, like the current SystemC examples. I don't really like
the idea of a new top-level directory for examples since it doesn't seem
like anything else would go there.

>
>
> 3. The systemc sources have been guarded by a scons variable which means
> that while you all likely have them (as of 92 CLs ago) in your checkouts,
> they aren't currently doing anything. I'm planning to flip that switch to
> be default on in the near future, and then after that removing the switch.
> This is just a heads up.
>

Would it make sense to keep this as an option and *not* enable it by
default? Does SystemC add significant compile time to gem5 and add size to
the binary? I expect SystemC will be used by a small minority of gem5 users.

>
>
> 4. I have an adapted version of Accelera's (the upstream systemc folks)
> package of tests and run script in src/systemc/tests. The script is pretty
> flexible and deserves some documentaiton, but in short if you want to run
> it you can use a command line like this:
>
> src/systemc/tests/verify.py -j 48 build/ARM/ --filter-file
> src/systemc/tests/working.filt


> Of the 853 total tests, some are simply uncompilable, a few are for
> features which are deprecated or highly non-standard which I chose not to
> implement, leaving 818. Exactly which those are and why is described in the
> working.filt file mentioned in the command line above.
>
> Of those 818, 798 are considered passing right now. Of the 20 remaining,
> the majority, 18, are "failing" because my implementation chooses to run
> some processes in one order, while the Accellera implementation chooses a
> different order. Both are within the spec, but since "correctness" is
> determined by matching the output, these tests fail. One of the others is
> because of a corner case in how reset signals work at the very beginning of
> simulation, and the last is because I don't free up dead processes, and one
> of the tests attempts to reuse their names. That works in the Accellera
> implementation, but mine recongizes the conflict and renames the new
> objects per the spec.
>
> I've made considerable effort to match the ordering of the Accellera
> implementation, but these last few are, in my opinion, not worth chasing
> down or contorting the gem5 implementation to match. My thought as of right
> now is to update the reference output so that the tests pass with gem5's
> ordering.
>
> In general it's not great to use the output and arbitrary non-standard
> ordering decisions to determine correctness. There are several places in
> the implementation where I've done things in ways that I know are
> inefficient, but which match Accellera. I would like to fix those, but
> doing so would make some of the tests fail. In a perfect world, we would
> have tests which checked only the required behavior and not arbitrary
> undefined decisions the implementation is allowed to make.
>
>
All of this seems reasonable to me. I like the idea of updating the outputs
to match gem5's ordering.

Any chance you can hook this into the new testing infrastructure? (E.g.,
ext/testlib, tests/main.py, and tests/gem5.) Maybe you could add a
tests/systemc/ that looks like tests/gem5/ or just add a directory under
tests/gem5. If you have any questions on how to use the new testing
infrastructure don't hesitate to ask. I really want to migrate everything
over to that.


>
> 5. There is no mechanism yet for connecting models either to gem5 through
> TLM with 

Re: [gem5-dev] state of systemc

[Jason Lowe-Power]

On Wed, Oct 10, 2018 at 5:18 PM Gabe Black  wrote:

> On Wed, Oct 10, 2018 at 4:44 PM Jason Lowe-Power 
> wrote:
>
> > Hey Gabe,
> >
> > TBH, I've been ignoring most of the SystemC stuff for a while now...
> you've
> > really been doing a lot of work! :). We should be looking into this more
> > closely soon. I have a student who is going to be trying to use your
> > SystemC integration this quarter. Some other comments inline below.
> >
> > Cheers,
> > Jason
> >
> > On Tue, Oct 9, 2018 at 3:26 PM Gabe Black  wrote:
> >
> > > Hi folks! Since the systemc implementation seems to be nearing an
> > > interesting point, I thought it would be a good idea to let everyone
> know
> > > what's going on.
> > >
> > > 1. Even though I've been checking in a batch of 40 CLs a week, the list
> > of
> > > pending CLs still sits at 92. Since the previous CLs haven't been
> > reviewed,
> > > I'm hoping it will be fine to just wait a week (without annotating all
> 92
> > > CLs as such), and then checking them all in to get everything up to
> date.
> > >
> > >
> > Is there anything of particular interest to look at in these last 92? I
> > assume not... but if there is, let me know and I can take a look early
> next
> > week.
> >
>
> Nothing any more interesting that what preceded it. The things that might
> come after it (the examples, enabling systemc in normal builds, hooking
> into ports) may be more interesting.
>
>
> >
> >
> > >
> > > 2. I'm planning to make some examples to show how you can run a systemc
> > > simulation based on sc_main, or one which has systemc objects
> > instantiated
> > > by gem5 and built into a gem5 hierarchy. I asked about this in an
> earlier
> > > email, but I'm assuming putting these in a new directory called
> > "examples"
> > > at the top level of the repository is ok. CLs will of course be
> available
> > > for review if people want to object and/or suggest alternatives.
> > >
> >
> > I saw the other email, and I meant to respond. Maybe util/ would be a
> good
> > place to put this, like the current SystemC examples. I don't really like
> > the idea of a new top-level directory for examples since it doesn't seem
> > like anything else would go there.
> >
>
> Sure. util seems like a strange place to look for examples, but if that's
> where some already are that seems reasonable.
>
> Agreed, it is weird. I'd also be ok with a more thorough restructuring and
adding a gem5/examples directory if there was more than just SystemC stuff
there.

>
> >
> > >
> > >
> > > 3. The systemc sources have been guarded by a scons variable which
> means
> > > that while you all likely have them (as of 92 CLs ago) in your
> checkouts,
> > > they aren't currently doing anything. I'm planning to flip that switch
> to
> > > be default on in the near future, and then after that removing the
> > switch.
> > > This is just a heads up.
> > >
> >
> > Would it make sense to keep this as an option and *not* enable it by
> > default? Does SystemC add significant compile time to gem5 and add size
> to
> > the binary? I expect SystemC will be used by a small minority of gem5
> > users.
> >
>
>
> I think it definitely should be enabled by default, since otherwise many
> people won't build it and it will end up broken a lot. The impact on
> compile time isn't significant, particularly if you're doing an incremental
> build. The gem5.opt binary size (using the ARM arch) went from 714MB to
> 741MB, which is a less than 4% increase. I would be curious to see where
> that extra space is going (code, data, etc.) to see if any can be trimmed
> (I used the systemc data types, essentially their STL, as is), but it's not
> a high priority right now.
>
> I can see a case where you might want to be able to turn it off to squeeze
> down gem5's size for some reason, but even then it doesn't make that much
> of a difference. I think getting rid of the knob most people will ignore
> would be a better tradeoff complexity wise.
>
>
> This sounds reasonable to me. I was just a little hesitant to add so much
code by default, but I completely see where you're coming from with it
being broken. I ran into this often with gem5-gpu. We probably should have
pushed to mainline that support earlier.

>
> >
> > >
> > >
> > > 4.

Re: [gem5-dev] Separate automatically generated nightly Cron results and Gerrit patch "Changes in" emails from other dev discussions

[Jason Lowe-Power]

Hi Ciro, Gabe,

Interesting proposal. I also have a number of filters set up. Strangely, I
had to set up filters so that the gerrit emails wouldn't go to spam. You'd
think that Gmail would know that emails from googlesource aren't spam...

I agree with Gabe about turning off the cron emails. Are there any
objections to this? IMO, they're worthless at this point.

I'd like to keep the gerrit email on the main development list, though. I
know it's been heavy lately (blame Gabe ;)), but there's often
conversations on gerrit that everyone on the dev list would like to see.
I'm also worried that if we create a new list for the gerrit emails no one
will ever see new changesets posted to gerrit. What are others' opinions on
this?

Cheers,
Jason

On Fri, Oct 12, 2018 at 4:57 PM Gabe Black  wrote:

> It seems reasonable to send CL related emails to a gem5-review (or similar)
> list. Since the cron messages are basically worthless at this point (the
> tests fail, nobody is likely to fix them, probably nobody reads them) we
> should just turn them off until we have tests in place that produce useful
> results to report. Or minimally switch it over to run, say, the unit tests
> nightly? If we don't turn it off for some reason, I think making a separate
> list for that would also make sense.
>
> Gabe
>
> On Fri, Oct 12, 2018 at 11:22 AM Ciro Santilli 
> wrote:
>
> > I want to watch only discussions and bug reports, without a ton of Cron
> > messages and patches in the middle.
> >
> > I've created a filter now, but it is annoying for new users who likely to
> > want the same thing.
> >
> > Also annoying to browse the archives later.
> >
> > I would rather either:
> >
> > - create a separate list for hand written -dev messages
> > - put all hand written messages in gem5-user and leave -dev only for the
> > automatic ones
> >
> > ___
> > 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] Make the GNU mailman archive visible to non subscribers

[Jason Lowe-Power]

Hi Ciro,

I'm not sure what the original reason for not having the archives public
was. It could be to try to keep the server load down.

We're trying to migrate our infrastructure away from self-hosted things.
One step is to move to some cloud-based mailing list. When we do that, I
think it will take care of this problem. Any good suggestions for
cloud-based mailing lists other than google groups?

Cheers,
Jason

On Fri, Oct 12, 2018 at 10:53 AM Ciro Santilli 
wrote:

> I find it confusing that you sign up for the email at:
> http://www.gem5.org/mailman/listinfo/gem5-dev and that has a link to the
> archives: http://m5sim.org/mailman/private/gem5-dev/ but seeing that link
> requires you to be logged in.
>
>
> Can we make those archives public? This would make it clear which is the
> canonical archive. Now I just randomly choose between GMANE and Mail
> Archive. When GMANE is not down that is.
> ___
> 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] cc registers

[Jason Lowe-Power]

Hey Gabe,

I don't know if this helps, but I remember a lot of problems with register
renaming and CC registers ~6ish years ago. IIRC, there's a separate pool of
physical registers for the CC registers so that they do not limit the
renaming of "normal" registers.

There were probably some discussions on the former reviewboard about this.
But again, it was so long ago that I don't remember the exact context. In
fact, this might not have anything to do with why they are special
registers.

Cheers,
Jason

On Mon, Oct 15, 2018 at 8:57 PM Gabe Black  wrote:

> Hey folks. I think I'm missing some context from when I was away from gem5.
> Does anyone know why there's a separate register file defined explicitly
> for condition code registers? Why is having them as integer registers not
> sufficient?
>
> Also as a general point, it's bad form to have "generic" features like this
> which are hidden behind #ifdefs and #defines and only implemented for one
> or two ISAs. Another example of this is a feature in MIPS which it uses to
> read registers of other threads and which is only available in that ISA. If
> the primitives available for ISAs aren't sufficient lets fix that, not add
> on ISA specific extensions which are unused or incompatible with most of
> the ISAs and hidden behind flags.
>
> Gabe
> ___
> 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] Order of exit callbacks and last stat dump

[Jason Lowe-Power]

Hi Andreas,

Good question. I don't see any reason why we couldn't reverse the order in
simulate.py (
https://gem5.googlesource.com/public/gem5/+/master/src/python/m5/simulate.py#155).
TBH, I'm not sure it's really appropriate to have the stats dump like that
anyway. I'd rather see explicit calls via python to m5.dumpStats().

At the same time, I think the current order should be OK. While the exit
callbacks are meant to clean up some state (e.g., close open files), they
shouldn't delete any objects that might have stats. Unless I'm missing
something.

Cheers,
Jason

On Fri, Oct 12, 2018 at 7:32 AM Andreas Sandberg 
wrote:

> Hi Everyone,
>
> Does anyone know why src/python/m5/simulate.py sets up atexit handlers
> that request a stat dump after calling the exit callbacks in C++?
>
> This seems very strange since I would typically use the exit cleanups to
> perform model-specific cleanup. I wouldn't expect any calls into the
> SimObject after receiving the exit callback.
>
> 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] Unreachable states in the MESI-Three-Level protocol

[Jason Lowe-Power]

Hi Gabriel,

It doesn't surprise me at all that there are unreachable states in the
protocol. Specifically MESI_Three_Level was kind of quickly thrown together
a few years ago to try to have an example three level protocol that looked
something like Intel systems. The L0 cache was bolted on the
MESI_Two_Level.

You have some very good questions that I don't know the answers to! Having
a tool to check for dead transitions in SLICC would be very cool! I'm not
sure how much effort this would take, TBH. At one point, there was some
effort to make it possible to convert SLICC into a model checking language,
but I don't think it was ever finished.

To answer your question about how to know the total number of
transitions... all I can say is that you can't assume all possible
transitions will be exercised through testing. Many protocols have
transitions that happen very rarely with unlikely race conditions. One
example I can think of was this paper from ASPLOS (
http://research.cs.wisc.edu/multifacet/papers/asplos17_crossing_guard.pdf)
which counted the number of transitions possible and that were visited by
the tester. You may be able to reach out the the first author, Lena, to get
more information.

Sorry I can't help more. It sounds like your work has interesting research
potential!

Cheers,
Jason

On Wed, Oct 31, 2018 at 9:50 AM Gabriel Arthur Gerber Andrade <
29.a...@gmail.com> wrote:

> Hello,
>
> I'm part of a research team that works with memory-model verification. We
> use the gem5 to evaluate our techniques. From the results of our most
> recent experiments, a concern arose about the protocol we adopted: the
> *MESI
> Three Level* protocol.
>
> We measured the number of distinct transitions stimulated in the finite
> state machine of each cache controller when running a suite of constrained
> random tests. The results indicated an unexpected saturation around 70% of
> stimulated transitions. We applied two different types of test generator,
> and both were unable to attain a higher percentage.
>
> In order to explain such result, we analyzed each transition not
> stimulated. In doing so, we identified transitions in the SLICC
> implementation of the protocol that seem to be unreachable. Therefore, we
> would like to know if someone in the development team can confirm that some
> transitions are unreachable (or if we are missing something).
>
> As an example, let's take one transition of the first-level cache
> controller (file `src/mem/protocol/MESI_Three_Level-L0cache.sm`). According
> to the finite state machine, the controller should change the state of a
> *Modified *cache block to *Shared *when it receives a forward of a load
> request from the second-level cache (`transition(M, Fwd_GetS, S)` in the
> SLICC code). However, the second-level cache never forwards such request.
> Instead, when the latter receives a `CoherenceRequestType:GETS` from the
> third-level cache (which acts as the Directory), it triggers a
> `L0_Invalidate_Else` event and sends an *invalidation* request to the
> first-level cache. Hence, the previously mentioned transition is
> unreachable and, naturally, was never covered in our experiments.
>
> If we are correct in our analysis, how can we correctly define the total
> amount of transitions in each controller? Is there any kind of automated
> tool to verify unreachable SLICC code?
>
> source code for reference:
> 1. src/mem/protocol/MESI_Three_Level-L0cache.sm
> 2. src/mem/protocol/MESI_Three_Level-L1cache.sm
> 3. src/mem/protocol/MESI_Two_Level-L2cache.sm
>
> Best regards,
> Gabriel Arthur
> ___
> 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] GCC4.X support

[Jason Lowe-Power]

Dropping 4.8/4.9 works for me. Maybe we should also email gem5-users to see
if anyone is using old clusters.

Jason

On Mon, Nov 26, 2018 at 9:34 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi all,
>
>
> There is an ongoing discussion about dropping support for gcc < 5.0.
> (At the moment we support gcc/4.8: http://www.gem5.org/Dependencies<
> http://www.gem5.org/Dependencies)>)
>
> It sparked from the following patch
>
> https://gem5-review.googlesource.com/c/public/gem5/+/14315
>
> which is keeping gem5 gcc4.x compliant. If we decide to drop support, I
> will abandon the patch.
> (ideally when http://www.gem5.org/Dependencies gets updated)
>
> Does anybody have any concern about that?
>
> Thanks
>
> Giacomo
>
>
> 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] Unit test naming convention

[Jason Lowe-Power]

That's fine with me!

+1

On Wed, Nov 28, 2018 at 4:54 PM Gabe Black  wrote:

> Hi folks. We have a few unit tests now, and they are mostly consistently
> named by adding test to the file name. For instance the tests for foo.cc
> would be in footest.cc.
>
> There are two minor downsides to that. First, that's a bit ugly to read,
> and it may look weird if files, for instance, use _ to separate words
> instead of squishing everything together, ie foo_bar.cc -> foo_bartest.cc.
> Second, if there already is a footest.cc which is not for unit tests (not
> super likely, but definitely possible), then the naming gets a little
> ambiguous.
>
> Would it make sense to mark tests with .test, so foo.cc -> foo.test.cc?
> That's clear to read, more universally consistent, easily grepped for, and
> will probably not be ambiguous.
>
> Gabe
> ___
> 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] custom allocator for Request/Packet objects

[Jason Lowe-Power]

Hey Gabe,

Are you thinking that a custom allocator would make a difference in terms
of memory footprint or in terms of performance (or both)?

A couple of thoughts:
- I'm hesitant to put the final keyword on Packet. I think we could see
some code cleanup by making Packet a polymorphic object (e.g., Daniel has
been talking about implementing packets with compressed data). Obviously,
using polymorphism isn't required, and I don't have any plans to make this
change in the near future. But it's something that I've been thinking about.
- I like the idea of requiring the use of a small function to allocate
requests and packets. In many cases, for Packets, we use
Packet::createRead()/createWrite(), which is a step in that direction. I
think this would be a relatively non-controversial change moving in the
direction of custom allocators. It may also allow us to do some testing on
this more easily.

Another argument against custom allocators is that we'll be adding a
significant amount of error-prone code. I like the idea of using standard
libraries as much as possible to aid in understanding the code and reducing
the bug surface.

That said, if we get a 20% speedup or a reduction in memory footprint then
this change would likely be worth it!

Cheers,
Jason

On Wed, Nov 28, 2018 at 7:22 PM Gabe Black  wrote:

> I was just wondering whether it would make sense to have custom allocators
> defined for Request and Packet types which would keep around a pool of them
> rather than defaulting to the normal allocator. I suspect since both types
> of objects are allocated very frequently this could save a lot of heap
> overhead.
>
> I think there are two complications to doing this. First, we'd want to make
> sure Request and Packet objects are truly those objects and are of the
> appropriate size. Subclasses could add new members and make the types
> bigger. I think to ensure that, we'd need to add the "final" keyword (added
> in C++11) to ensure those types can't be subclassed and have unpredictable
> sizes.
>
> Second, we use make_shared a lot to build Requests, and that actually
> allocates a larger amount of memory to hold the object and reference count
> information. It allocates that larger object with new, and it looks like
> you're supposed to use allocate_shared if you want to use a custom
> allocator. Writing a custom allocator looks relatively complicated, but it
> might make a big difference if it works correctly.
>
> Also we'd probably want to put the Request allocator incantation in a small
> function rather than calling make_shared or allocate_shared directly to
> avoid a lot of boilerplate and churn if things need to change.
>
> Thoughts? Like I said I suspect this may make a significant difference, but
> it might not be easy to implement and may not actually make much of a
> difference at all.
>
> Gabe
> ___
> 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] GCC4.X support

[Jason Lowe-Power]

I advocate for explicitly stating that SystemC should be disabled for gcc <
5.0 and making this change in the SConscript with a warning. I don't think
the SystemC support is widely used right now, and few people are stuck on
4.8, so I doubt it will affect anyone. We can even include a link to the
gerrit patch that fixes it in the SCons warning.

Jason

On Thu, Nov 29, 2018 at 5:19 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Chang,
>
>
> I think it makes sense to wait until EOL of Ubuntu 14.04.
>
> We should consider about fixing the bug then, or to explicitly say in
> gem5.org that SYSTEMC has to be disabled in order
>
> to be compliant (which is not the best approach IMO).
>
>
> Gabe, what's your opinion on this? Can you provide a better alternative to
> my patch?
>
> Otherwise, If nobody wants to spend time on this I feel we should go on
> merging the patch with a remainder of reverting it
>
> once we deprecate usage of GCC4.8/9
>
>
> Giacomo
>
> 
> From: gem5-dev  on behalf of Chang Hyun Park <
> heartinpi...@gmail.com>
> Sent: 27 November 2018 02:11:34
> To: gem5 Developer List
> Subject: Re: [gem5-dev] GCC4.X support
>
> Dear Jason and Giacomo,
>
> We are running our simulation clusters on Ubuntu 14.04 (LTS) which will
> expire next April.
> Ubuntu 14.04 ships with GCC 4.8.
>
> If its not too much hassle supporting 4.8, what about dropping support for
> gcc < 5.0 after the EOL of Ubuntu 14.04?
> (So perhaps drop support for gcc < 5.0 beginning May 2019)
>
> Best Regards,
> Chang Hyun Park
>
> > On 27 Nov 2018, at 3:53 AM, Jason Lowe-Power 
> wrote:
> >
> > Dropping 4.8/4.9 works for me. Maybe we should also email gem5-users to
> see
> > if anyone is using old clusters.
> >
> > Jason
> >
> > On Mon, Nov 26, 2018 at 9:34 AM Giacomo Travaglini <
> > giacomo.travagl...@arm.com> wrote:
> >
> >> Hi all,
> >>
> >>
> >> There is an ongoing discussion about dropping support for gcc < 5.0.
> >> (At the moment we support gcc/4.8: http://www.gem5.org/Dependencies<
> >> http://www.gem5.org/Dependencies)>)
> >>
> >> It sparked from the following patch
> >>
> >> https://gem5-review.googlesource.com/c/public/gem5/+/14315
> >>
> >> which is keeping gem5 gcc4.x compliant. If we decide to drop support, I
> >> will abandon the patch.
> >> (ideally when http://www.gem5.org/Dependencies gets updated)
> >>
> >> Does anybody have any concern about that?
> >>
> >> Thanks
> >>
> >> Giacomo
> >>
> >>
> >> 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
> 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] GCC4.X support

[Jason Lowe-Power]

Gabe, can you put a patch together real fast that disables SystemC for gcc
< 5?

If not, I should be able to do it tomorrow.

Jason

On Thu, Nov 29, 2018 at 4:06 PM Gabe Black  wrote:

> I commented on the CL if we decide to check it in. I'm not 100% sure what's
> best, but the more I think about it the more I tend to agree with Jason.
> That would probably be the least invasive thing to do, given its temporary
> nature. It would be a bit awkward and clunky for anybody that hits it, but
> hopefully that set is very small or empty.
>
> Gabe
>
> On Thu, Nov 29, 2018 at 8:52 AM Jason Lowe-Power 
> wrote:
>
> > I advocate for explicitly stating that SystemC should be disabled for
> gcc <
> > 5.0 and making this change in the SConscript with a warning. I don't
> think
> > the SystemC support is widely used right now, and few people are stuck on
> > 4.8, so I doubt it will affect anyone. We can even include a link to the
> > gerrit patch that fixes it in the SCons warning.
> >
> > Jason
> >
> > On Thu, Nov 29, 2018 at 5:19 AM Giacomo Travaglini <
> > giacomo.travagl...@arm.com> wrote:
> >
> > > Hi Chang,
> > >
> > >
> > > I think it makes sense to wait until EOL of Ubuntu 14.04.
> > >
> > > We should consider about fixing the bug then, or to explicitly say in
> > > gem5.org that SYSTEMC has to be disabled in order
> > >
> > > to be compliant (which is not the best approach IMO).
> > >
> > >
> > > Gabe, what's your opinion on this? Can you provide a better alternative
> > to
> > > my patch?
> > >
> > > Otherwise, If nobody wants to spend time on this I feel we should go on
> > > merging the patch with a remainder of reverting it
> > >
> > > once we deprecate usage of GCC4.8/9
> > >
> > >
> > > Giacomo
> > >
> > > 
> > > From: gem5-dev  on behalf of Chang Hyun
> Park
> > <
> > > heartinpi...@gmail.com>
> > > Sent: 27 November 2018 02:11:34
> > > To: gem5 Developer List
> > > Subject: Re: [gem5-dev] GCC4.X support
> > >
> > > Dear Jason and Giacomo,
> > >
> > > We are running our simulation clusters on Ubuntu 14.04 (LTS) which will
> > > expire next April.
> > > Ubuntu 14.04 ships with GCC 4.8.
> > >
> > > If its not too much hassle supporting 4.8, what about dropping support
> > for
> > > gcc < 5.0 after the EOL of Ubuntu 14.04?
> > > (So perhaps drop support for gcc < 5.0 beginning May 2019)
> > >
> > > Best Regards,
> > > Chang Hyun Park
> > >
> > > > On 27 Nov 2018, at 3:53 AM, Jason Lowe-Power 
> > > wrote:
> > > >
> > > > Dropping 4.8/4.9 works for me. Maybe we should also email gem5-users
> to
> > > see
> > > > if anyone is using old clusters.
> > > >
> > > > Jason
> > > >
> > > > On Mon, Nov 26, 2018 at 9:34 AM Giacomo Travaglini <
> > > > giacomo.travagl...@arm.com> wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >>
> > > >> There is an ongoing discussion about dropping support for gcc < 5.0.
> > > >> (At the moment we support gcc/4.8: http://www.gem5.org/Dependencies
> <
> > > >> http://www.gem5.org/Dependencies)>)
> > > >>
> > > >> It sparked from the following patch
> > > >>
> > > >> https://gem5-review.googlesource.com/c/public/gem5/+/14315
> > > >>
> > > >> which is keeping gem5 gcc4.x compliant. If we decide to drop
> support,
> > I
> > > >> will abandon the patch.
> > > >> (ideally when http://www.gem5.org/Dependencies gets updated)
> > > >>
> > > >> Does anybody have any concern about that?
> > > >>
> > > >> Thanks
> > > >>
> > > >> Giacomo
> > > >>
> > > >>
> > > >> 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.
> > 

Re: [gem5-dev] custom allocator for Request/Packet objects

[Jason Lowe-Power]

Couple more comments below.

On Thu, Nov 29, 2018 at 3:08 PM Gabe Black  wrote:

> I looked at the code as is, and Packets themselves aren't ever inherited by
> anything, and they maintain a stack (I think) of sender state objects which
> doesn't affect the size of the packet. The sender state is inherited in a
> bunch of places since that is often customized. As far as compressed
> packets, what would the benefit be? It seems like there would be a lot of
> overhead to compress and decompress them, and I don't think they ever get
> all that big. I'm also hesitant to add "final" in there since I think it
> would be potentially limiting, but sometimes sensible limits are useful
> :-).
>

Not to speak for Daniel too much, but I think he was planning on modeling
the *data* in the packet being compressed. Then, there may be a different
packet size depending on the compression ratio of the data, for instance. I
think this would be cleaner to implement by inheriting from packet than
adding the interface to the current Packet. But, this isn't a hard
requirement. It was just an example of why we might want to inherit from
Packet at some point.

>
> The reason exactly how big Request/Packets are is a concern is that I think
> you'd get a meaningful performance benefit if you could use extra knowledge
> to do things faster than just using new. For instance, if you knew that
> what you were allocating was always X bytes, then you could just have a
> bunch of blocks of X bytes laying around in a list and return one when
> asked. You wouldn't have to try to keep things compacted like new would, or
> keep track of (or even check) how big things were. That marginal bit of
> savings could make a big difference if allocations happened a lot,
> particularly if the type of allocations were ones new (and/or malloc if
> it's built on it) was bad at. My brief Googling says malloc is bad at lots
> of small allocations, for what that's worth.
>

We use tcmalloc as our default allocator right now. I wonder how that
compares. IIRC, when we moved from malloc to tcmalloc we got a ~10%
performance boost. At least, that's what Hansson said ;).


>
> Also, a custom allocator could make some types of debugging marginally
> harder. For instance, if you used valgrind, it would replace malloc/new,
> and that wouldn't be used in the typical way for those types. They would
> likely be mostly batch allocated at the start of simulation, and then just
> returned by the various mechanisms later. That would make information about
> where a particular Request object came from less useful, although you would
> still likely be able to see that it was accessed in an illegal way, and
> where that access happened.
>

This is a big downside. I've found memory errors with valgrind in packets
*many times* due to how we copy data in to/out of them. This might be a
show stopper for me.

As a side note, tcmalloc has bitten me a number of times here. I've run
valgind with tcmalloc and seen "0 bytes allocated and 0 bytes deleted"
after waiting for hours too many times. I have finally learned to recompile
everything using "--without-tcmalloc" before running valgind.


> I agree that taking an incremental approach and doing some experiments are
> worth while, and that wrapping request allocation in a small function would
> be a good first step. I can't promise a timeline, but hopefully I'll have
> something to share at some point in the future.
>
> Gabe
>
> On Thu, Nov 29, 2018 at 9:21 AM Nikos Nikoleris 
> wrote:
>
> > Hey all,
> >
> > The bigger opportunity is probably around packets as sometimes we are
> > allocating a number of them per request.
> >
> > A custom allocator would be a great contribution if it would make gem5
> > substantially faster. But if it proved make things only marginally
> > better, I agree with Jason, we would need to factor in the fact that we
> > will be making the code more fragile. Would debugging/profiling be
> > harder if we used a custom deallocator?
> >
> > If the size of the Packet is a concern, we will probably have to deal
> > with members that are not fixed in size such as the senderState. It
> > might also be worth looking into something similar for the pointers from
> > packets such as data.
> >
> > Packet and Request memory management is something that we have been
> > concerned about as well. Giacomo, recently, changed all naked Request
> > pointers for shared_ptr and now we don't have to manually deallocate
> > them. But when we tried to do this for Packet pointers (figuring out
> > when to de-allocate a packet is not trivial) there was a substantial
> > 

Re: [gem5-dev] integrating systemc tests into testing framework

[Jason Lowe-Power]

Hey Gabe,

Sorry for the slow response. I've been hoping to make more progress on the
testing framework, but as always, it's been put on the back burner.

The current state is that things should be all working. The best thing you
could help with is adding new tests (e.g., for systemc) and porting old
tests over to find the missing features, missing documentation, etc. I have
some patches that are very close to being ready for memory tests (e.g.,
traffic gen) and CPU tests, but I'm working with some students to get them
pushed and it's taking longer than I hoped. Hopefully, this will happen in
the next couple of weeks.

Related, I think the jenkins/kokoro integration is very close as well. I
was working on it last month, and I remember everything mostly working. I
think it just needed some more testing (preferably with more tests). I'll
have some time the week of the 14th to look into this more.

Let me know if you have any specific questions on how to add tests to the
new testing framework. I tried to write good documentation in TESTING.md,
but it may be missing things. I'll be more responsive next time :).

Cheers,
Jason



On Thu, Jan 3, 2019 at 5:30 PM Gabe Black  wrote:

> Hello...?
>
> On Tue, Dec 18, 2018 at 3:26 PM Gabe Black  wrote:
>
>> These changes have all been checked in. I still need some info about how
>> to hook them systemc tests into Jason and co's framework.
>>
>> In general, how is getting that framework installed and ready to use
>> coming along? Is there any blocking issue I can help with?
>>
>> Gabe
>>
>> On Wed, Dec 5, 2018 at 7:16 PM Gabe Black  wrote:
>>
>>> Hi folks, and specifically Jason.
>>>
>>> With these pending changes, the systemc tests (with the checked in
>>> filter applied) should all pass, and should be well behaved and not leave
>>> random files scattered around the source tree when run. Three of these
>>> changes fix some small bugs I found while finishing this out, and two
>>> update reference test output to match gem5's legal but slightly different
>>> behavior compared to Accellera.
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/14915
>>> https://gem5-review.googlesource.com/c/public/gem5/+/14916
>>> https://gem5-review.googlesource.com/c/public/gem5/+/14917
>>> https://gem5-review.googlesource.com/c/public/gem5/+/14918
>>> https://gem5-review.googlesource.com/c/public/gem5/+/14919
>>>
>>> The next step will be to integrate these tests into the overarching test
>>> framework Jason and co. have been working on. I'm pretty sure there's
>>> documentation out there which should tell me how to do this, but to save me
>>> some minor effort could someone point out what I should read to see how to
>>> do this? Any other tips or suggestions to keep in mind?
>>>
>>> Gabe
>>>
>>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Finding tests in the new test framework

[Jason Lowe-Power]

Hey Gabe,

I agree that the current implementation isn't the best. I'm happy to hear
suggestions for better test discovery. Even a little yaml file or something
like that in tests/ which lists all of the files to execute to look for
tests would be fine with me. I don't love the idea of using SCons (plus it
has all of the downsides you just mentioned ;)). @Sean Wilson
, do you have any recollection of what we were
thinking when we implemented this?

Re: Name of tests/main.py. I agree that this is not a great long-term name.
I'd like to put off renaming it until we delete all of the old testing
framework, though.

Cheers,
Jason

On Wed, Jan 16, 2019 at 3:30 PM Gabe Black  wrote:

> Hi folks. I'm getting started integrating the systemc tests into the new
> testing framework, and I'd like to change how it finds tests to run.
> Currently it scans for files which starts or ends with test or tests, ends
> in .py, and which separate test or tests with a - or _ from the rest of the
> name. It looks for those files recursively relative to the current
> directory. That has a few problems.
>
> First, once a bug is fixed I have a CL out for, the tests/main.py (may need
> a better name? Not obvious that's what you're supposed to run) can be run
> from outside the tests directory. That means that you may end up scanning
> files that you don't intend, or not scanning files that you do intend. I
> don't think the directories you look in should be based on your current
> directory, although I don't immediately have another proposal. I haven't
> put a ton of thought into it yet, suggestions welcome.
>
> Second, it's easy to have false positives. For instance, when I attempted
> to run main.py from the root of the checkout, so ./tests/main.py, it picked
> up a file in ext/googletest,
> specifically
> ext/googletest/googlemock/scripts/generator/cpp/gmock_class_test.py.
> It then dutifully executed that code to look for tests. In this case that
> file doesn't seem to do anything, but I don't think it's unrealistic that
> there could be accidental undesirable side effects from something which has
> an unfortunate name. I think if we're going to be executing things to see
> what tests they define (which is reasonable IMO), we should make sure their
> author intended for them to be used that way.
>
> In addition to accidental name collisions, there are definitely security
> implications from this scheme. Let's say I've got a gem5 tree checked out
> which no one else can modify, but for whatever reason they can still create
> files within. If they make a file with the right name, they can run
> arbitrary code as the owner of the tree just by tucking something away deep
> in the file hierarchy of gem5 somewhere when they go to run the tests. This
> is particularly dangerous when the paths that are scanned aren't well
> constrained/constant.
>
> Finally, the framework seems to be written with the intention that all
> tests would go in the tests directory. This has been gem5's tendency
> historically, but I think, outside of a few potential exceptions, it's a
> bad practice. Tests should be alongside the things that are being tested.
> For instance, if I get the systemc tests hooked into the new framework,
> that should be in src/systemc/tests (where the tests live), not in
> tests/systemc or similar.
>
> That makes it important to be able to be able to run the framework on
> directories outside the tests directory, minimally in the src directory,
> and have it do the "right thing", not run errantly named files, etc.
>
> Thoughts? Suggestions?
> Gabe
> ___
> 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] test framework and parallelism

[Jason Lowe-Power]

Hey Gabe,

Right now, there's two parallelism options: -j, which sets the number of
things to compile simultaneously (just passes it on to scons), and -t which
specifies the number of different test cases (suites) to run in parallel.

I'd have to dig through the ext/testlib code to point you to exactly where
the -t option is used, but I think that's what you'd want to use. IIRC,
Sean also set up things so you could have a remote test server that was
used to execute parallel tasks. I'm not sure if that was fully plumbed out,
though.

This might help you get started:
https://gem5.googlesource.com/public/gem5/+/master/ext/testlib/main.py#269

Cheers,
Jason

On Wed, Jan 16, 2019 at 4:14 PM Gabe Black  wrote:

> Hi folks. I'm integrating the systemc tests into the testing framework, and
> I wonder what level of parallelism there is in the framework itself, what
> level of parallelism the tests themselves should utilize, and how that's
> plumbed down.
>
> For instance, I have a verify.py script I wrote to run and verify the
> systemc tests. It has a lot of nice features that would be difficult to
> plumb through the framework so I want to keep it as its own independent
> entity. It has the ability to run scons to build the tests and the tests
> themselves in parallel which is very useful. I could make it automatically
> detect how much parallelism it might want to use, but that would likely be
> somewhat hard to do in a system dependent way, ie to make it work on macs
> without having one to test on, and we don't necessarily want it to run as
> wide as possible regardless of what else might be going on in the system,
> test wise or otherwise.
>
> Is there a way to tell the test framework to do things in parallel? Is
> there a way to allocate some amount of parallelism at the scheduler level
> (if a level like that exists) for a particular test, and how is that
> communicated to the test?
>
> Gabe
> ___
> 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] git push woes

[Jason Lowe-Power]

Hi Dave,

Is it possible that you have not committed your change? It says that there
is no difference from your code to googlesource master. That often means
that there is no commit that differs.

Try running "git log" and making sure that you have an entry for the commit
you are expecting to push.

If that doesn't work, let me know and we can try to find a solution.

Cheers,
Jason

On Sat, Feb 2, 2019 at 9:44 AM David Taylor Kerns 
wrote:

> Hello,
> I'm trying to contribute a 1-line (1 char) fix to
>
> http://grok.gem5.org/xref/gem5/configs/example/se.py?a=true&h=#157
>
> there's a missing ']' @ line 157
>
> - exec("workload = %s(buildEnv['TARGET_ISA', 'linux', '%s')" % (
>
> + exec("workload = %s(buildEnv['TARGET_ISA'], 'linux', '%s')" % (
>
>
>
> the git repo is fighting me  :(
>
> $ git push origin HEAD:refs/for/master
> Total 0 (delta 0), reused 0 (delta 0)
> remote: Processing changes: refs: 1, done
> To https://gem5.googlesource.com/public/gem5
>  ! [remote rejected] HEAD -> refs/for/master (no new changes)
> error: failed to push some refs to '
> https://gem5.googlesource.com/public/gem5'
>
> thanks for any help you can provide
>
> Dave
> ___
> 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] git push woes

[Jason Lowe-Power]

Hey Dave,

Install the git commit hook:
f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f
https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x $f

Then run "git commit --amend"

Jason

On Sat, Feb 2, 2019 at 10:08 AM David Taylor Kerns <
dtke...@email.arizona.edu> wrote:

> oh I see, (longer story here that I was skipping) my first clone was
> associated with a bad email address...
> and my commit on the 2nd  clone failed w/out me noticing ... ok, that's
> resolved, now I'm back to a (new) push error
>
> It looks like the error message tells me almost everything I need ...
> except where to create the Change-Id
>
>  $ git push origin HEAD:refs/for/master
> Counting objects: 9, done.
> Delta compression using up to 24 threads.
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (5/5), 435 bytes | 0 bytes/s, done.
> Total 5 (delta 4), reused 0 (delta 0)
> remote: Resolving deltas: 100% (4/4)
> remote: Processing changes: refs: 1, done
> remote: ERROR: commit 050aa7a: missing Change-Id in message footer
> remote:
> remote: Hint: to automatically insert a Change-Id, install the hook:
> remote: f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f
> https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x
> $f
> remote: and then amend the commit:
> remote:   git commit --amend
> remote: Finally, push your changes again
> remote:
> To https://gem5.googlesource.com/public/gem5
>  ! [remote rejected] HEAD -> refs/for/master (commit 050aa7a: missing
> Change-Id in message footer)
> error: failed to push some refs to '
> https://gem5.googlesource.com/public/gem5'
>
>
> On Sat, Feb 2, 2019 at 10:49 AM Jason Lowe-Power 
> wrote:
>
> > Hi Dave,
> >
> > Is it possible that you have not committed your change? It says that
> there
> > is no difference from your code to googlesource master. That often means
> > that there is no commit that differs.
> >
> > Try running "git log" and making sure that you have an entry for the
> commit
> > you are expecting to push.
> >
> > If that doesn't work, let me know and we can try to find a solution.
> >
> > Cheers,
> > Jason
> >
> > On Sat, Feb 2, 2019 at 9:44 AM David Taylor Kerns <
> > dtke...@email.arizona.edu>
> > wrote:
> >
> > > Hello,
> > > I'm trying to contribute a 1-line (1 char) fix to
> > >
> > > http://grok.gem5.org/xref/gem5/configs/example/se.py?a=true&h=#157
> > >
> > > there's a missing ']' @ line 157
> > >
> > > - exec("workload = %s(buildEnv['TARGET_ISA', 'linux', '%s')" % (
> > >
> > > + exec("workload = %s(buildEnv['TARGET_ISA'], 'linux', '%s')" % (
> > >
> > >
> > >
> > > the git repo is fighting me  :(
> > >
> > > $ git push origin HEAD:refs/for/master
> > > Total 0 (delta 0), reused 0 (delta 0)
> > > remote: Processing changes: refs: 1, done
> > > To https://gem5.googlesource.com/public/gem5
> > >  ! [remote rejected] HEAD -> refs/for/master (no new changes)
> > > error: failed to push some refs to '
> > > https://gem5.googlesource.com/public/gem5'
> > >
> > > thanks for any help you can provide
> > >
> > > Dave
> > > ___
> > > 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
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] git push woes

[Jason Lowe-Power]

Yeah, that seems kind of old. My version on Ubuntu 18.04 is 2.17, the
current version is 2.20. It looks like 1.8 was released in 2012.

Jason

On Sat, Feb 2, 2019 at 10:25 AM David Taylor Kerns <
dtke...@email.arizona.edu> wrote:

> I obviously have my noob hat on :) ... you told me the same thing git
> did... so here we go...
>
> $ f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f
> https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x
> $f
>  % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100  1754  100  17540 0   3328  0 --:--:-- --:--:-- --:--:--
> 3334
> dtkerns@compute:~/git/gem5$ git commit --amend
> git: 'interpret-trailers' is not a git command. See 'git --help'.
> cannot insert change-id line in .git/COMMIT_EDITMSG
>
> when I look at the content of the $f file it create I see
> interpret-trailers
> as an argument to an internal git command
>
> am I running the wrong version of git?
>
> $ git --version
> git version 1.8.3.1
>
>
> On Sat, Feb 2, 2019 at 11:14 AM Jason Lowe-Power 
> wrote:
>
> > Hey Dave,
> >
> > Install the git commit hook:
> > f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f
> > https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x
> > $f
> >
> > Then run "git commit --amend"
> >
> > Jason
> >
> > On Sat, Feb 2, 2019 at 10:08 AM David Taylor Kerns <
> > dtke...@email.arizona.edu> wrote:
> >
> > > oh I see, (longer story here that I was skipping) my first clone was
> > > associated with a bad email address...
> > > and my commit on the 2nd  clone failed w/out me noticing ... ok, that's
> > > resolved, now I'm back to a (new) push error
> > >
> > > It looks like the error message tells me almost everything I need ...
> > > except where to create the Change-Id
> > >
> > >  $ git push origin HEAD:refs/for/master
> > > Counting objects: 9, done.
> > > Delta compression using up to 24 threads.
> > > Compressing objects: 100% (5/5), done.
> > > Writing objects: 100% (5/5), 435 bytes | 0 bytes/s, done.
> > > Total 5 (delta 4), reused 0 (delta 0)
> > > remote: Resolving deltas: 100% (4/4)
> > > remote: Processing changes: refs: 1, done
> > > remote: ERROR: commit 050aa7a: missing Change-Id in message footer
> > > remote:
> > > remote: Hint: to automatically insert a Change-Id, install the hook:
> > > remote: f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f
> > > https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod
> +x
> > > $f
> > > remote: and then amend the commit:
> > > remote:   git commit --amend
> > > remote: Finally, push your changes again
> > > remote:
> > > To https://gem5.googlesource.com/public/gem5
> > >  ! [remote rejected] HEAD -> refs/for/master (commit 050aa7a: missing
> > > Change-Id in message footer)
> > > error: failed to push some refs to '
> > > https://gem5.googlesource.com/public/gem5'
> > >
> > >
> > > On Sat, Feb 2, 2019 at 10:49 AM Jason Lowe-Power 
> > > wrote:
> > >
> > > > Hi Dave,
> > > >
> > > > Is it possible that you have not committed your change? It says that
> > > there
> > > > is no difference from your code to googlesource master. That often
> > means
> > > > that there is no commit that differs.
> > > >
> > > > Try running "git log" and making sure that you have an entry for the
> > > commit
> > > > you are expecting to push.
> > > >
> > > > If that doesn't work, let me know and we can try to find a solution.
> > > >
> > > > Cheers,
> > > > Jason
> > > >
> > > > On Sat, Feb 2, 2019 at 9:44 AM David Taylor Kerns <
> > > > dtke...@email.arizona.edu>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > > I'm trying to contribute a 1-line (1 char) fix to
> > > > >
> > > > > http://grok.gem5.org/xref/gem5/configs/example/se.py?a=true&h=#157
> > > > >
> > > > > there's a missing ']' @ line 157
> > > > >
> > > > > - exec("workload = %s(buildEnv['TARGET_ISA&#x

[gem5-dev] Including test workloads

[Jason Lowe-Power]

Hi all,

Based off of the conversation on [1] I think we should have a broader
discussion of how to include test code.

We have a number of different options with tradeoffs. I'd like to get this
right the first time and not have to go back and change things, so let's
try to hash this out now. :)

There are multiple goals in mind when choosing testing workloads. In my
mind, there's the following, but I may be missing some other goals as well.
1) Short. We want tests to run in seconds or minutes, not hours
2) High coverage. Best case scenario is that we have a bunch of really
short tests that execute in seconds that each coveres a different (small)
part of gem5 and a couple of slightly longer tests that cover a larger part
of gem5.
3) Unencumbered by licensing (for example, SPEC wouldn't work)
4) Tests performance in an understandable way (relates to 2). Simple
workloads like matrix multiply are nice here. We know the memory footprint
so we should be able to predict the cache misses, for instance. Or predict
the number of FLOPs.

# Option 1: Include simple code from other sources
This is what I've currently done. I went to the LLVM test suite (
https://github.com/llvm-mirror/test-suite/) and grabbed a couple of
workloads. My thoughts with using the llvm test suite is that they would
have a number of workloads with different characteristics, be unencumbered,
and short. It turns out most of the workloads aren't that short, so I chose
a couple of the smallest ones I could find first.

# Option 2: Roll our own
I don't think we have the developer time to do this generally. The RISC-V
tests are a good example of how we can do a great job when we do have time,
though.

# Option 3: Choose other well-known benchmarks test suites
I'm open to other ideas. I just went with what I thought was quick and easy.

# How to include the workloads
We also have to decide how to include the workloads. I feel strongly that
we should not include binaries in the repo, so I developed the
"DownloadedProgram" fixture for the new test infrastructure that will
automatically download the application when needed from gem5.org or any
other location.

On the other hand, I'm less sure about where to include the code for the
tests. I don't *love* including it in the gem5 repo. However, it's really
nice to be able to see all of the code for a test in one place and not have
to search through multiple repos and our less than stellar documentation.
It's important to keep things simple in the tests, otherwise people won't
use it.

I'm open to having a separate gem5-test-workloads repository if this is
something that others want (maybe with submodules pointing to other
projects like llvm-suite and linux). In the long term, I think this is the
best solution, but I had decided it wasn't worth the headache in the short
term.

Let me know what others think. I'd like to either get this right the first
time or have a solid plan for how we're going to get it right in the future.

Cheers,
Jason

[1]
https://gem5-review.googlesource.com/c/public/gem5/+/15857/1/tests/gem5/cpu_tests/benchmarks/FloatMM.c
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Status of automated CI on Gerrit reviews before merging

[Jason Lowe-Power]

Hi Ciro,

Yeah, I've been working on this for a while, albeit slowly. The main thing
you could do to help is to test and review the new testing infrastructure
changes:
https://gem5-review.googlesource.com/q/owner:yazakram%2540ucdavis.edu.
Another huge help would be to convert the old tests in tests/configs to the
new test infrastructure in tests/gem5.

I've been putting off getting CI going until we have a few tests to
actually run, but once the changes linked above are committed, I'll move my
focus to CI.

Jason

On Fri, Feb 8, 2019 at 3:40 AM Ciro Santilli  wrote:

> Hi people,
>
> I really feel the need for a CI system that tests the build and posts
> some kind of comment on Gerrit before we merge, to help preventing
> breaking the build.
>
> I've been told someone might be working on it already. If that is the
> case, what are you looking into, and what is the status of the
> investigation?
>
> If there is any way that I can help, let me know. I would likely need
> some kind of admin permission on a sandbox gerrit repo try stuff out
> myself in that case.
> 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] Panic when trying to run SPEC2017 on GEM5

[Jason Lowe-Power]

Hey Dan,

There are probably a couple of issues you're seeing:
1) The invalid instruction is likely an SSE or AVX instruction that gem5
doesn't implement. You *could* solve this by using something like
-march=athlon64, but there are downsides to compiling for a 20 year old
processor
2) Running in SE mode, you'll likely find important syscalls that aren't
implemented (and you may get bad data). SE mode doesn't model many
important system-level interaction (e.g., page table walks) which can have
significant effects on modern workloads.

The "solution" to 2) is to use FS mode, but I don't have a good solution to
1). We need to get our x86 implementation up to date, but as far as I know
no one is working on it right now.

Cheers,
Jason

On Fri, Feb 8, 2019 at 6:40 AM Dan Recher  wrote:

> Hello,
>
> While trying to run perlbench from SPEC2017 with se.py config on top of
> Ubuntu 18 and perlbench compiled in Ubuntu 18 as well, it's seems that
> compilation generated modern instruction that are not supported by Gem5.
>
> log:
> command line: ./build/X86/gem5.opt configs/example/se.py -c
>
> /home/dan/SPEC2017/benchspec/CPU/500.perlbench_r/exe/perlbench_r_base.mytest-m64
> -o /home/dan/SPEC2017/benchspec/CPU/500.perlbench_r/data/test/input/
> makerand.pl
>  REAL SIMULATION 
> info: Entering event queue @ 0.  Starting simulation...
> warn: ignoring syscall access(...)
> warn: ignoring syscall access(...)
> warn: ignoring syscall access(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall access(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall rt_sigaction(...)
>   (further warnings will be suppressed)
> panic: Unrecognized/invalid instruction executed:
>
> {
> leg = 0x10,
> rex = 0x8,
> vex/xop = 0x61,
> op = {
> type = three byte 0f38,
> op = 0xf7,
> },
> modRM = 0,
> sib = 0,
> immediate = 0,
> displacement = 0
> dispSize = 0}
> Memory Usage: 694576 KBytes
> Program aborted at tick 327822000
>
>
> --> does anyone encounter with this problem? does anyone run SPEC2017 in
> GEM5?
> should I downgrade my ubuntu to previous version or there is any other
> solution?
>
> Thanks,
> Dan Recher
> ___
> 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] Status of automated CI on Gerrit reviews before merging

[Jason Lowe-Power]

Hi Ciro,

We're planning on using the Google Jenkins server. Google has graciously
said they will donate the needed CPU cycles :). See
https://gem5.googlesource.com/testing/jenkins-gem5-prod/ for the current
state of the CI testing. I'll start looking into this again, soon.

Cheers,
Jason

On Fri, Feb 8, 2019 at 8:28 AM Ciro Santilli  wrote:

> On 2/8/19 3:13 PM, Jason Lowe-Power wrote:
> > Hi Ciro,
> >
> > Yeah, I've been working on this for a while, albeit slowly. The main
> thing
> > you could do to help is to test and review the new testing infrastructure
> > changes:
> > https://gem5-review.googlesource.com/q/owner:yazakram%2540ucdavis.edu.
> > Another huge help would be to convert the old tests in tests/configs to
> the
> > new test infrastructure in tests/gem5.
> >
> > I've been putting off getting CI going until we have a few tests to
> > actually run, but once the changes linked above are committed, I'll move
> my
> > focus to CI.
> >
>
> OK, awesome! I'll try to have a look at those patches.
>
> Do you have any ideas about which CI provider to go for?
>
> I think an automated build would already add a lot of value to prevent
> the build itself from breaking, even if the test system is not perfect.
>
> > Jason
> >
> > On Fri, Feb 8, 2019 at 3:40 AM Ciro Santilli 
> wrote:
> >
> >> Hi people,
> >>
> >> I really feel the need for a CI system that tests the build and posts
> >> some kind of comment on Gerrit before we merge, to help preventing
> >> breaking the build.
> >>
> >> I've been told someone might be working on it already. If that is the
> >> case, what are you looking into, and what is the status of the
> >> investigation?
> >>
> >> If there is any way that I can help, let me know. I would likely need
> >> some kind of admin permission on a sandbox gerrit repo try stuff out
> >> myself in that case.
> >> 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
> >
>
> 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] SimObject Param types which are template classes

[Jason Lowe-Power]

Hey Gabe,

Could you describe in a little more detail why you want to templatize a
SimObject. Since python doesn't have support for templates, I don't really
like the idea of supporting this.

One option is to have the Python side of the SimObject be the
"specialization" and then you'd just have to implement the
SimObjectParams::create() function to return the specialized template for
each of the types you want to support from Python. Does that make sense?
Maybe this is what you meant by "subclassing"

For instance:

*my_simobject.hh:*
template 
MySimObject public SimObject
{
...
};

*my_simobject.cc:*
MySimObjectIntParams::create() {
return MySimObject(this);
}

MySimObjectFloatParams::create() {
return MySimObject(this);
}

*MySimObject.py:*
class MySimObjectGeneric(SimObject): # I'm not sure if this is exactly
right...
   ...
   

class MySimObjectInt(MySimObjectGeneric):



class MySimObjectFloat(MySimObjectGeneric):



I would say that if the above doesn't work now, we should update things so
it does work. However, I don't think we should do any of this
*automatically* for templated SimObjects.

Cheers,
Jason

On Fri, Feb 15, 2019 at 5:55 PM Gabe Black  wrote:

> Hi folks. I'm trying to create a SimObject out of a templated class (the
> python Param type uses a specialization of it), and the pybind11 generated
> code doesn't compile because the predeclaration of the class type isn't
> syntactically correct since it's a template. I can work around this problem
> by, for instance, subclassing it and then using that subclass (at least I
> think I can, I haven't tried it yet), but it would be nice if the system
> could handle it.
>
> It's not obvious how to fix it since it's not obvious from the fully
> specified type how it should be prototyped, so it's not a quick fix. Has
> anyone attempted to get this to work, and/or have a solution?
>
> Thanks!
> Gabe
> ___
> 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] Python 2.7 vs 3.x integer division: Should we change the Python 2.7 defaults?

[Jason Lowe-Power]

Hey Andreas,

I'd be happy to use the future version and switch the uses of "/" to "//"
when floordiv was intended. It should be pretty obvious when floordiv was
intended, and I imagine that it's every case of "/" in the current codebase.

I *do* hope that Python 3 returns 1.5 for 3/2 and not 1.4, though. ;)

Cheers,
Jason

On Mon, Feb 25, 2019 at 6:41 AM Andreas Sandberg 
wrote:

> Hi Everyone,
>
> TL;DR; Python 3 changes the default behaviour of division. Should we
> enable the same behaviour in Python 2.7?
>
> Most of you have probably been hit by my Python 3 spam recently. Sorry
> about that. :( The good news is that there are only a handful of changes
> left to merge before gem5 works in Python 3. Once that happens, we'll
> probably start running (some of) our internal regressions using Python 3
> instead of (or in addition to) Python 2.7.
>
> There is still one potential gotcha when using Python 3 in gem5, integer
> divisions. Unlike Python 2.7, the default behaviour when dividing two
> integers in Python 3 is to promote to floating point if necessary. I.e.,
> if you were to evaluate 3/2 in you'd get the following results:
>
> Python 3: 1.4
> Python 2.x: 1
>
> The operator above is known as "true division" (__truediv__) in Python
> 3. To get the old behaviour, there is a new operator (// or
> __floordiv__) called floor division that is supported since Python 2.2.
> For example, evaluating 3//2 would result in 1 in both Python 2.7 and
> Python 3.
>
> The new behaviour can be enabled by default in Python 2.7 by importing
> division from __future__. Should we enable this by default to get
> consistent behaviour of division across Python 2 and 3?
>
> 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] Port configuration overhaul

[Jason Lowe-Power]

Hey Gabe,

I was digging through the old reviewboard and found this patch that also
re-did this interface: http://reviews.gem5.org/r/1301

I'm not sure why this was never committed.

I believe Andreas H's goal was to enable TLM-2 interfaces with the gem5,
IIRC.

Just something to consider.

Cheers,
Jason

On Thu, Mar 7, 2019 at 7:00 AM Gabe Black  wrote:

> Hey folks, specifically folks looking at this doc. I have a series of
> patches which largely implement what I was going for, although it turned
> out differently than what I have in my doc. I'll update the doc soon(ish)
> to describe the current version. Go ahead and review the CLs if you want,
> although I should probably run another test or two on them and the
> discussion of the design is still open over on the doc.
>
>
> https://gem5-review.googlesource.com/q/topic:%22tlm%22+(status:open%20OR%20status:merged)
>
> Gabe
>
> On Wed, Mar 6, 2019 at 12:20 AM Gabe Black  wrote:
>
> > Hi folks. I've been looking at how to configure TLM sockets through
> gem5's
> > port configuration mechanism and how gem5's port configuration mechanism
> > works in general, and I think I've mostly come up with a plan. I've
> written
> > everything up in a doc over here:
> >
> >
> >
> https://docs.google.com/document/d/17eXkE9YtzvYXEgkHFNR1my_xYKl3mYNNtXM9pIAX-t0/edit?usp=sharing
> >
> > Please take a look if you have a chance, and please comment on the doc if
> > you have any questions, concerns, etc.
> >
> > I created the doc on my personal account but wrote it from my work
> account
> > so it *should* be accessible and commentable by anyone with the link.
> > Please let me know if that's not the case.
> >
> > Gabe
> >
> ___
> 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] Port configuration overhaul

[Jason Lowe-Power]

Hey Gabe,

I'll need to think about this a bit more myself, but do you think these
changes will increase the places we can use ports? Like Andreas was saying,
it would be nice to use it for things like interrupt routing, connecting
TLBs, and connecting all of the wavefronts in the GPU to the coalescer,
etc. These are a few places that I can think of trying to use ports where
it wasn't a great semantic before.

Cheers,
Jason

On Thu, Mar 14, 2019 at 6:12 AM Gabe Black  wrote:

> Great, I'm glad you're in favor of this. I have a new, hopefully more final
> batch of patches incoming soon which also include application of the new
> mechanism to TLM sockets.
>
> Gabe
>
> On Thu, Mar 14, 2019 at 2:47 AM Andreas Sandberg  >
> wrote:
>
> > Hi Everyone,
> >
> > I remember talking to Andreas H about this many years ago. If I remember
> > correctly, the main reason the patch wasn't committed at the time was
> > performance related. IIRC, the patch series had a ~10%-20% performance
> > hit. I suspect it the patch Jason pointed to isn't the main reason for
> > any performance issues though, it's more likely one of the subsequent
> > patches that added TLM-like 4-phase handshakes.
> >
> > I'm very much in favour of sorting out the ports vs protocol issue once
> > and for all. A generic port interface would be extremely useful for
> > interrupt routing which is currently very ad-hoc.
> >
> > Cheers,
> > Andreas
> >
> > On 07/03/2019 19:42, Steve Reinhardt wrote:
> > > Thanks for digging this up, Jason.  I knew this issue had been
> addressed
> > > multiple times before (I think I even had a patch at one point that
> was a
> > > smaller change, but held it off in favor of Andreas's version).  I
> don't
> > > know why Andreas's change was never committed either.
> > >
> > > Anyway, it will be good to see this cleaned up, regardless of whether
> we
> > go
> > > with Andreas's code or Gabe's proposal or some hybrid.  I've been out
> of
> > > the loop long enough that I don't have a specific preference.
> > >
> > > Steve
> > >
> > >
> > > On Thu, Mar 7, 2019 at 10:19 AM Jason Lowe-Power 
> > > wrote:
> > >
> > >> Hey Gabe,
> > >>
> > >> I was digging through the old reviewboard and found this patch that
> also
> > >> re-did this interface: http://reviews.gem5.org/r/1301
> > >>
> > >> I'm not sure why this was never committed.
> > >>
> > >> I believe Andreas H's goal was to enable TLM-2 interfaces with the
> gem5,
> > >> IIRC.
> > >>
> > >> Just something to consider.
> > >>
> > >> Cheers,
> > >> Jason
> > >>
> > >> On Thu, Mar 7, 2019 at 7:00 AM Gabe Black 
> wrote:
> > >>
> > >>> Hey folks, specifically folks looking at this doc. I have a series of
> > >>> patches which largely implement what I was going for, although it
> > turned
> > >>> out differently than what I have in my doc. I'll update the doc
> > soon(ish)
> > >>> to describe the current version. Go ahead and review the CLs if you
> > want,
> > >>> although I should probably run another test or two on them and the
> > >>> discussion of the design is still open over on the doc.
> > >>>
> > >>>
> > >>>
> > >>
> >
> https://gem5-review.googlesource.com/q/topic:%22tlm%22+(status:open%20OR%20status:merged)
> > >>> Gabe
> > >>>
> > >>> On Wed, Mar 6, 2019 at 12:20 AM Gabe Black 
> > wrote:
> > >>>
> > >>>> Hi folks. I've been looking at how to configure TLM sockets through
> > >>> gem5's
> > >>>> port configuration mechanism and how gem5's port configuration
> > >> mechanism
> > >>>> works in general, and I think I've mostly come up with a plan. I've
> > >>> written
> > >>>> everything up in a doc over here:
> > >>>>
> > >>>>
> > >>>>
> > >>
> >
> https://docs.google.com/document/d/17eXkE9YtzvYXEgkHFNR1my_xYKl3mYNNtXM9pIAX-t0/edit?usp=sharing
> > >>>> Please take a look if you have a chance, and please comment on the
> doc
> > >> if
> > >>>> you have any questions, conce

[gem5-dev] Multiple inheirtance for SimObjects and Garnet networks

[Jason Lowe-Power]

derived class.
>
> Using virtual inheritance in SimObjects is also simple and painless. It
> requires only three small changes to the constructor:
> 1. We add a default argument so that the constructor can be implicitly
> called by derived classes that inherit virtually from it.
> 2. We explicitly call the base SimObject(p) instead of the immediate
> parent class constructor; this is only called by the most derived class in
> the hierarchy, and causes SimObject::_params to be defined.
> 3. We then add "p = params();" as the first line of the constructor; this
> way, if constructor is being called implicitly (as a virtual base class) by
> a derived class, it picks up the proper _params pointer to use for itself.
>
> Here's what the constructor ends up looking like:
>
>   Before:
> MySimObject(const Params *p) : MySimObjectParent(p) { ... }
>   After:
> MySimObject(const Params *p = nullptr) : SimObject(p) { p = params();
> ... }
>
>
> There is an alternative to this, which is to use templates where each
> derived SimObject takes a Params typedef as a template parameter, and
> passes it up the chain to the base SimObject so it can initialize the
> SimObject::_params variable with the proper type, which would then mean
> that base class params() methods would (automatically) upcast rather than
> downcast as we do now. There are, of course, other options along similar
> lines, to consider. I did explore this option a bit, but it turned out to
> be 1. very invasive, requiring updates to a lot of code 2. not really any
> cleaner or clearer in the end.
>
> I have been using this patch locally for several weeks now with no issues
> and have not encountered any overheads to worry about. For an example of
> where it makes much more sense to me to use multiple-inheritance is where
> Simple and Garnet2.0 network links were implemented. The authors ended up
> adding garnet and simple network specific parameters to the basicLink
> classes because they couldn't produce the kind of inheritance necessary to
> extend an entire hierarchy. I've attached a diagram describing the change.
> Although, in this instance, the code muckiness is relatively minor, I have
> noticed similar coding practices in various parts of gem5 codebase, where I
> would assume the authors would have used multiple-inheritance if it were
> available.
>
> Ryan Gambord
> 
>
>
>
> On Tue, Apr 2, 2019 at 2:51 PM Gabe Black (Gerrit) <
> noreply-gerritcodereview-0odfogtxitwjotgcull...@google.com> wrote:
>
>> To take a step back, not having multiple inheritance was a design
>> decision that was made a long time ago, I think specifically to avoid all
>> the craziness with virtual inheritance and all the challenges that come
>> along with it. Multiple inheritance is allowed when the additional classes
>> are just interfaces which the class implements which avoid much of the
>> complexity. I couldn't find any place that was written down unfortunately.
>>
>> If we were to allow general multiple inheritance and accept the overhead
>> of virtual inheritance, etc., then that would also have to be a design
>> decision with conversation on the mailing list, buy in (or at least a lack
>> of objection) from everybody, and then an implementation, but here we're
>> skipping ahead to that last step.
>>
>> Personally, I think disallowing multiple/virtual inheritance was a good
>> decision, and there would need to be a pretty compelling and pressing need
>> to start allowing it. I don't assert that no such reason exists, but I
>> haven't seen it yet.
>>
>> View Change <https://gem5-review.googlesource.com/c/public/gem5/+/17609>
>>
>>
>> To view, visit change 17609
>> <https://gem5-review.googlesource.com/c/public/gem5/+/17609>. To
>> unsubscribe, or for help writing mail filters, visit settings
>> <https://gem5-review.googlesource.com/settings>.
>> Gerrit-Project: public/gem5
>> Gerrit-Branch: master
>> Gerrit-Change-Id: Ic3664b37f55d0c0f0de95975190794a266c58350
>> Gerrit-Change-Number: 17609
>> Gerrit-PatchSet: 2
>> Gerrit-Owner: Ryan Gambord 
>> Gerrit-Reviewer: Alexandru Duțu 
>> Gerrit-Reviewer: Andreas Sandberg 
>> Gerrit-Reviewer: Gabe Black 
>> Gerrit-Reviewer: Jason Lowe-Power 
>> Gerrit-Reviewer: Nikos Nikoleris 
>> Gerrit-Reviewer: Ryan Gambord 
>> Gerrit-CC: John Alsop 
>> Gerrit-Comment-Date: Tue, 02 Apr 2019 21:51:48 +
>> Gerrit-HasComments: No
>> Gerrit-Has-Labels: No
>> Gerrit-MessageType: comment
>>
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Hardware transactional memory support in gem5

[Jason Lowe-Power]

Hello,

gem5 currently does not have support for hardware transactional memory. The
CPU core models (e.g., the O3CPU), the ISAs (x86 or ARM), and the memory
system (e.g., Ruby) would need to be enhanced to implement HTM.

Cheers,
Jason

On Fri, Apr 5, 2019 at 10:10 PM  wrote:

> Hi
> I am new to gem5. I have simulated a High Performance In-order ARM CPU
> model in FS mode. I want Hardware Transactional Memory support with the
> system so as to run STAMP benchmarks on it. Is some HTM model of a
> processor available for that purpose. The processor may not necessarily be
> ARM. I can go for x86 as well.
> ___
> 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