[gem5-dev] changeset in gem5: gpu-compute: init valid field of GpuTlbEntry ...

[Tony Gutierrez]

changeset 499071baed7b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=499071baed7b
description:
gpu-compute: init valid field of GpuTlbEntry in default ctor

valid field for GpuTlbEntry is not set in the default ctor, which can
lead to strange behavior, and is also flagged by UBSAN.

diffstat:

 src/gpu-compute/gpu_tlb.hh |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 70052ef97ce1 -r 499071baed7b src/gpu-compute/gpu_tlb.hh
--- a/src/gpu-compute/gpu_tlb.hhMon Nov 21 15:37:07 2016 -0500
+++ b/src/gpu-compute/gpu_tlb.hhMon Nov 21 15:38:30 2016 -0500
@@ -68,7 +68,7 @@
 GpuTlbEntry(Addr asn, Addr _vaddr, Addr _paddr, bool _valid)
   : TlbEntry(asn, _vaddr, _paddr, false, false), valid(_valid) { }
 
-GpuTlbEntry() : TlbEntry() { }
+GpuTlbEntry() : TlbEntry(), valid(false) { }
 
 bool valid;
 };
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3741: ruby: add default ctor for MachineID type

[Joe Gross]

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

Ship it!


Ship It!

- Joe Gross


