Re: [gem5-dev] Review Request 3817: arm, kvm: enable running 32-bit Guest under ARM KVM64

2017-02-24 Thread Rahul Thakur

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

(Updated Feb. 25, 2017, 1:24 a.m.)


Review request for Default.


Summary (updated)
-

arm, kvm: enable running 32-bit Guest under ARM KVM64


Repository: gem5


Description (updated)
---

Changeset 11874:85949465c50b
---
arm, kvm: enable running 32-bit Guest under ARM KVM64

1) Pass KVM_ARM_VCPU_EL1_32BIT to kvmArmVCpuInit
   when running 32-bit OS

2) Correctly map 64-bit registers to banked 32-bit ones

Change-Id: I20d138276f6cc5aff7a855988c2e30dccef5affc


Diffs (updated)
-

  src/arch/arm/kvm/armv8_cpu.cc ba90ffa751b6 
  src/arch/arm/kvm/base_cpu.cc ba90ffa751b6 

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


Testing
---


Thanks,

Rahul Thakur

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

Re: [gem5-dev] Review Request 3824: gpu-compute: Fix Python/C++ object hierarchy discrepancies

2017-02-24 Thread Brad Beckmann

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


Thanks for catching this bug.  I'm now a bit surprised this code work correctly 
before.

I have a couple questions/comments below.  The most important is possibly 
missing "max_outstanding_request" line.  Other than that, this patch looks good 
to me and points out we have more items to fix.


src/mem/ruby/system/GPUCoalescer.py (line 50)


This patch points out that we really should not have an icache or IFETCHes 
as part of the GPUCoalescer.  It is designed to only handle data accesses from 
the GPU CUs.

You don't necessarily need to remove this line and make all the other 
necessary changes, but if you don't, we'll get someone from AMD to make that 
change.



src/mem/ruby/system/GPUCoalescer.py (line 52)


Aren't you missing the following line:

max_outstanding_requests = Param.Int(16,
   "max requests (incl. prefetches) outstanding")


- Brad Beckmann


On Feb. 22, 2017, 9:28 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3824/
> ---
> 
> (Updated Feb. 22, 2017, 9:28 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11878:b0a4f3815b55
> ---
> gpu-compute: Fix Python/C++ object hierarchy discrepancies
> 
> The GPUCoalescer and the Shader classes have different base classes in
> C++ and Python. This causes subtle bugs in SWIG and compilation errors
> for PyBind.
> 
> Change-Id: I1ddd2a8ea43f083470538ddfea891347b21d14d8
> Reviewed-by: Andreas Hansson 
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/shader.hh ba90ffa751b6 
>   src/gpu-compute/shader.cc ba90ffa751b6 
>   src/mem/ruby/system/GPUCoalescer.hh ba90ffa751b6 
>   src/mem/ruby/system/GPUCoalescer.py ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3824/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

[gem5-dev] Review Request 3839: syscall_emul: style mods and small refactor to FDArray

2017-02-24 Thread Brandon Potter

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11893:3615e7d15a81
---
syscall_emul: style mods and small refactor to FDArray

Some members were defined as public when they should have been
privately declared so these were moved to the appropriate spot.

The operator[] had inline specified for for an in-class definition
which is redundant since inline definitions are always implicitly
inline.

Private members had the leading underscore applied to them to
denote that they're private (consistent with style guide).

Changed static const defined class variable into a constexpr
with brace-list initialization.


Diffs
-

  src/sim/fd_array.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/sim/fd_array.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 

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


Testing
---


Thanks,

Brandon Potter

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

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

2017-02-24 Thread Matthias Jung

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

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] Review Request 3835: sim: expand AuxVector class

2017-02-24 Thread Brandon Potter

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

(Updated Feb. 24, 2017, 6:59 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11891:11b2a627263e
---
sim: expand AuxVector class

The AuxVector class is responsible for holding Process data (in SE Mode
of course). The data that it holds is normally setup by an OS kernel in
the process address space. The purpose behind doing this is to pass in
information that the process will need for various reasons. (Check out
the enum in the header file for an idea of what the AuxVector holds.)

The AuxVector struct was changed into a class and encapsulation methods
were added to protect access to the member variables.

The host ISA may have a different endianness than the simulated ISA.
Since data is passed between the process address space and the
simulator for auxiliary vectors, we need to worry about maintaining
endianness for the right context.


Diffs (updated)
-

  src/arch/riscv/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/sparc/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/x86/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/sim/aux_vector.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/sim/aux_vector.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/alpha/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/arm/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/mips/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
  src/arch/power/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 

Diff: http://reviews.gem5.org/r/3835/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

2017-02-24 Thread Steve Reinhardt

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

Ship it!


Ship It!

- Steve Reinhardt


On Feb. 23, 2017, 2: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, 2: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 3836: x86: remove unnecessary parameter from functions

2017-02-24 Thread Michael LeBeane

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

Ship it!


Ship It!

- Michael LeBeane


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 3835: sim: expand AuxVector class

2017-02-24 Thread Michael LeBeane

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

Ship it!


Ship It!

- Michael LeBeane


On Feb. 24, 2017, 5:23 a.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3835/
> ---
> 
> (Updated Feb. 24, 2017, 5:23 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11891:da5745659ea2
> ---
> sim: expand AuxVector class
> 
> The AuxVector class is responsible for holding Process data (in SE Mode
> of course). The data that it holds is normally setup by an OS kernel in
> the process address space. The purpose behind doing this is to pass in
> information that the process will need for various reasons. (Check out
> the enum in the header file for an idea of what the AuxVector holds.)
> 
> The AuxVector struct was changed into a class and encapsulation methods
> were added to protect access to the member variables.
> 
> The host ISA may have a different endianness than the simulated ISA.
> Since data is passed between the process address space and the
> simulator for auxiliary vectors, we need to worry about maintaining
> endianness for the right context.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/aux_vector.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/aux_vector.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/sparc/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/power/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/riscv/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/arm/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/mips/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3835/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 3816: commit 70469eba20cdcf091d66cf2ef463318203c7cc71

2017-02-24 Thread Andreas Sandberg

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

Ship it!



src/arch/arm/kvm/armv8_cpu.cc (line 253)


I don't think you need this. You should be able to just load the value 
straight from kvm into a CPSR-typed variable. E.g.:

  const CPSR cpsr(getOneRegU64(...));
  tc->setMiscRegNoEffect(MISCREG_CPSR, cpsr);
  // set CC regs
  ...


Looks good, thanks for refactoring!

- Andreas Sandberg


On Feb. 23, 2017, 7:17 p.m., Rahul Thakur wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3816/
> ---
> 
> (Updated Feb. 23, 2017, 7:17 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11873:f1d504c8ede4
> ---
> commit 70469eba20cdcf091d66cf2ef463318203c7cc71
> Author: Slava Malyugin 
> Date:   Wed Dec 2 19:01:12 2015 -0800
> 
> arm, kvm: fix saving/restoring conditional flags in ARM KVM64
> 
> The gem5 stores flags separately from other fields CPSR, so we need to
> split them out and recombine on trips to/from KVM.
> 
> Change-Id: I9f0a685f8667c581cdef7d8c234604a3135d9402
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/armv8_cpu.cc ba90ffa751b6 
> 
> Diff: http://reviews.gem5.org/r/3816/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rahul Thakur
> 
>

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

Re: [gem5-dev] Review Request 3827: python: Use PyBind11 instead of SWIG for Python wrappers

2017-02-24 Thread Andreas Sandberg


> On Feb. 23, 2017, 9:37 p.m., Tony Gutierrez wrote:
> > This seems like a welcome change. A question: are there any requirements 
> > for using PyBind besides Python 2.7 or 3.x and the std clibs? I see that 
> > the PyBind GitHub only mentions these dependencies, and I wanted to get 
> > confirmation based on your experiences using it.

There shouldn't be any external dependencies other than Python 2.7/3.x and 
C++11. I have tested it with gcc 4.8 our CI system (RHEL 6.6), gcc 6.2, and 
clang 3.8. I haven't seen any issues other than a weird clang error (possibly a 
clang bug) related to the PyEventDeleter class. I have updated the patch to 
work around that issue.


- Andreas


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


On Feb. 24, 2017, 10:20 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3827/
> ---
> 
> (Updated Feb. 24, 2017, 10:20 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11884:e0f1c63a8440
> ---
> python: Use PyBind11 instead of SWIG for Python wrappers
> 
> Use the PyBind11 wrapping infrastructure instead of SWIG to generate
> wrappers for functionality that needs to be exported to Python. This
> has several benefits:
> 
>   * 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.
> 
> As a part of this change, the mechanism to define exported methods has
> been redesigned slightly. New methods can be exported either by
> declaring them in the SimObject declaration and decorating them with
> the cxxMethod decorator or by adding an instance of
> PyBindMethod/PyBindProperty to the cxx_exports class variable. The
> decorator has the added benefit of making it possible to add a
> docstring and naming the method's parameters.
> 
> The new wrappers has the following known issues:
> 
>   * Global events can't be memory managed correctly. This was the
> case in SWIG as well.
> 
> Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Andreas Hansson 
> Reviewed-by: Andrew Bardsley 
> 
> 
> Diffs
> -
> 
>   src/cpu/BaseCPU.py ba90ffa751b6 
>   src/arch/arm/ArmPMU.py ba90ffa751b6 
>   src/SConscript ba90ffa751b6 
>   src/python/pybind11/stats.cc PRE-CREATION 
>   src/python/swig/core.i ba90ffa751b6 
>   src/python/swig/debug.i ba90ffa751b6 
>   src/python/swig/drain.i ba90ffa751b6 
>   src/python/swig/event.i ba90ffa751b6 
>   src/python/swig/inet.i ba90ffa751b6 
>   src/python/swig/pyevent.hh ba90ffa751b6 
>   src/python/swig/pyevent.cc ba90ffa751b6 
>   src/python/swig/pyobject.hh ba90ffa751b6 
>   src/python/swig/pyobject.cc ba90ffa751b6 
>   src/python/swig/pyobject.i ba90ffa751b6 
>   src/python/swig/range.i ba90ffa751b6 
>   src/python/swig/serialize.i ba90ffa751b6 
>   src/python/swig/stats.i ba90ffa751b6 
>   src/python/swig/time.i ba90ffa751b6 
>   src/python/swig/trace.i ba90ffa751b6 
>   src/sim/Process.py ba90ffa751b6 
>   src/sim/System.py ba90ffa751b6 
>   src/sim/init.hh ba90ffa751b6 
>   src/sim/init.cc ba90ffa751b6 
>   src/sim/power/PowerModel.py ba90ffa751b6 
>   src/sim/power/PowerModelState.py ba90ffa751b6 
>   src/sim/power/ThermalDomain.py ba90ffa751b6 
>   src/sim/power/ThermalModel.py ba90ffa751b6 
>   src/unittest/SConscript ba90ffa751b6 
>   src/unittest/stattest.cc ba90ffa751b6 
>   src/unittest/stattest.i ba90ffa751b6 
>   tests/configs/switcheroo.py ba90ffa751b6 
>   src/cpu/kvm/BaseKvmCPU.py ba90ffa751b6 
>   src/cpu/kvm/X86KvmCPU.py ba90ffa751b6 
>   src/python/SConscript ba90ffa751b6 
>   src/python/_m5/__init__.py ba90ffa751b6 
>   src/python/m5/SimObject.py ba90ffa751b6 
>   src/python/m5/event.py ba90ffa751b6 
>   src/python/m5/internal/params.py ba90ffa751b6 
>   src/python/m5/params.py ba90ffa751b6 
>   src/python/m5/util/pybind.py PRE-CREATION 
>   

Re: [gem5-dev] Review Request 3827: python: Use PyBind11 instead of SWIG for Python wrappers

2017-02-24 Thread Andreas Sandberg

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

(Updated Feb. 24, 2017, 10:20 a.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11884:e0f1c63a8440
---
python: Use PyBind11 instead of SWIG for Python wrappers

Use the PyBind11 wrapping infrastructure instead of SWIG to generate
wrappers for functionality that needs to be exported to Python. This
has several benefits:

  * 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.

As a part of this change, the mechanism to define exported methods has
been redesigned slightly. New methods can be exported either by
declaring them in the SimObject declaration and decorating them with
the cxxMethod decorator or by adding an instance of
PyBindMethod/PyBindProperty to the cxx_exports class variable. The
decorator has the added benefit of making it possible to add a
docstring and naming the method's parameters.

The new wrappers has the following known issues:

  * Global events can't be memory managed correctly. This was the
case in SWIG as well.

Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
Signed-off-by: Andreas Sandberg 
Reviewed-by: Andreas Hansson 
Reviewed-by: Andrew Bardsley 


Diffs (updated)
-

  src/cpu/BaseCPU.py ba90ffa751b6 
  src/arch/arm/ArmPMU.py ba90ffa751b6 
  src/SConscript ba90ffa751b6 
  src/python/pybind11/stats.cc PRE-CREATION 
  src/python/swig/core.i ba90ffa751b6 
  src/python/swig/debug.i ba90ffa751b6 
  src/python/swig/drain.i ba90ffa751b6 
  src/python/swig/event.i ba90ffa751b6 
  src/python/swig/inet.i ba90ffa751b6 
  src/python/swig/pyevent.hh ba90ffa751b6 
  src/python/swig/pyevent.cc ba90ffa751b6 
  src/python/swig/pyobject.hh ba90ffa751b6 
  src/python/swig/pyobject.cc ba90ffa751b6 
  src/python/swig/pyobject.i ba90ffa751b6 
  src/python/swig/range.i ba90ffa751b6 
  src/python/swig/serialize.i ba90ffa751b6 
  src/python/swig/stats.i ba90ffa751b6 
  src/python/swig/time.i ba90ffa751b6 
  src/python/swig/trace.i ba90ffa751b6 
  src/sim/Process.py ba90ffa751b6 
  src/sim/System.py ba90ffa751b6 
  src/sim/init.hh ba90ffa751b6 
  src/sim/init.cc ba90ffa751b6 
  src/sim/power/PowerModel.py ba90ffa751b6 
  src/sim/power/PowerModelState.py ba90ffa751b6 
  src/sim/power/ThermalDomain.py ba90ffa751b6 
  src/sim/power/ThermalModel.py ba90ffa751b6 
  src/unittest/SConscript ba90ffa751b6 
  src/unittest/stattest.cc ba90ffa751b6 
  src/unittest/stattest.i ba90ffa751b6 
  tests/configs/switcheroo.py ba90ffa751b6 
  src/cpu/kvm/BaseKvmCPU.py ba90ffa751b6 
  src/cpu/kvm/X86KvmCPU.py ba90ffa751b6 
  src/python/SConscript ba90ffa751b6 
  src/python/_m5/__init__.py ba90ffa751b6 
  src/python/m5/SimObject.py ba90ffa751b6 
  src/python/m5/event.py ba90ffa751b6 
  src/python/m5/internal/params.py ba90ffa751b6 
  src/python/m5/params.py ba90ffa751b6 
  src/python/m5/util/pybind.py PRE-CREATION 
  src/python/pybind11/core.cc PRE-CREATION 
  src/python/pybind11/debug.cc PRE-CREATION 
  src/python/pybind11/event.cc PRE-CREATION 
  src/python/pybind11/pybind.hh PRE-CREATION 
  src/python/pybind11/pyobject.cc PRE-CREATION 
  SConstruct ba90ffa751b6 
  src/arch/arm/ArmSystem.py ba90ffa751b6 

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


Testing
---

NOTE: I have few cleanup patches that remove SWIG-related stuff from the build 
system and the C++ files. These will be submitted separately if this gets 
approved.


Thanks,

Andreas Sandberg

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

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

2017-02-24 Thread Cron Daemon
* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
CHANGED!
scons: *** [build/ALPHA/encumbered/eio/eio.do] Error 1
scons: *** [build/ALPHA/encumbered/eio/eio.fo] Error 1
scons: *** [build/ALPHA/encumbered/eio/eio.o] Error 1
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: 
passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: 
passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic: passed.
* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic-dummychecker: 
passed.
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: passed.
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-simple:
 passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker: passed.
* build/ARM/tests/opt/quick/se/50.vortex/arm/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: passed.
* build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-atomic: passed.
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-switcheroo-atomic:
 passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: passed.
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic: 
passed.
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing: passed.
*