On Nov. 21, 2016, 1:24 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3741/
> ---
> 
> (Updated Nov. 21, 2016, 1:24 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11903:5fc941f6049b
> ---
> ruby: add default ctor for MachineID type
> 
> not all uses of MachineID initialize its fields, so here we add a default
> ctor.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/common/MachineID.hh 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3741/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

Re: [gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

[Joe Gross]

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

Ship it!


Ship It!

- Joe Gross


On Nov. 21, 2016, 4:32 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3742/
> ---
> 
> (Updated Nov. 21, 2016, 4:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:7a987e64e013
> ---
> ruby: Fix overflow reported by ASAN in MessageBuffer.
> 
> In MessageBuffer the m_not_avail_count member is incremented but not used.
> This causes an overflow reported by ASAN. This patch changes from an int to
> Stats::Scalar, since the count is useful in debugging finite MessageBuffers.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/MessageBuffer.hh 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
>   src/mem/ruby/network/MessageBuffer.cc 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3742/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

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

Re: [gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

[Jason Lowe-Power]

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

Ship it!


Ship It!

- Jason Lowe-Power


On Nov. 21, 2016, 10:32 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3742/
> ---
> 
> (Updated Nov. 21, 2016, 10:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:7a987e64e013
> ---
> ruby: Fix overflow reported by ASAN in MessageBuffer.
> 
> In MessageBuffer the m_not_avail_count member is incremented but not used.
> This causes an overflow reported by ASAN. This patch changes from an int to
> Stats::Scalar, since the count is useful in debugging finite MessageBuffers.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/MessageBuffer.hh 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
>   src/mem/ruby/network/MessageBuffer.cc 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3742/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

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

Re: [gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

[Tony Gutierrez]

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

Ship it!


Ship It!

- Tony Gutierrez


On Nov. 21, 2016, 2:32 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3742/
> ---
> 
> (Updated Nov. 21, 2016, 2:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:7a987e64e013
> ---
> ruby: Fix overflow reported by ASAN in MessageBuffer.
> 
> In MessageBuffer the m_not_avail_count member is incremented but not used.
> This causes an overflow reported by ASAN. This patch changes from an int to
> Stats::Scalar, since the count is useful in debugging finite MessageBuffers.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/MessageBuffer.hh 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
>   src/mem/ruby/network/MessageBuffer.cc 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3742/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

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

Re: [gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

[Brad Beckmann]

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

Ship it!


Ship It!

- Brad Beckmann


On Nov. 21, 2016, 10:32 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3742/
> ---
> 
> (Updated Nov. 21, 2016, 10:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:7a987e64e013
> ---
> ruby: Fix overflow reported by ASAN in MessageBuffer.
> 
> In MessageBuffer the m_not_avail_count member is incremented but not used.
> This causes an overflow reported by ASAN. This patch changes from an int to
> Stats::Scalar, since the count is useful in debugging finite MessageBuffers.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/MessageBuffer.hh 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
>   src/mem/ruby/network/MessageBuffer.cc 
> 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3742/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

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

[gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

[Matthew Poremba]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11711:7a987e64e013
---
ruby: Fix overflow reported by ASAN in MessageBuffer.

In MessageBuffer the m_not_avail_count member is incremented but not used.
This causes an overflow reported by ASAN. This patch changes from an int to
Stats::Scalar, since the count is useful in debugging finite MessageBuffers.


Diffs
-

  src/mem/ruby/network/MessageBuffer.hh 
9e5050028323260c6d2211d7158ac4a4145ed8bc 
  src/mem/ruby/network/MessageBuffer.cc 
9e5050028323260c6d2211d7158ac4a4145ed8bc 

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


Testing
---


Thanks,

Matthew Poremba

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

Re: [gem5-dev] Review Request 3739: gpu-compute: init valid field of GpuTlbEntry in default ctor

[Joe Gross]

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

Ship it!


This fixed a ubsan error I was seeing.

- Joe Gross


On Nov. 21, 2016, 12:46 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3739/
> ---
> 
> (Updated Nov. 21, 2016, 12:46 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11902:877b71cb546d
> ---
> gpu-compute: init valid field of GpuTlbEntry in default ctor
> 
> valid field for GpuTlbEntry is not set in the default ctor, which can
> lead to strange behavior, and is also flagged by UBSAN.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/gpu_tlb.hh 9e5050028323260c6d2211d7158ac4a4145ed8bc 
> 
> Diff: http://reviews.gem5.org/r/3739/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

Re: [gem5-dev] Review Request 3721: x86: fix issue with casting in Cvtf2i

[Joe Gross]

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

Ship it!


This fixes some errors I was seeing when running with sanitizers.

- Joe Gross


On Nov. 17, 2016, 2:54 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3721/
> ---
> 
> (Updated Nov. 17, 2016, 2:54 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11892:35849c921444
> ---
> x86: fix issue with casting in Cvtf2i
> 
> UBSAN flags this operation because it detects that arg is being cast directly
> to an unsigned type, argBits. this patch fixes this by first casting the
> value to a signed int type, then reintrepreting the raw bits of the signed
> int into argBits.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/microops/mediaop.isa 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3721/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

Re: [gem5-dev] Review Request 3721: x86: fix issue with casting in Cvtf2i

[Tony Gutierrez]

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


Thoughts? I would like to ship this today.

- Tony Gutierrez


On Nov. 17, 2016, 12:54 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3721/
> ---
> 
> (Updated Nov. 17, 2016, 12:54 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11892:35849c921444
> ---
> x86: fix issue with casting in Cvtf2i
> 
> UBSAN flags this operation because it detects that arg is being cast directly
> to an unsigned type, argBits. this patch fixes this by first casting the
> value to a signed int type, then reintrepreting the raw bits of the signed
> int into argBits.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/microops/mediaop.isa 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3721/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

Re: [gem5-dev] Review Request 3692: gpu-compute: fix segfault when constructing GPUExecContext

[Tony Gutierrez]

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


Any other thoughts? Plan on shipping this today.

- Tony Gutierrez


On Nov. 1, 2016, 3:55 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3692/
> ---
> 
> (Updated Nov. 1, 2016, 3:55 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11889:b236bb4bd2ce
> ---
> gpu-compute: fix segfault when constructing GPUExecContext
> 
> the GPUExecContext context currently stores a reference to its parent WF's
> GPUISA object, however there are some special instructions that do not have
> an associated WF. when these objects are constructed they set their WF pointer
> to null, which causes the GPUExecContext to segfault when trying to 
> dereference
> the WF pointer to get at the WF's GPUISA object. here we change the GPUISA
> reference in the GPUExecContext class to a pointer so that it may be set to
> null.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/gpu_exec_context.hh 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/gpu-compute/gpu_exec_context.cc 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3692/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

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

[gem5-dev] Review Request 3741: ruby: add default ctor for MachineID type

[Tony Gutierrez]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11903:5fc941f6049b
---
ruby: add default ctor for MachineID type

not all uses of MachineID initialize its fields, so here we add a default
ctor.


Diffs
-

  src/mem/ruby/common/MachineID.hh 9e5050028323260c6d2211d7158ac4a4145ed8bc 

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


Testing
---


Thanks,

Tony Gutierrez

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

Re: [gem5-dev] Review Request 3676: syscall_emul: [patch 10/22] refactor fdentry and add fdarray class

[Michael LeBeane]

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



src/sim/process.cc (line 228)


Please add in a warning.



src/sim/process.cc (line 249)


Please add in a warning.



src/sim/syscall_emul.hh (line 989)


I see you added getSimFD() to the base class, but it still looks like you 
have some unnecessary dynamic casts laying around.


- Michael LeBeane


On Nov. 16, 2016, 5:59 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3676/
> ---
> 
> (Updated Nov. 16, 2016, 5:59 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11717:7f3bf41cce5c
> ---
> syscall_emul: [patch 10/22] refactor fdentry and add fdarray class
> 
> Several large changes happen in this patch.
> 
> The FDEntry class is rewritten so that file descriptors now correspond to
> types: 'Regular' which is normal file-backed file with the file open on the
> host machine, 'Pipe' which is a pipe that has been opened on the host machine,
> and 'Device' which does not have an open file on the host yet acts as a pseudo
> device with which to issue ioctls. Other types which might be added in the
> future are directory entries and sockets (off the top of my head).
> 
> The FDArray class was create to hold most of the file descriptor handling
> that was stuffed into the Process class. It uses shared pointers and
> the std::array type to hold the FDEntries mentioned above. The implementation
> could use a review; I feel that there's some room for improvement, but it
> seems like a decent first step.
> 
> The changes to these two classes needed to be propagated out to the rest
> of the code so there were quite a few changes for that. Also, comments were
> added where I thought they were needed to help others and extend our
> DOxygen coverage.
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_entry.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_entry.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/fd_array.hh PRE-CREATION 
>   src/sim/fd_array.cc PRE-CREATION 
>   src/sim/SConscript c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/gpu-compute/cl_driver.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/kern/tru64/tru64.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3676/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 3720: syscall_emul: implement fallocate

[Brandon Potter]

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

(Updated Nov. 21, 2016, 7:20 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11713:4d12929bd03c
---
syscall_emul: implement fallocate


Diffs (updated)
-

  src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 

Diff: http://reviews.gem5.org/r/3720/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 3718: syscall_emul: extend sysinfo system call to include mem_unit

[Jason Lowe-Power]

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

Ship it!


Ship It!

- Jason Lowe-Power


On Nov. 17, 2016, 8:27 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3718/
> ---
> 
> (Updated Nov. 17, 2016, 8:27 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:96f28447a815
> ---
> syscall_emul: extend sysinfo system call to include mem_unit
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3718/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 3718: syscall_emul: extend sysinfo system call to include mem_unit

[Michael LeBeane]

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

Ship it!



src/sim/syscall_emul.hh (line 780)


Why 1?  Comment would be helpful.


- Michael LeBeane


On Nov. 17, 2016, 8:27 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3718/
> ---
> 
> (Updated Nov. 17, 2016, 8:27 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11711:96f28447a815
> ---
> syscall_emul: extend sysinfo system call to include mem_unit
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3718/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 3719: syscall_emul: add support for x86 statfs system calls

[Michael LeBeane]

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

Ship it!


Ship It!

- Michael LeBeane


On Nov. 17, 2016, 8:26 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3719/
> ---
> 
> (Updated Nov. 17, 2016, 8:26 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11712:767b13a252fe
> ---
> syscall_emul: add support for x86 statfs system calls
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/linux.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3719/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

[gem5-dev] Review Request 3740: commit 8606171b2c2e65d0b9931ccb4bd2ebc533c55d60

[Rahul Thakur]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11708:33c0089caa50
---
commit 8606171b2c2e65d0b9931ccb4bd2ebc533c55d60
Author: Rahul Thakur 
Date:   Thu Oct 27 20:36:16 2016 -0700

mem: Refactor CommMonitor stats, add basic atomic mode stats

Change-Id: I978f1155873b3882e16d9cd74e86400efd9c5e3b


Diffs
-

  src/mem/comm_monitor.hh 1d085f66c4ca 
  src/mem/comm_monitor.cc 1d085f66c4ca 

Diff: http://reviews.gem5.org/r/3740/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 3720: syscall_emul: implement fallocate

[Michael LeBeane]

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

Ship it!



src/sim/syscall_emul.cc (line 956)


Newline here.


- Michael LeBeane


On Nov. 17, 2016, 8:25 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3720/
> ---
> 
> (Updated Nov. 17, 2016, 8:25 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11713:f2882a43dda0
> ---
> syscall_emul: implement fallocate
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3720/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 3705: dev: Fix buffer length when unserializing an eth pkt

[Michael LeBeane]

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

(Updated Nov. 21, 2016, 6:57 p.m.)


Review request for Default.


Changes
---

Fix unserialize to support checkpoints created before changeset 11701.


Repository: gem5


Description
---

Changeset 11705:008f04dcc085
---
dev: Fix buffer length when unserializing an eth pkt
Changeset 11701 only serialized the useful portion of of an ethernet packets'
payload.  However, the device models expect each ethernet packet to contain
a 16KB buffer, even if there is no data in it.  This patch adds a 'bufLength'
field to EthPacketData so the original size of the packet buffer can always be
unserialized.

Reported-by: Gabor Dozsa 


Diffs (updated)
-

  src/dev/net/dist_etherlink.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/dist_iface.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/etherlink.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/etherpkt.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/etherpkt.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/i8254xGBe.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/ns_gige.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/pktfifo.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/sinic.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 

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


Testing
---


Thanks,

Michael LeBeane

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

Re: [gem5-dev] Review Request 3717: hsail: disable asserts to allow immediate operands i.e. 0 with loads

[Brandon Potter]

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

(Updated Nov. 21, 2016, 6:52 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11710:96a7b2230a02
---
hsail: disable asserts to allow immediate operands i.e. 0 with loads


Diffs (updated)
-

  src/arch/hsail/operand.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 

Diff: http://reviews.gem5.org/r/3717/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 3738: Ruby: Initialize MessageSizeType of SequencerMsg to Request_Control

[Tony Gutierrez]

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


As this is a simple bug fix, I pushed it out right away. You can close this 
request.

- Tony Gutierrez


On Nov. 18, 2016, 2:20 p.m., Sooraj Puthoor wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3738/
> ---
> 
> (Updated Nov. 18, 2016, 2:20 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11898:7aa1f642586a
> ---
> Ruby: Initialize MessageSizeType of SequencerMsg to Request_Control
> 
> SequencerMsg is autogenerated by slicc scripts and the MessageSizeType is
> initialized to the max enume value by default. The DMASequencer pushes this
> message to the mandatory queue and since the MessageSizeType is unitialized,
> string_to_MessageSizeType() function used by traces to print the message fails
> with a panic. This patch avoids this problem by initializing MessageSizeType 
> of
> SequencerMsg to Request_Control.
> 
> 
> Diffs
> -
> 
>   src/mem/protocol/RubySlicc_Exports.sm 
> 1d085f66c4ca9bb4d4ca58a9f964a2b650f0cd91 
> 
> Diff: http://reviews.gem5.org/r/3738/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sooraj Puthoor
> 
>

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

Re: [gem5-dev] Review Request 3739: gpu-compute: init valid field of GpuTlbEntry in default ctor

[Tony Gutierrez]

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

(Updated Nov. 21, 2016, 10:46 a.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11902:877b71cb546d
---
gpu-compute: init valid field of GpuTlbEntry in default ctor

valid field for GpuTlbEntry is not set in the default ctor, which can
lead to strange behavior, and is also flagged by UBSAN.


Diffs
-

  src/gpu-compute/gpu_tlb.hh 9e5050028323260c6d2211d7158ac4a4145ed8bc 

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


Testing
---


Thanks,

Tony Gutierrez

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

Re: [gem5-dev] Review Request 3727: cpu: disallow speculative update of the conditional branch predictor tables (o3)

[Jason Lowe-Power]

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

Ship it!


Seems reasonable to me, though I'm no branch predictor expert.

- Jason Lowe-Power


On Nov. 18, 2016, 3:14 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3727/
> ---
> 
> (Updated Nov. 18, 2016, 3:14 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> 
> cpu: disallow speculative update of the conditional branch predictor tables 
> (o3)
> 
> The Minor and o3 cpu models share the branch prediction 
> code. Minor relies on the BPredUnit::squash() function 
> to update the branch predictor tables on a branch mispre-
> diction. This is fine because Minor executes in-order, so 
> the update is on the correct path. However, this causes the 
> branch predictor to be updated on out-of-order branch 
> mispredictions when using the o3 model, which should not 
> be the case. 
> 
> This patch guards against speculative update of the branch 
> prediction tables. On a branch misprediction, BPredUnit::squash() 
> calls BpredUnit::update(..., squashed = true). The underlying
> branch predictor tests against the value of squashed. If it is 
> true, it restores any speculatively updated internal state
> it might have (e.g., global/local branch history), then returns. 
> If false, it updates its prediction tables. Previously, exist-
> ing predictors did not test against the "squashed" parameter.
> 
> To accomodate for this change, the Minor model must now call
> BPredUnit::squash() then BPredUnit::update(..., squashed = false)
> on branch mispredictions. Before, calling BpredUnit::squash()
> performed the prediction tables update.
> 
> The effect is a slight MPKI improvement when using the o3
> model. A further patch should perform the same modifications
> for the indirect target predictor and BTB (less critical).
> 
> 
> Diffs
> -
> 
>   src/cpu/minor/fetch2.cc 1d085f66c4ca 
>   src/cpu/pred/2bit_local.hh 1d085f66c4ca 
>   src/cpu/pred/2bit_local.cc 1d085f66c4ca 
>   src/cpu/pred/bi_mode.hh 1d085f66c4ca 
>   src/cpu/pred/bi_mode.cc 1d085f66c4ca 
>   src/cpu/pred/bpred_unit.hh 1d085f66c4ca 
>   src/cpu/pred/bpred_unit.cc 1d085f66c4ca 
>   src/cpu/pred/tournament.hh 1d085f66c4ca 
>   src/cpu/pred/tournament.cc 1d085f66c4ca 
> 
> Diff: http://reviews.gem5.org/r/3727/diff/
> 
> 
> Testing
> ---
> 
> Fast regressions (SE)
> booting Linux (FS)
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

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

[gem5-dev] Review Request 3739: gpu-compute: init valid field of GpuTlbEntry in default ctor

[Tony Gutierrez]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11902:877b71cb546d
---
gpu-compute: init valid field of GpuTlbEntry in default ctor

the default ctor for GpuTlbEntry is not set in the default ctor, which can
lead to strange behavior, and is also flagged by UBSAN.


Diffs
-

  src/gpu-compute/gpu_tlb.hh 9e5050028323260c6d2211d7158ac4a4145ed8bc 

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


Testing
---


Thanks,

Tony Gutierrez

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

Re: [gem5-dev] RISC-V Patches

[stever]

Can I pipe up and tell you I agree? I also think it’s better to get the basic 
support implemented and then expand it incrementally.

Many thanks to Alec for all the effort, and also to Jason for the shepherding.

Steve

From: Jason Lowe-Power
Sent: Monday, November 21, 2016 9:08 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] RISC-V Patches

Hi Alec,

I think it's fine to push without 100% of the possible features working. If
we waited until every possible feature was working we'd never push any
patches ;). Just getting the RISCV support out there and letting others use
it is what's most important, IMO. Others can pipe up and tell me I'm wrong,
though!

Jason

On Mon, Nov 21, 2016 at 11:05 AM Alec Roelke  wrote:

> Hi Jason,
>
> I had removed the tests from the regression patch that fail due to the
> error I pointed out in my initial message because I didn't think it was
> appropriate to include failing tests in a gem5 release, and had planned to
> add them when the bug was fixed.  I'm pretty busy at the moment with
> several deadlines in the next few weeks, so I don't know if I'll be able to
> get to it anytime soon.
>
> Thanks,
> Alec
>
> On Mon, Nov 21, 2016 at 11:31 AM, Jason Lowe-Power 
> wrote:
>
> > Hi Alec,
> >
> > These are ready according to me. Unless someone has an objection, I'll
> push
> > them on Friday (assuming I can get up after all the food on Thursday).
> >
> > Note: All of the tests are passing for me with minor changes in the
> > instruction rates, etc.
> >
> > Thanks again for these patches. I think that this is one of the most
> > important additions to gem5 in a while :).
> >
> > Cheers,
> > Jason
> >
> > On Sun, Nov 20, 2016 at 2:20 PM Alec Roelke  wrote:
> >
> > > Hello Everyone,
> > >
> > > It has been about two weeks since the last review for my 8 RISC-V
> patches
> > > except the 7th patch, so it seems to me like most of them can be
> > > committed?  The patches are:
> > > - 3624 (arch: [Patch 1/5] Added RISC-V base instruction set RV64I)
> > > - 3627 (riscv: [Patch 2/5] Added RISC-V multiply extension RV64M)
> > > - 3628 (riscv: [Patch 3/5] Added RISCV floating point extensions
> RV64FD)
> > > - 3629 (riscv: [Patch 4/5] Added RISC-V atomic memory extension RV64A)
> > > - 3630 (riscv: [Patch 5/5] Added missing support for timing CPU models)
> > > - 3668 (riscv: [Patch 6/5] Improve Linux emulation for RISC-V)
> > > - 3693 (riscv: [Patch 7/5] Corrected LRSC semantics)
> > > - 3694 (riscv: [Patch 8/5] Added some regression tests to RISC-V)
> > >
> > > There is a bug that sometimes occurs with the O3 CPU model where a
> memory
> > > access may cross a cache line boundary (see the first comment chain of
> > > patch 3693) and cause a panic.  I have not encountered this except when
> > > trying to run some of the regression tests I made for patch 3694 on O3.
> > It
> > > would make the most sense to change patch 3624 to fix it, but since
> that
> > > would delay shipping it, I think it would be better to make a new
> patch.
> > >
> > > 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

Re: [gem5-dev] Review Request 3714: hsail: add a wavesize case statement to register operand code

[Brandon Potter]

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

(Updated Nov. 21, 2016, 6:34 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11707:856f37d405e4
---
hsail: add a wavesize case statement to register operand code


Diffs (updated)
-

  src/arch/hsail/operand.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 

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


Testing
---


Thanks,

Brandon Potter

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

Re: [gem5-dev] Patches of TAGE branch predictor

[Arthur Perais]

I suppose it was called by the InOrder CPU once upon a time. Now the 
Minor CPU uses the same branch prediction code as the o3 CPU, which may 
have led to the current inconsistencies in how branch predictors handle 
out-of-order mispredictions (or not :)).


I've submitted a patch regarding this recently 
(http://reviews.gem5.org/r/3727/), feel free to take a look.


Arthur.


Le 21/11/2016 à 16:40, Jason Lowe-Power a écrit :

Hi Fernando,

I don't know what he original use of predictInOrder was, but you're right,
it doesn't look like it's in use now. You may be able to figure out what it
was used for by inferring its function from the code.

Jason

On Sun, Nov 13, 2016 at 2:37 PM Jason Lowe-Power 
wrote:


Hi Fernando,

I have no idea, off the top of my head. I'd have to look into the code
and/or the history of the file to figure it out.

I'm busy with an ISCA submission right now, but I can find time to look
into this in a week or so.

Cheers,
Jason

On Sun, Nov 13, 2016 at 2:26 PM Fernando Endo 
wrote:

Hi Jason,

I've been working a bit on the integration, and I wondered what is and
where this method is used:

BPredUnit::predictInOrder()

I greped the source and built code and did not find a calling point.

Thanks,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France


2016-11-06 21:38 GMT+01:00 Jason Lowe-Power :


Hi Fernando,

Yes, it seems like a good idea to include a TAGE predictor in gem5.

Please

make patches and post them to the reviewboard. We welcome the

contribution.

Additionally, I believe there was a recent email about a possible bug

when

updating the branch predictor state on a mis-speculation. If you're
familiar with this code, or know of a fix for this, we would appreciate a
patch. Or, if it's actually not broken, that would be great, too. It's

part

of the code that I'm not very familiar with.

Cheers,
Jason

On Fri, Nov 4, 2016 at 9:46 AM Fernando Endo 
wrote:

Hello all,

I'd like to know if the gem5 community would like to have a TAGE branch
prediction in gem5.
In my branch it seems to be working, so if you give me a positive

feedback

I may spend some spare time to rebase and test the patch over mainstream.

More specifically, I took the CBP2016 winner and removed local prediction
tables. This specific version is called TAGE-GSC (Global Statistical
Corrector) and should go to src/cpu/pred/tage-gsc.hh. This file is
functionally equivalent to the original CBP2016 winner and can be

compared

against it without modification. Then, a glue code was implemented in
src/cpu/pred/TAGE.hh and src/cpu/pred/TAGE.cc, making tage-gsc.hh to work
in gem5.

I validated the gem5 implementation by comparing the predictor at fetch
with a validator at commit. The prediction tables must be the same.

Regards,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France
___
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

Re: [gem5-dev] Review Request 3693: riscv: [Patch 7/5] Corrected LRSC semantics

[Tony Gutierrez]

> On Nov. 2, 2016, 12:38 p.m., Alec Roelke wrote:
> > This doesn't work with the O3 CPU model; I wrote a simple program that 
> > performs a lr.w followed by sc.w that works with the atomic-simple, 
> > timing-simple, and minor CPU models, but with the O3 model I get this error:
> > 
> > gem5.debug: build/RISCV/mem/cache/cache.cc\:162: void 
> > Cache::satisfyRequest(PacketPtr, CacheBlk*, bool, bool): Assertion 
> > `pkt->getOffset(blkSize) + pkt->getSize() <= blkSize' failed.
> > 
> > I can't seem to track down what's causing the error.  Can anybody help me?
> 
> Ali Saidi wrote:
> the issue is that the ld + st crosses a cache line which the O3 doesn't 
> support doing this type of op when it spans two cache lines because you have 
> to track both of them.
> 
> Alec Roelke wrote:
> I see.  It sounds like fixing it would require making changes to the O3 
> model itself, is that right?  Are there changes I can make within the scope 
> of this patch, or others in the series, that will make it work?  This may 
> actually explain other errors I'm getting with the O3 model with some of the 
> other tests I'm making.
> 
> Tony Gutierrez wrote:
> I'm not sure if you would need to necessarily modify the O3 model much, 
> if at all. Certainly you will need to have your memory instructions detect an 
> access that will cross a cache line boundary, split it into two, and track 
> both. Then you will only consider it completed when both reqs get responses. 
> This is done in a few other places in the model.
> 
> Alec Roelke wrote:
> Can you point me to where this is done?  I don't see it in any of the 
> ISAs I checked.  From what I can tell, it should be easy enough to split a 
> memory request into two, and for readMemAtomic reconstructing the results 
> should be fairly easy, but even if calling readMemTiming twice in a single 
> LoadInitiateAcc worked and created two corresponding LoadCompleteAccs, it 
> doesn't seem to be possible to reconstruct the data that was read from those 
> two LoadCompleteAccs.  Would I have to use micro-ops?

Take a look at the splitRequest() methods in the BaseDynInst class and how this 
interacts with the O3 model, I think it is a good starting point.


- Tony


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


On Nov. 20, 2016, 11:51 a.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3693/
> ---
> 
> (Updated Nov. 20, 2016, 11:51 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11694:d650c7e96464
> ---
> riscv: [Patch 7/5] Corrected LRSC semantics
> 
> RISC-V makes use of load-reserved and store-conditional instructions to
> enable creation of lock-free concurrent data manipulation as well as
> ACQUIRE and RELEASE semantics for memory ordering of LR, SC, and AMO
> instructions (the latter of which do not follow LR/SC semantics). This
> patch is a correction to patch 4, which added these instructions to the
> implementation of RISC-V. It modifies locked_mem.hh and the
> implementations of lr.w, sc.w, lr.d, and sc.d to apply the proper gem5
> flags and return the proper values.
> 
> An important difference between gem5's LLSC semantics and RISC-V's LR/SC
> ones, beyond the name, is that gem5 uses 0 to indicate failure and 1 to
> indicate success, while RISC-V is the opposite. Strictly speaking, RISC-V
> uses 0 to indicate success and nonzero to indicate failure where the
> value would indicate the error, but currently only 1 is reserved as a
> failure code by the ISA reference.
> 
> This is the seventh patch in the series which originally consisted of five
> patches that added the RISC-V ISA to gem5. The original five patches added
> all of the instructions and added support for more detailed CPU models and
> the sixth patch corrected the implementations of Linux constants and
> structs. There will be an eighth patch that adds some regression tests
> for the instructions.
> 
> [Removed some commented-out code from locked_mem.hh.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   src/arch/riscv/isa/decoder.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/mem.isa PRE-CREATION 
>   src/arch/riscv/locked_mem.hh PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3693/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

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

Re: [gem5-dev] RISC-V Patches

[Alec Roelke]

Hi Jason,

I had removed the tests from the regression patch that fail due to the
error I pointed out in my initial message because I didn't think it was
appropriate to include failing tests in a gem5 release, and had planned to
add them when the bug was fixed.  I'm pretty busy at the moment with
several deadlines in the next few weeks, so I don't know if I'll be able to
get to it anytime soon.

Thanks,
Alec

On Mon, Nov 21, 2016 at 11:31 AM, Jason Lowe-Power 
wrote:

> Hi Alec,
>
> These are ready according to me. Unless someone has an objection, I'll push
> them on Friday (assuming I can get up after all the food on Thursday).
>
> Note: All of the tests are passing for me with minor changes in the
> instruction rates, etc.
>
> Thanks again for these patches. I think that this is one of the most
> important additions to gem5 in a while :).
>
> Cheers,
> Jason
>
> On Sun, Nov 20, 2016 at 2:20 PM Alec Roelke  wrote:
>
> > Hello Everyone,
> >
> > It has been about two weeks since the last review for my 8 RISC-V patches
> > except the 7th patch, so it seems to me like most of them can be
> > committed?  The patches are:
> > - 3624 (arch: [Patch 1/5] Added RISC-V base instruction set RV64I)
> > - 3627 (riscv: [Patch 2/5] Added RISC-V multiply extension RV64M)
> > - 3628 (riscv: [Patch 3/5] Added RISCV floating point extensions RV64FD)
> > - 3629 (riscv: [Patch 4/5] Added RISC-V atomic memory extension RV64A)
> > - 3630 (riscv: [Patch 5/5] Added missing support for timing CPU models)
> > - 3668 (riscv: [Patch 6/5] Improve Linux emulation for RISC-V)
> > - 3693 (riscv: [Patch 7/5] Corrected LRSC semantics)
> > - 3694 (riscv: [Patch 8/5] Added some regression tests to RISC-V)
> >
> > There is a bug that sometimes occurs with the O3 CPU model where a memory
> > access may cross a cache line boundary (see the first comment chain of
> > patch 3693) and cause a panic.  I have not encountered this except when
> > trying to run some of the regression tests I made for patch 3694 on O3.
> It
> > would make the most sense to change patch 3624 to fix it, but since that
> > would delay shipping it, I think it would be better to make a new patch.
> >
> > 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] ReviewBoard full text search

[Jason Lowe-Power]

Hi all,

Is there any reason we don't have full text search enabled on reviewboard?
Did we accidentally overlook it, or does it strain our server too much?
Something else?

https://www.reviewboard.org/docs/manual/dev/users/searching/full-text-search/

I've been bitten many time by knowing something was posted to reviewboard,
but I've been unable to find it easily.

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

Re: [gem5-dev] RISC-V Patches

[Jason Lowe-Power]

Hi Alec,

These are ready according to me. Unless someone has an objection, I'll push
them on Friday (assuming I can get up after all the food on Thursday).

Note: All of the tests are passing for me with minor changes in the
instruction rates, etc.

Thanks again for these patches. I think that this is one of the most
important additions to gem5 in a while :).

Cheers,
Jason

On Sun, Nov 20, 2016 at 2:20 PM Alec Roelke  wrote:

> Hello Everyone,
>
> It has been about two weeks since the last review for my 8 RISC-V patches
> except the 7th patch, so it seems to me like most of them can be
> committed?  The patches are:
> - 3624 (arch: [Patch 1/5] Added RISC-V base instruction set RV64I)
> - 3627 (riscv: [Patch 2/5] Added RISC-V multiply extension RV64M)
> - 3628 (riscv: [Patch 3/5] Added RISCV floating point extensions RV64FD)
> - 3629 (riscv: [Patch 4/5] Added RISC-V atomic memory extension RV64A)
> - 3630 (riscv: [Patch 5/5] Added missing support for timing CPU models)
> - 3668 (riscv: [Patch 6/5] Improve Linux emulation for RISC-V)
> - 3693 (riscv: [Patch 7/5] Corrected LRSC semantics)
> - 3694 (riscv: [Patch 8/5] Added some regression tests to RISC-V)
>
> There is a bug that sometimes occurs with the O3 CPU model where a memory
> access may cross a cache line boundary (see the first comment chain of
> patch 3693) and cause a panic.  I have not encountered this except when
> trying to run some of the regression tests I made for patch 3694 on O3.  It
> would make the most sense to change patch 3624 to fix it, but since that
> would delay shipping it, I think it would be better to make a new patch.
>
> 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] Patches of TAGE branch predictor

[Jason Lowe-Power]

Hi Fernando,

I don't know what he original use of predictInOrder was, but you're right,
it doesn't look like it's in use now. You may be able to figure out what it
was used for by inferring its function from the code.

Jason

On Sun, Nov 13, 2016 at 2:37 PM Jason Lowe-Power 
wrote:

> Hi Fernando,
>
> I have no idea, off the top of my head. I'd have to look into the code
> and/or the history of the file to figure it out.
>
> I'm busy with an ISCA submission right now, but I can find time to look
> into this in a week or so.
>
> Cheers,
> Jason
>
> On Sun, Nov 13, 2016 at 2:26 PM Fernando Endo 
> wrote:
>
> Hi Jason,
>
> I've been working a bit on the integration, and I wondered what is and
> where this method is used:
>
> BPredUnit::predictInOrder()
>
> I greped the source and built code and did not find a calling point.
>
> Thanks,
>
> --
> Fernando A. Endo, Post-doc
>
> INRIA Rennes-Bretagne Atlantique
> France
>
>
> 2016-11-06 21:38 GMT+01:00 Jason Lowe-Power :
>
> > Hi Fernando,
> >
> > Yes, it seems like a good idea to include a TAGE predictor in gem5.
> Please
> > make patches and post them to the reviewboard. We welcome the
> contribution.
> >
> > Additionally, I believe there was a recent email about a possible bug
> when
> > updating the branch predictor state on a mis-speculation. If you're
> > familiar with this code, or know of a fix for this, we would appreciate a
> > patch. Or, if it's actually not broken, that would be great, too. It's
> part
> > of the code that I'm not very familiar with.
> >
> > Cheers,
> > Jason
> >
> > On Fri, Nov 4, 2016 at 9:46 AM Fernando Endo 
> > wrote:
> >
> > Hello all,
> >
> > I'd like to know if the gem5 community would like to have a TAGE branch
> > prediction in gem5.
> > In my branch it seems to be working, so if you give me a positive
> feedback
> > I may spend some spare time to rebase and test the patch over mainstream.
> >
> > More specifically, I took the CBP2016 winner and removed local prediction
> > tables. This specific version is called TAGE-GSC (Global Statistical
> > Corrector) and should go to src/cpu/pred/tage-gsc.hh. This file is
> > functionally equivalent to the original CBP2016 winner and can be
> compared
> > against it without modification. Then, a glue code was implemented in
> > src/cpu/pred/TAGE.hh and src/cpu/pred/TAGE.cc, making tage-gsc.hh to work
> > in gem5.
> >
> > I validated the gem5 implementation by comparing the predictor at fetch
> > with a validator at commit. The prediction tables must be the same.
> >
> > Regards,
> >
> > --
> > Fernando A. Endo, Post-doc
> >
> > INRIA Rennes-Bretagne Atlantique
> > France
> > ___
> > 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] Status of RISC-V patches

[Jason Lowe-Power]

Hi Andreas,

I don't think it's surprising, but I like this idea. I think it's much more
maintainable going forward than what we've been doing.

Does this have any bearing on the RISC-V patches? I was hoping we would be
able to get Alec's stuff pushed in soon. I don't want to hold things up for
perfection, especially since it seems a number of people have been asking
of RISC-V support.

Thanks,
Jason

On Mon, Nov 14, 2016 at 4:40 PM Andreas Hansson 
wrote:

> Hi all,
>
> Merely a thought when it comes to adding tests:
>
> I would suggest we ditch all proprietary/closed-source tests and move in
> the direction of something that is open and maintained. My proposal would
> be to adopt a few of the tests from the llvm test suite. There are both
> very short LLVM-specific tests that are BSD licensed, and a bunch of
> smaller “apps” that maintain their original license. It would be great if
> we could identify a few relevant tests from the tests suite and start
> going in that direction. The source for the tests along with build scripts
> etc should probably be in a repo on their own.
>
> What do you think?
>
> Andreas
>
> On 28/10/2016, 22:12, "gem5-dev on behalf of Alec Roelke"
>  wrote:
>
> >I think I get it.  Thanks for your help!
> >
> >It looks like I won't be able to make use of any tests other than
> >00.hello,
> >because either they're multithreaded or pieces of them are missing.  I'm
> >going to try to put my instruction tests into 02.insttest.
> >
> >On Fri, Oct 28, 2016 at 11:01 AM, Jason Lowe-Power 
> >wrote:
> >
> >> Hi Alec,
> >>
> >> Our regression testing infrastructure is confusing, to say the least.
> >> Honestly, it would take me at least a few hours to figure out how to add
> >> new regressions again. But here's a little information that hopefully
> >>will
> >> help you save some time.
> >>
> >> You need to put reference outputs in tests/quick/se/ >> NAME>/ref/riscv/linux/.
> >>
> >> The config files are in tests/configs. One of these files (without the
> >> .py) is what goes in  above. The  can be
> >> anything. Using some of the same tests that are there make sense, but
> >>you
> >> may want to add other RISC-V specific tests as well.
> >>
> >> You *may* be able to use the config files in tests/configs without
> >> changes, but maybe not. I'm not sure. You'll probably be able to use
> >>some
> >> but not others.
> >>
> >> Getting scons to run your regressions is totally black magic to me.
> >>Here's
> >> a couple of things I've learned, though.
> >> 1) You should delete the build directory (e.g., build/RISCV/tests/
> >> debug/quick/se/00.hello/riscv/) every time you want to re-run the
> >> regression.
> >> 2) The regression won't even try to run if you don't have dummy files in
> >> tests/quick/se//ref/riscv/linux/.
> >>
> >> For the missing stats/changed stats, since this is first time you're
> >> running the RISC-V stats, I would totally ignore all of that
> >>information. I
> >> would just look at the output (simout/simerr) and make sure it seems
> >> reasonable (e.g., no errors). If you have an idea of a stat that you
> >>expect
> >> to see (e.g., floating point ops > 0) then you could look at the stats
> >>file
> >> too to make sure it's what you expect.
> >>
> >> There's no specific configuration you should be using. For the most
> >>part,
> >> all of the tests are just functional tests. The configurations for the
> >> system are specified in the tests/configs () Python
> >>files.
> >>
> >> Hopefully this will help you get started. Let us know if you have more
> >> questions. Maybe someone with more regression tester experience will be
> >> able to help more.
> >>
> >> Jason
> >>
> >> On Thu, Oct 27, 2016 at 8:23 PM Alec Roelke  wrote:
> >>
> >>> I'll start with converting as many from "quick" as I can.  If/when I
> >>>end
> >>> up creating my own, is there a convention for what they should be
> >>>named and
> >>> where they should go?
> >>>
> >>> Also, I'm having a bit of a problem with just 00.hello.  I compiled the
> >>> source in tests/test-progs/hello/src into
> >>>tests/test-progs/hello/bin/riscv/linux
> >>> (for some reason mine disappeared), and then created
> >>> tests/quick/se/00.hello/ref/riscv/linux/simple-atomic.  Then I compiled
> >>> and ran build/RISCV/gem5.fast, configuring for the atomic CPU and
> >>> redirecting the output stats, configuration, stdout, and stderr into
> >>>that
> >>> directory.  But when I run build/RISCV/tests/debug/quick/
> >>> se/00.hello/riscv/linux/simple-atomic, it claims that it couldn't find
> >>> several stats and that it found several other unexpected ones in
> >>>stats.txt
> >>> (and completely ignored the other files).  Is there some other
> >>> configuration I should be using to generate the output for the
> >>>regression?
> >>> Actually, better yet, is there a way for me to figure out what the
> >>> 

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

[Cron Daemon]

* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 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/o3-timing: 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/simple-atomic: 
passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: passed.
 * build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: 
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_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 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/o3-timing: passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: 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-two-level:
 passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 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/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 passed.
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: 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/50.vortex/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/70.twolf/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/10.mcf/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
passed.
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: 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.
*