Re: [gem5-dev] Review Request 3696: syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess simulations

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Feb. 23, 2017, 7:40 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3696/
> ---
> 
> (Updated Feb. 23, 2017, 7:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11879:5e2d3ce3a08c
> ---
> syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
> simulations
> 
> Modifies the clone system call and adds execve system call. Requires allowing
> processes to steal thread contexts from other processes in the same system
> object and the ability to detach pieces of process state (such as MemState)
> to allow dynamic sharing.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/linux/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/alpha/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/arm/linux/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/arm/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/generic/types.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/mips/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/power/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/riscv/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/sparc/linux/syscalls.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/sparc/process.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/sparc/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/linux/process.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/linux/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/process.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/arch/x86/types.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/cpu/checker/thread_context.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/cpu/o3/thread_context.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/cpu/simple_thread.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/cpu/thread_context.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/cpu/thread_state.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/mem/page_table.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/mem/page_table.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/mem/se_translating_port_proxy.hh 
> 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/Process.py 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/fd_array.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/fd_array.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/process.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/process.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/syscall_desc.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/syscall_emul.hh 5ea85692a53ea437c95e5a199884bd3a5266f820 
>   src/sim/syscall_emul.cc 5ea85692a53ea437c95e5a199884bd3a5266f820 
> 
> Diff: http://reviews.gem5.org/r/3696/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 3785: sim, kvm: make KvmVM a System parameter

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3785/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> sim, kvm: make KvmVM a System parameter
> 
> A KVM VM is typically a child of the System object already, but for
> solving future issues with configuration graph resolution, the most
> logical way to keep track of this object is for it to be an actual
> parameter of the System object.
> 
> Change-Id: I965ded22203ff8667db9ca02de0042ff1c772220
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/KvmGic.py 97eebddaae84 
>   src/arch/arm/kvm/gic.cc 97eebddaae84 
>   src/cpu/kvm/BaseKvmCPU.py 97eebddaae84 
>   src/cpu/kvm/KvmVM.py 97eebddaae84 
>   src/cpu/kvm/base.cc 97eebddaae84 
>   src/cpu/kvm/vm.hh 97eebddaae84 
>   src/cpu/kvm/vm.cc 97eebddaae84 
>   src/sim/System.py 97eebddaae84 
>   src/sim/system.hh 97eebddaae84 
>   src/sim/system.cc 97eebddaae84 
>   configs/example/fs.py 97eebddaae84 
>   configs/example/se.py 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3785/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3785: sim, kvm: make KvmVM a System parameter

[Alexandru Dutu]

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



src/sim/system.cc (line 98)
<http://reviews.gem5.org/r/3785/#comment7943>

Sorry, I should have been more specific. I meant by not conditioning 
System.kvm_vm by USE_KVM in System.py and have it be nullptr if KVM is not 
present we can get rid of some #if USE_KVM in the C++ code.


- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3785/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> sim, kvm: make KvmVM a System parameter
> 
> A KVM VM is typically a child of the System object already, but for
> solving future issues with configuration graph resolution, the most
> logical way to keep track of this object is for it to be an actual
> parameter of the System object.
> 
> Change-Id: I965ded22203ff8667db9ca02de0042ff1c772220
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/KvmGic.py 97eebddaae84 
>   src/arch/arm/kvm/gic.cc 97eebddaae84 
>   src/cpu/kvm/BaseKvmCPU.py 97eebddaae84 
>   src/cpu/kvm/KvmVM.py 97eebddaae84 
>   src/cpu/kvm/base.cc 97eebddaae84 
>   src/cpu/kvm/vm.hh 97eebddaae84 
>   src/cpu/kvm/vm.cc 97eebddaae84 
>   src/sim/System.py 97eebddaae84 
>   src/sim/system.hh 97eebddaae84 
>   src/sim/system.cc 97eebddaae84 
>   configs/example/fs.py 97eebddaae84 
>   configs/example/se.py 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3785/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3788: arm, kvm: remove KvmGic

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3788/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm, kvm: remove KvmGic
> 
> KvmGic functionality has been subsumed within the new MuxingKvmGic
> model, which has Pl390 fallback when not using KVM for fast emulation.
> This simplifies configuration and will enable checkpointing between
> KVM emulation and full-system simulation.
> 
> Change-Id: Ie61251720064c512843015c075e4ac419a4081e8
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/KvmGic.py 97eebddaae84 
>   src/arch/arm/kvm/gic.hh 97eebddaae84 
>   src/arch/arm/kvm/gic.cc 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3788/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3784: sim,kvm,arm: fix typos

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3784/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> sim,kvm,arm: fix typos
> 
> Change-Id: Ifc65d42eebfd109c1c622c82c3c3b3e523819e85
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/gic.hh 97eebddaae84 
>   src/dev/arm/gic_pl390.hh 97eebddaae84 
>   src/dev/arm/gic_pl390.cc 97eebddaae84 
>   src/sim/System.py 97eebddaae84 
>   src/sim/system.hh 97eebddaae84 
>   src/sim/system.cc 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3784/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3766: tests: check for gem5 binary before tests

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Dec. 15, 2016, 4:51 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3766/
> ---
> 
> (Updated Dec. 15, 2016, 4:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> tests: check for gem5 binary before tests
> 
> Provides a helpful error when tests.py is invoked without the gem5 binary.
> 
> Before:
> Running 0 tests
> 
> After:
> gem5 binary 'quick/...' not an executable file
> 
> Change-Id: I1566802206c9e21ca89bd03e91db22844168a085
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   tests/tests.py 78ef8daecd81de0c392034809b3bc155396bf983 
> 
> Diff: http://reviews.gem5.org/r/3766/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3787: arm, kvm: Automatically use the MuxingKvmGic

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3787/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm, kvm: Automatically use the MuxingKvmGic
> 
> Automatically use the MuxingKvmGic in the VExpress_GEM5_V1
> platform. This removes the need to patch the host kernel or the
> platform configuration when using KVM on ARM.
> 
> Change-Id: Ib1ed9b3b849b80c449ef1b62b83748f3f54ada26
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   src/dev/arm/RealView.py 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3787/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3785: sim, kvm: make KvmVM a System parameter

[Alexandru Dutu]

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



src/sim/system.cc (line 98)
<http://reviews.gem5.org/r/3785/#comment7940>

It seems we don't need #if here, p->kvm_vm will be nullptr in case there is 
no initialization from python. Right?


- Alexandru Dutu


On Jan. 17, 2017, 10:04 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3785/
> ---
> 
> (Updated Jan. 17, 2017, 10:04 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> sim, kvm: make KvmVM a System parameter
> 
> A KVM VM is typically a child of the System object already, but for
> solving future issues with configuration graph resolution, the most
> logical way to keep track of this object is for it to be an actual
> parameter of the System object.
> 
> Change-Id: I965ded22203ff8667db9ca02de0042ff1c772220
> Reviewed-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/KvmGic.py 97eebddaae84 
>   src/arch/arm/kvm/gic.cc 97eebddaae84 
>   src/cpu/kvm/BaseKvmCPU.py 97eebddaae84 
>   src/cpu/kvm/KvmVM.py 97eebddaae84 
>   src/cpu/kvm/base.cc 97eebddaae84 
>   src/cpu/kvm/vm.hh 97eebddaae84 
>   src/cpu/kvm/vm.cc 97eebddaae84 
>   src/sim/System.py 97eebddaae84 
>   src/sim/system.hh 97eebddaae84 
>   src/sim/system.cc 97eebddaae84 
>   configs/example/fs.py 97eebddaae84 
>   configs/example/se.py 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3785/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3670: syscall_emul: [patch 4/22] remove redundant M5_pid field from process

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 17, 2016, 3:14 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3670/
> ---
> 
> (Updated Oct. 17, 2016, 3:14 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11692:ba60e4ae816f
> ---
> syscall_emul: [patch 4/22] remove redundant M5_pid field from process
> 
> 
> Diffs
> -
> 
>   src/sim/system.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/system.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/Process.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3670/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 3721: x86: fix issue with casting in Cvtf2i

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Nov. 17, 2016, 8: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, 8: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 3700: syscall_emul: [PATCH 19/22] adds basic signaling mechanism to SE mode

[Alexandru Dutu]

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



src/sim/se_signal.hh (line 45)
<http://reviews.gem5.org/r/3700/#comment7850>

This should not have an underscore, also why not just use signal?


- Alexandru Dutu


On Nov. 16, 2016, 4:36 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3700/
> ---
> 
> (Updated Nov. 16, 2016, 4:36 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11728:85a344df47dd
> ---
> syscall_emul: [PATCH 19/22] adds basic signaling mechanism to SE mode
> 
> 
> Diffs
> -
> 
>   src/sim/system.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/se_signal.hh PRE-CREATION 
>   src/sim/se_signal.cc PRE-CREATION 
>   src/sim/SConscript c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3700/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 3706: style: local variable name correction

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Nov. 16, 2016, 4:24 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3706/
> ---
> 
> (Updated Nov. 16, 2016, 4:24 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11726:71d4b80b78ab
> ---
> style: local variable name correction
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3706/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 3702: syscall_emul: [PATCH 21/22] rewrite code related to system call exits

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Nov. 16, 2016, 4:44 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3702/
> ---
> 
> (Updated Nov. 16, 2016, 4:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11730:9ee83d124c9c
> ---
> syscall_emul: [PATCH 21/22] rewrite code related to system call exits
> 
> The changeset refactors exit, exit_group, and futex related exit
> functionality.
> 
> 
> Diffs
> -
> 
>   src/sim/system.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/futex_map.hh PRE-CREATION 
>   src/sim/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3702/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 3699: syscall_emul: [PATCH 18/22] refactor and add functionality for dup, dup2, and pipe

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Nov. 7, 2016, 10:09 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3699/
> ---
> 
> (Updated Nov. 7, 2016, 10:09 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:01d31dbe35c4
> ---
> syscall_emul: [PATCH 18/22] refactor and add functionality for dup, dup2, and 
> pipe
> 
> 
> Diffs
> -
> 
>   src/arch/arm/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_emul.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_emul.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3699/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 3701: syscall_emul: [PATCH 20/22] add the tgkill system call

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Nov. 14, 2016, 8:56 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3701/
> ---
> 
> (Updated Nov. 14, 2016, 8:56 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11727:33fae597297e
> ---
> syscall_emul: [PATCH 20/22] add the tgkill system call
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3701/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 3696: syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess simulations

[Alexandru Dutu]

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



src/mem/page_table.cc (line 110)
<http://reviews.gem5.org/r/3696/#comment7809>

Ranged for can be used here.



src/sim/process.hh (lines 77 - 82)
<http://reviews.gem5.org/r/3696/#comment7804>

These are not following the naming conventions, they should not contain 
underscore.



src/sim/process.cc (line 143)
<http://reviews.gem5.org/r/3696/#comment7805>

Does memState need to be dynamically allocated?



src/sim/process.cc (line 249)
<http://reviews.gem5.org/r/3696/#comment7806>

Ranged for can be used here.



src/sim/syscall_emul.hh (line 1214)
<http://reviews.gem5.org/r/3696/#comment7807>

Should these commented lines be removed?



src/sim/syscall_emul.hh (line 1762)
<http://reviews.gem5.org/r/3696/#comment7808>

Ranged for will work here as well.


- Alexandru Dutu


On Nov. 14, 2016, 8:37 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3696/
> ---
> 
> (Updated Nov. 14, 2016, 8:37 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11722:6fea3eedd891
> ---
> syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
> simulations
> 
> Modifies the clone system call and adds execve system call. Requires allowing
> processes to steal thread contexts from other processes in the same system
> object and the ability to detach pieces of process state (such as MemState)
> to allow dynamic sharing.
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_desc.hh PRE-CREATION 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/page_table.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/se_translating_port_proxy.hh 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/Process.py c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/thread_state.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/page_table.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/o3/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/simple_thread.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/types.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/checker/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/linux/syscalls.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/mips/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/power/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/arm/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/generic/types.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/arm/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3696/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 3646: gpu-compute, hsail: call discardFetch() from the WF

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 7, 2016, 8:53 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3646/
> ---
> 
> (Updated Oct. 7, 2016, 8:53 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11676:28636ac9878f
> ---
> gpu-compute, hsail: call discardFetch() from the WF
> 
> because every taken branch causes fetch to be discarded, we move the call
> to the WF to avoid to have to call it from each and every branch instruction
> type.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/insts/branch.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/wavefront.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
> 
> Diff: http://reviews.gem5.org/r/3646/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 3652: gpu-compute: use the GPUISA object to advance the PC

[Alexandru Dutu]

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

Ship it!



src/gpu-compute/fetch_unit.cc (line 282)
<http://reviews.gem5.org/r/3652/#comment7696>

This should go away when we will fetch directly from memory.


- Alexandru Dutu


On Oct. 10, 2016, 6:24 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3652/
> ---
> 
> (Updated Oct. 10, 2016, 6:24 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11679:5695d76ec68b
> ---
> gpu-compute: use the GPUISA object to advance the PC
> 
> the GPU model treats the PC as a pointer to individual instruction objects -
> which are store in a contiguous array - and not a byte address to be fetched
> from the real memory system. this is ok for HSAIL because all instructions are
> considered by the model to be the same size.
> 
> in machine ISA, however, instructions may be 32b or 64b, and branches are
> calculated by advancing the PC by the number of words (4 byte chunks) it
> needs to advance in the real instruction stream. because of this there is
> a mismatch between the PC we use to index into the instruction array, and
> the actual byte address PC the ISA expects. here we move the PC advance
> calculation to the ISA so that differences in the instrucion sizes may be
> accounted for in generic way.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/fetch_unit.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/wavefront.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
> 
> Diff: http://reviews.gem5.org/r/3652/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 3655: gpu-compute, hsail: make the PC a byte address, not an instruction index

[Alexandru Dutu]

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

Ship it!


Looks good to me.

- Alexandru Dutu


On Oct. 10, 2016, 6:34 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3655/
> ---
> 
> (Updated Oct. 10, 2016, 6:34 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11680:b7ba41787b5d
> ---
> gpu-compute, hsail: make the PC a byte address, not an instruction index
> 
> currently the PC is incremented on an instruction granularity, and not as an
> instruction's byte address. machine ISA instructions assume the PC is a byte
> address, and is incremented accordingly. here we make the GPU model, and the
> HSAIL instructions treat the PC as a byte address as well.
> 
> 
> Diffs
> -
> 
>   src/arch/hsail/gpu_isa.hh PRE-CREATION 
>   src/arch/hsail/gpu_types.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/arch/hsail/insts/branch.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/arch/hsail/insts/gpu_static_inst.hh 
> 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/cl_driver.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/fetch_unit.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/gpu_static_inst.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/gpu_static_inst.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/hsail_code.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/kernel_cfg.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/kernel_cfg.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
> 
> Diff: http://reviews.gem5.org/r/3655/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 3658: gpu-compute: support in-order data delivery in GM pipe

[Alexandru Dutu]

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

Ship it!


Neat refactoring! Other than the python arg name, this looks good to me.


configs/example/apu_se.py (line 156)
<http://reviews.gem5.org/r/3658/#comment7691>

Shouldn't we stick to the dash naming style instead of camel case?



src/gpu-compute/global_memory_pipeline.hh 
<http://reviews.gem5.org/r/3658/#comment7690>

Neat fix! The next two methods should also go away, however that is not 
something to be considered for this patch.


- Alexandru Dutu


On Oct. 10, 2016, 11:51 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3658/
> ---
> 
> (Updated Oct. 10, 2016, 11:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11683:e48e281afdd8
> ---
> gpu-compute: support in-order data delivery in GM pipe
> 
> this patch adds an ordered response buffer to the GM pipeline
> to ensure in-order data delivery. the buffer is implemented as
> a stl ordered map, which sorts the request in program order by
> using their sequence ID. when requests return to the GM pipeline
> they are marked as done. only the oldest request may be serviced
> from the ordered buffer, and only if is marked as done.
> 
> the FIFO response buffers are kept and used in OoO delivery mode
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/GPU.py 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/compute_unit.cc 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/global_memory_pipeline.hh 
> 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/gpu-compute/global_memory_pipeline.cc 
> 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   configs/example/apu_se.py 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/arch/hsail/insts/decl.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/arch/hsail/insts/mem_impl.hh 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
>   src/arch/hsail/insts/pseudo_inst.cc 
> 220fa4099b9a91526b8a1828f27cf1a9f3c15837 
> 
> Diff: http://reviews.gem5.org/r/3658/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 3679: style: [patch 12/22] fix preliminary style issues for subsequent fault patch

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 17, 2016, 4:11 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3679/
> ---
> 
> (Updated Oct. 17, 2016, 4:11 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11700:db830c773c2d
> ---
> style: [patch 12/22] fix preliminary style issues for subsequent fault patch
> 
> This changeset add spaces in a few spots and removes an unnecessary comment.
> 
> 
> Diffs
> -
> 
>   src/sim/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3679/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 3671: syscall_emul: [patch 5/22] remove LiveProcess class and use Process instead

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 19, 2016, 7:27 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3671/
> ---
> 
> (Updated Oct. 19, 2016, 7:27 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11694:c915cc7cff42
> ---
> syscall_emul: [patch 5/22] remove LiveProcess class and use Process instead
> 
> The EIOProcess class was removed recently and it was the only other class
> which derived from Process. Since every Process invocation is also a
> LiveProcess invocation, it makes sense to simplify the who organization
> by combining the fields from LiveProcess into Process.
> 
> 
> Diffs
> -
> 
>   configs/common/cpu2000.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/example/apu_se.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/example/se.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/learning_gem5/part1/simple.py 
> 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/learning_gem5/part1/two_level.py 
> 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/splash2/cluster.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   configs/splash2/run.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/tru64/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/tru64/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/freebsd/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/freebsd/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/mips/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/mips/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/mips/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/mips/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/linux/syscalls.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/solaris/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/solaris/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/gpu-compute/cl_driver.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/gpu-compute/cl_driver.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/freebsd/freebsd.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/linux/linux.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/linux/linux.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/operatingsystem.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/operatingsystem.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/tru64/tru64.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/Process.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/emul_driver.hh 4a86763c0b30cccba0f56

Re: [gem5-dev] Review Request 3675: syscall_emul: [patch 9/22] remove unused global variable (num_processes)

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 17, 2016, 3:25 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3675/
> ---
> 
> (Updated Oct. 17, 2016, 3:25 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11697:e818bb00b9ea
> ---
> syscall_emul: [patch 9/22] remove unused global variable (num_processes)
> 
> 
> Diffs
> -
> 
>   src/arch/sparc/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3675/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 3672: syscall_emul: [patch 6/22] remove unused fields from Process class

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 17, 2016, 3:19 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3672/
> ---
> 
> (Updated Oct. 17, 2016, 3:19 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11694:ebff480ad584
> ---
> syscall_emul: [patch 6/22] remove unused fields from Process class
> 
> It looks like tru64 has some nxm* system calls, but the two fields that
> are defined in the Process class are unused by any of the code. There doesn't
> appear to be any reference in the tru64 code.
> 
> 
> Diffs
> -
> 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3672/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 3670: syscall_emul: [patch 4/22] remove redundant M5_pid field from process

[Alexandru Dutu]

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



src/sim/process.cc 
<http://reviews.gem5.org/r/3670/#comment7629>

Even if we are serializing nextPid in the System object, shouldn't we still 
serialize _pid? We might need to have the same pids restored and not reassign 
different ones.



src/sim/process.cc 
<http://reviews.gem5.org/r/3670/#comment7630>

Same goes for unserialization.


- Alexandru Dutu


On Oct. 17, 2016, 3:14 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3670/
> ---
> 
> (Updated Oct. 17, 2016, 3:14 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11692:ba60e4ae816f
> ---
> syscall_emul: [patch 4/22] remove redundant M5_pid field from process
> 
> 
> Diffs
> -
> 
>   src/sim/system.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/system.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/Process.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/alpha/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3670/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 3662: syscall_emul: [patch 2/22] move SyscallDesc into its own .hh and .cc

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 17, 2016, 3:08 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3662/
> ---
> 
> (Updated Oct. 17, 2016, 3:08 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11690:4bd82b7d3c09
> ---
> syscall_emul: [patch 2/22] move SyscallDesc into its own .hh and .cc
> 
> The class was crammed into syscall_emul.hh which has tons of forward
> declarations and template definitions. To clean it up a bit, moved the
> class into separate files and commented the class with doxygen style
> comments. Also, provided some encapsulation by adding some accessors and
> a mutator.
> 
> The syscallreturn.hh file was renamed syscall_return.hh to make it consistent
> with other similarly named files in the src/sim directory.
> 
> The DPRINTF_SYSCALL macro was moved into its own header file with the
> include the Base and Verbose flags as well.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/freebsd/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/arm/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/mips/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/power/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/linux/syscalls.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/sparc/solaris/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/kern/tru64/tru64.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/SConscript 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_debug_macros.hh PRE-CREATION 
>   src/sim/syscall_desc.hh PRE-CREATION 
>   src/sim/syscall_desc.cc PRE-CREATION 
>   src/sim/syscall_emul.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscall_emul.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 
>   src/sim/syscallreturn.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 
> 
> Diff: http://reviews.gem5.org/r/3662/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 3644: gpu-compute: remove inst enums and use bit flag for attributes

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 6, 2016, 2:14 a.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3644/
> ---
> 
> (Updated Oct. 6, 2016, 2:14 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11663:8d1c14f262e9
> ---
> gpu-compute: remove inst enums and use bit flag for attributes
> 
> this patch removes the GPUStaticInst enums that were defined in GPU.py. 
> instead,
> a simple set of attribute flags that can be set in the base instruction class
> are used. this will help unify the attributes of HSAIL and other possible ISA
> instructions within the model itself.
> 
> because the static instrution now carries the attributes, a GPUDynInst
> must carry a pointer to a valid GPUStaticInst so a new static kernel launch
> instruction is added, which carries the attributes needed to perform a
> the kernel launch.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/kernel_cfg.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/lds_state.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/lds_state.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/gpu_static_inst.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/gpu_static_inst.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/wavefront.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/local_memory_pipeline.cc 
> b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/shader.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/vector_register_file.cc 
> b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/SConscript b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/generic_types.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/generic_types.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/branch.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/decl.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/main.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/mem.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/mem.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/mem_impl.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/hsail/insts/pseudo_inst.cc 
> b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/GPU.py b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/GPUStaticInstFlags.py PRE-CREATION 
>   src/gpu-compute/SConscript b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/code_enums.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/compute_unit.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/compute_unit.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/global_memory_pipeline.cc 
> b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/gpu_dyn_inst.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/gpu-compute/gpu_dyn_inst.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
> 
> Diff: http://reviews.gem5.org/r/3644/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 3643: style: reduce include dependencies in some headers

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Oct. 5, 2016, 4:27 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3643/
> ---
> 
> (Updated Oct. 5, 2016, 4:27 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11660:1c76ab8bafec
> ---
> style: reduce include dependencies in some headers
> 
> 
> Diffs
> -
> 
>   src/arch/x86/system.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/tlb.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/tlb.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/utility.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/utility.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/kern/linux/linux.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/kern/linux/linux.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/mem/multi_level_page_table.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/mem/multi_level_page_table_impl.hh 
> b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/mem/page_table.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/mem/page_table.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/arguments.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/process.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/process.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/sim_object.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/sim_object.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/syscall_emul.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/sim/syscall_emul.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/generic/tlb.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/power/interrupts.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/pagetable.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/pagetable.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/pseudo_inst.cc b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
>   src/arch/x86/system.hh b29aca3fcb75f5ad92429001ab11c65b2f9635b0 
> 
> Diff: http://reviews.gem5.org/r/3643/diff/
> 
> 
> Testing
> ---
> 
> util/regress
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

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

[gem5-dev] changeset in gem5: misc: Adds a warning in case gdb is attached ...

[Alexandru Dutu]

changeset 370d69b00fcf in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=370d69b00fcf
description:
misc: Adds a warning in case gdb is attached multiple times
Instead of scheduling another event, this patch adds a warning in case 
gdb
is attached multiple times and the first attachement event has not been
processed yet.

diffstat:

 src/base/remote_gdb.cc |  6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diffs (16 lines):

diff -r 5fad5a37d6fc -r 370d69b00fcf src/base/remote_gdb.cc
--- a/src/base/remote_gdb.ccTue Oct 04 13:03:52 2016 -0400
+++ b/src/base/remote_gdb.ccTue Oct 04 13:04:19 2016 -0400
@@ -249,6 +249,12 @@
 void
 BaseRemoteGDB::InputEvent::process(int revent)
 {
+if (gdb->trapEvent.scheduled()) {
+warn("GDB trap event has already been scheduled! "
+ "Ignoring this input event.");
+return;
+}
+
 if (revent & POLLIN) {
 gdb->trapEvent.type(SIGILL);
 gdb->scheduleInstCommitEvent(&gdb->trapEvent, 0);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: kvm: Adding details to kvm page fault in x86

[Alexandru Dutu]

changeset b29aca3fcb75 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b29aca3fcb75
description:
kvm: Adding details to kvm page fault in x86
Adding details, e.g. rip, rsp etc. to the kvm pagefault exit when in SE 
mode.

diffstat:

 src/arch/x86/pseudo_inst.cc |  21 +++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diffs (40 lines):

diff -r 370d69b00fcf -r b29aca3fcb75 src/arch/x86/pseudo_inst.cc
--- a/src/arch/x86/pseudo_inst.cc   Tue Oct 04 13:04:19 2016 -0400
+++ b/src/arch/x86/pseudo_inst.cc   Tue Oct 04 13:06:05 2016 -0400
@@ -29,8 +29,10 @@
  */
 
 #include "arch/x86/pseudo_inst.hh"
+#include "arch/x86/system.hh"
 #include "debug/PseudoInst.hh"
 #include "sim/process.hh"
+#include "sim/system.hh"
 
 using namespace X86ISA;
 
@@ -62,8 +64,23 @@
 
 Process *p = tc->getProcessPtr();
 if (!p->fixupStackFault(tc->readMiscReg(MISCREG_CR2))) {
-panic("Page fault at %#x ", tc->readMiscReg(MISCREG_CR2));
-}
+SETranslatingPortProxy proxy = tc->getMemProxy();
+// at this point we should have 6 values on the interrupt stack
+int size = 6;
+uint64_t is[size];
+// reading the interrupt handler stack
+proxy.readBlob(ISTVirtAddr + PageBytes - size*sizeof(uint64_t),
+   (uint8_t *)&is, sizeof(is));
+panic("Page fault at addr %#x\n\tInterrupt handler stack:\n"
+"\tss: %#x\n"
+"\trsp: %#x\n"
+"\trflags: %#x\n"
+"\tcs: %#x\n"
+"\trip: %#x\n"
+"\terr_code: %#x\n",
+tc->readMiscReg(MISCREG_CR2),
+is[5], is[4], is[3], is[2], is[1], is[0]);
+   }
 }
 
 } // namespace X86ISA
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: gpu-compute: Added method to compute the actu...

[Alexandru Dutu]

changeset 5fad5a37d6fc in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5fad5a37d6fc
description:
gpu-compute: Added method to compute the actual workgroup size
This patch adds a method to the Wavefront class to compute the actual 
workgroup
size. This can be different from the maximum workgroup size specified 
when
launching the kernel through the NDRange object. Current solution is 
still not
optimal, as we are computing these for each wavefront and the 
dispatcher also
needs to have this information and can't actually call
Wavefront::computeActuallWgSz before the wavefronts are being created. 
A long
term solution would be to have a Workgroup class that deals with all 
these
details.

diffstat:

 src/gpu-compute/compute_unit.cc |  48 +++-
 src/gpu-compute/compute_unit.hh |   6 ++--
 src/gpu-compute/wavefront.cc|  11 +
 src/gpu-compute/wavefront.hh|   6 +
 4 files changed, 38 insertions(+), 33 deletions(-)

diffs (183 lines):

diff -r 02a0c6b9c057 -r 5fad5a37d6fc src/gpu-compute/compute_unit.cc
--- a/src/gpu-compute/compute_unit.cc   Tue Oct 04 15:44:52 2016 +0100
+++ b/src/gpu-compute/compute_unit.cc   Tue Oct 04 13:03:52 2016 -0400
@@ -174,7 +174,7 @@
 }
 
 void
-ComputeUnit::FillKernelState(Wavefront *w, NDRange *ndr)
+ComputeUnit::fillKernelState(Wavefront *w, NDRange *ndr)
 {
 w->resizeRegFiles(ndr->q.cRegCount, ndr->q.sRegCount, ndr->q.dRegCount);
 
@@ -190,6 +190,7 @@
 w->spillSizePerItem = ndr->q.spillMemPerItem;
 w->roBase = ndr->q.roMemStart;
 w->roSize = ndr->q.roMemTotal;
+w->computeActualWgSz(ndr);
 }
 
 void
@@ -220,19 +221,16 @@
 
 
 void
-ComputeUnit::StartWF(Wavefront *w, int trueWgSize[], int trueWgSizeTotal,
- int waveId, LdsChunk *ldsChunk, NDRange *ndr)
+ComputeUnit::startWavefront(Wavefront *w, int waveId, LdsChunk *ldsChunk,
+NDRange *ndr)
 {
 static int _n_wave = 0;
 
-// Fill in Kernel state
-FillKernelState(w, ndr);
-
 VectorMask init_mask;
 init_mask.reset();
 
 for (int k = 0; k < wfSize(); ++k) {
-if (k + waveId * wfSize() < trueWgSizeTotal)
+if (k + waveId * wfSize() < w->actualWgSzTotal)
 init_mask[k] = 1;
 }
 
@@ -241,18 +239,18 @@
 w->initMask = init_mask.to_ullong();
 
 for (int k = 0; k < wfSize(); ++k) {
-w->workItemId[0][k] = (k + waveId * wfSize()) % trueWgSize[0];
-w->workItemId[1][k] =
-((k + waveId * wfSize()) / trueWgSize[0]) % trueWgSize[1];
-w->workItemId[2][k] =
-(k + waveId * wfSize()) / (trueWgSize[0] * trueWgSize[1]);
+w->workItemId[0][k] = (k + waveId * wfSize()) % w->actualWgSz[0];
+w->workItemId[1][k] = ((k + waveId * wfSize()) / w->actualWgSz[0]) %
+ w->actualWgSz[1];
+w->workItemId[2][k] = (k + waveId * wfSize()) /
+  (w->actualWgSz[0] * w->actualWgSz[1]);
 
-w->workItemFlatId[k] = w->workItemId[2][k] * trueWgSize[0] *
-trueWgSize[1] + w->workItemId[1][k] * trueWgSize[0] +
+w->workItemFlatId[k] = w->workItemId[2][k] * w->actualWgSz[0] *
+w->actualWgSz[1] + w->workItemId[1][k] * w->actualWgSz[0] +
 w->workItemId[0][k];
 }
 
-w->barrierSlots = divCeil(trueWgSizeTotal, wfSize());
+w->barrierSlots = divCeil(w->actualWgSzTotal, wfSize());
 
 w->barCnt.resize(wfSize(), 0);
 
@@ -294,8 +292,8 @@
 // is this the last wavefront in the workgroup
 // if set the spillWidth to be the remaining work-items
 // so that the vector access is correct
-if ((waveId + 1) * wfSize() >= trueWgSizeTotal) {
-w->spillWidth = trueWgSizeTotal - (waveId * wfSize());
+if ((waveId + 1) * wfSize() >= w->actualWgSzTotal) {
+w->spillWidth = w->actualWgSzTotal - (waveId * wfSize());
 } else {
 w->spillWidth = wfSize();
 }
@@ -328,17 +326,6 @@
 injectGlobalMemFence(gpuDynInst, true);
 }
 
-// Get true size of workgroup (after clamping to grid size)
-int trueWgSize[3];
-int trueWgSizeTotal = 1;
-
-for (int d = 0; d < 3; ++d) {
-trueWgSize[d] = std::min(ndr->q.wgSize[d], ndr->q.gdSize[d] -
- ndr->wgId[d] * ndr->q.wgSize[d]);
-
-trueWgSizeTotal *= trueWgSize[d];
-}
-
 // calculate the number of 32-bit vector registers required by wavefront
 int vregDemand = ndr->q.sRegCount + (2 * ndr->q.dRegCount);
 int wave_id = 0;
@@ -350,9 +337,10 @@
 // It must be stopped and not waiting
 // for a release to complete S_RETURNING
 if (w->status == Wavefront::S_STOPPED) {
+fillKernelState(w, ndr);
 // if we have scheduled all work items then stop
 // scheduling wavefronts
-if (wave_id * wfSize() >= trueWgSizeTotal)
+ 

Re: [gem5-dev] Review Request 3635: misc: Adds a warning in case gdb is attached multiple times

[Alexandru Dutu]

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

(Updated Oct. 3, 2016, 7:49 p.m.)


Review request for Default.


Summary (updated)
-

misc: Adds a warning in case gdb is attached multiple times


Repository: gem5


Description (updated)
---

Changeset 11654:46ce6e3222ec
---
misc: Adds a warning in case gdb is attached multiple times
Instead of scheduling another event, this patch adds a warning in case gdb
is attached multiple times and the first attachement event has not been
processed yet.


Diffs (updated)
-

  src/base/remote_gdb.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---

Regressions pass.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 3635: gdb: Adds a warning in case gdb is attached multiple times

[Alexandru Dutu]

> On Oct. 3, 2016, 11:06 a.m., Andreas Sandberg wrote:
> > Wouldn't it make more sense to just disallow multiple GDB clients to be 
> > attached at the same time?

This does not make sense to me as one can run a configuration with multiple, 
different processes. For example: threadContext A will be executing process 1 
and threadContext B will be executing process 2. In this case 2 gdb listeners 
will be instantiated and each will be listening on a different port. Imho, 
having multiple GDB clients is a neat feature.


- Alexandru


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


On Oct. 3, 2016, 5:41 a.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3635/
> ---
> 
> (Updated Oct. 3, 2016, 5:41 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11654:5cc5f694f938
> ---
> gdb: Adds a warning in case gdb is attached multiple times
> Instead of scheduling another event, this patch adds a warning in case gdb
> is attached multiple times and the first attachement event has not been
> processed yet.
> 
> 
> Diffs
> -
> 
>   src/base/remote_gdb.cc 2c111e634da005e2b78981fadd0368662454f2ed 
> 
> Diff: http://reviews.gem5.org/r/3635/diff/
> 
> 
> Testing
> ---
> 
> Regressions pass.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 3636: kvm: Adding details to kvm page fault in x86

[Alexandru Dutu]

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

(Updated Oct. 3, 2016, 5:42 a.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 11655:c4ea7a1c5818
---
kvm: Adding details to kvm page fault in x86
Adding details, e.g. rip, rsp etc. to the kvm pagefault exit when in SE mode.

# Node ID 54da9967f9cbb368f5aeb036a716c29edfe0efde
# Parent 7fae74a89c2c4d2e459817cedc75921ba7d52660


Diffs
-

  src/arch/x86/pseudo_inst.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing (updated)
---

Regressions pass.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 3635: gdb: Adds a warning in case gdb is attached multiple times

[Alexandru Dutu]

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

(Updated Oct. 3, 2016, 5:41 a.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 11654:5cc5f694f938
---
gdb: Adds a warning in case gdb is attached multiple times
Instead of scheduling another event, this patch adds a warning in case gdb
is attached multiple times and the first attachement event has not been
processed yet.


Diffs
-

  src/base/remote_gdb.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing (updated)
---

Regressions pass.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 3634: gpu-compute: Added method to compute the actual workgroup size

[Alexandru Dutu]

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

(Updated Oct. 3, 2016, 5:40 a.m.)


Review request for Default.


Summary (updated)
-

gpu-compute: Added method to compute the actual workgroup size


Repository: gem5


Description (updated)
---

Changeset 11653:beaa9af9fada
---
gpu-compute: Added method to compute the actual workgroup size
This patch adds a method to the Wavefront class to compute the actual workgroup
size. This can be different from the maximum workgroup size specified when
launching the kernel through the NDRange object. Current solution is still not
optimal, as we are computing these for each wavefront and the dispatcher also
needs to have this information and can't actually call
Wavefront::computeActuallWgSz before the wavefronts are being created. A long
term solution would be to have a Workgroup class that deals with all these
details.


Diffs (updated)
-

  src/gpu-compute/wavefront.cc 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/compute_unit.hh 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/compute_unit.cc 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/wavefront.hh 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing (updated)
---

Regressions pass.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 3637: mem: Functional page tables data structure change

[Alexandru Dutu]

> On Sept. 27, 2016, 10:17 p.m., Andreas Hansson wrote:
> > Surely an unordered_map also only allows a single entry per key.

Correct! This patch actually replaced

typedef m5::hash_map PTable;
with
typedef std::map PTable;

The problem was m5::hash_map was implemented as a multimap which holds multiple 
values for the same key.
However, your commit:

changeset:   11168:f98eb2da15a4
user:Andreas Hansson 
date:Mon Oct 12 04:07:59 2015 -0400
summary: misc: Remove redundant compiler-specific defines

changed typedef m5::hash_map PTable; to typedef 
std::unordered_map PTable; which does not hold multiple 
values for one key.
Therefore, there is no need for this patch.


- Alexandru


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


On Sept. 27, 2016, 10:11 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3637/
> ---
> 
> (Updated Sept. 27, 2016, 10:11 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11656:82d65f294a37
> ---
> mem: Functional page tables data structure change
> This patch changes the inner data structure of the functional page table from
> a std::unodereded_map, which allows duplicates, to a std::map, which does not.
> 
> 
> Diffs
> -
> 
>   src/mem/page_table.hh 2c111e634da005e2b78981fadd0368662454f2ed 
> 
> Diff: http://reviews.gem5.org/r/3637/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 3636: kvm: Adding details to kvm page fault in x86

[Alexandru Dutu]

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

(Updated Sept. 27, 2016, 10:49 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11655:c4ea7a1c5818
---
kvm: Adding details to kvm page fault in x86
Adding details, e.g. rip, rsp etc. to the kvm pagefault exit when in SE mode.

# Node ID 54da9967f9cbb368f5aeb036a716c29edfe0efde
# Parent 7fae74a89c2c4d2e459817cedc75921ba7d52660


Diffs (updated)
-

  src/arch/x86/pseudo_inst.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 3637: mem: Functional page tables data structure change

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11656:82d65f294a37
---
mem: Functional page tables data structure change
This patch changes the inner data structure of the functional page table from
a std::unodereded_map, which allows duplicates, to a std::map, which does not.


Diffs
-

  src/mem/page_table.hh 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 3636: kvm: Adding details to kvm page fault in x86

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11655:c0850056746d
---
kvm: Adding details to kvm page fault in x86
Adding details, e.g. rip, rsp etc. to the kvm pagefault exit when in SE mode.

# Node ID 54da9967f9cbb368f5aeb036a716c29edfe0efde
# Parent 7fae74a89c2c4d2e459817cedc75921ba7d52660


Diffs
-

  src/arch/x86/pseudo_inst.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 3635: gdb: Adds a warning in case gdb is attached multiple times

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11654:5cc5f694f938
---
gdb: Adds a warning in case gdb is attached multiple times
Instead of scheduling another event, this patch adds a warning in case gdb
is attached multiple times and the first attachement event has not been
processed yet.


Diffs
-

  src/base/remote_gdb.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 3634: gpu: Added method to compute the actual workgroup size

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11653:1f9f2cff588d
---
gpu: Added method to compute the actual workgroup size
This patch adds a method to the Wavefront class to compute the actual workgroup
size. This can be different from the maximum workgroup size specified when
launching the kernel through the NDRange object. Current solution is still not
optimal, as we are computing these for each wavefront and the dispatcher also
needs to have this information and can't actually call
Wavefront::computeActuallWgSz before the wavefronts are being created. A long
term solution would be to have a Workgroup class that deals with all these
details.


Diffs
-

  src/gpu-compute/compute_unit.hh 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/compute_unit.cc 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/wavefront.hh 2c111e634da005e2b78981fadd0368662454f2ed 
  src/gpu-compute/wavefront.cc 2c111e634da005e2b78981fadd0368662454f2ed 

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


Testing
---


Thanks,

Alexandru Dutu

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

[gem5-dev] changeset in gem5: hsail: Fix disassembly of load instruction wi...

[Alexandru Dutu]

changeset 44ca2fc730eb in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=44ca2fc730eb
description:
hsail: Fix disassembly of load instruction with 3 destination operands

diffstat:

 src/arch/hsail/insts/mem_impl.hh |  9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diffs (19 lines):

diff -r d426728892fe -r 44ca2fc730eb src/arch/hsail/insts/mem_impl.hh
--- a/src/arch/hsail/insts/mem_impl.hh  Fri Sep 16 12:32:36 2016 -0400
+++ b/src/arch/hsail/insts/mem_impl.hh  Fri Sep 16 12:36:20 2016 -0400
@@ -93,6 +93,15 @@
  this->dest_vect[1].disassemble(),
  this->addr.disassemble());
 break;
+  case 3:
+this->disassembly = csprintf("%s_%s_%s (%s,%s,%s), %s", 
this->opcode,
+ segmentNames[this->segment],
+ MemDataType::label,
+ this->dest_vect[0].disassemble(),
+ this->dest_vect[1].disassemble(),
+ this->dest_vect[2].disassemble(),
+ this->addr.disassemble());
+break;
   case 4:
 this->disassembly = csprintf("%s_%s_%s (%s,%s,%s,%s), %s",
  this->opcode,
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: gpu-compute: Adding context serialization met...

[Alexandru Dutu]

changeset d426728892fe in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d426728892fe
description:
gpu-compute: Adding context serialization methods to Wavefront
This patch adds methods to serialize the context of a particular 
wavefront
to the simulated system memory. Context serialization is used when a 
wavefront
is preempeted (i.e. context switch).

diffstat:

 src/gpu-compute/wavefront.cc |  125 +++
 src/gpu-compute/wavefront.hh |   12 
 2 files changed, 137 insertions(+), 0 deletions(-)

diffs (154 lines):

diff -r 42a1873be45c -r d426728892fe src/gpu-compute/wavefront.cc
--- a/src/gpu-compute/wavefront.cc  Fri Sep 16 12:31:46 2016 -0400
+++ b/src/gpu-compute/wavefront.cc  Fri Sep 16 12:32:36 2016 -0400
@@ -941,3 +941,128 @@
sizeof(privBase) + sizeof(spillBase) + sizeof(ldsChunk) +
computeUnit->wfSize() * sizeof(ReconvergenceStackEntry);
 }
+
+void
+Wavefront::getContext(const void *out)
+{
+uint8_t *iter = (uint8_t *)out;
+for (int i = 0; i < barCnt.size(); i++) {
+*(int *)iter = barCnt[i]; iter += sizeof(barCnt[i]);
+}
+*(int *)iter = wfId; iter += sizeof(wfId);
+*(int *)iter = maxBarCnt; iter += sizeof(maxBarCnt);
+*(int *)iter = oldBarrierCnt; iter += sizeof(oldBarrierCnt);
+*(int *)iter = barrierCnt; iter += sizeof(barrierCnt);
+*(int *)iter = computeUnit->cu_id; iter += sizeof(computeUnit->cu_id);
+*(uint32_t *)iter = wgId; iter += sizeof(wgId);
+*(uint32_t *)iter = barrierId; iter += sizeof(barrierId);
+*(uint64_t *)iter = initMask.to_ullong(); iter += 
sizeof(initMask.to_ullong());
+*(Addr *)iter = privBase; iter += sizeof(privBase);
+*(Addr *)iter = spillBase; iter += sizeof(spillBase);
+
+int stackSize = reconvergenceStack.size();
+ReconvergenceStackEntry empty = {std::numeric_limits::max(),
+std::numeric_limits::max(),
+std::numeric_limits::max()};
+for (int i = 0; i < workItemId[0].size(); i++) {
+if (i < stackSize) {
+*(ReconvergenceStackEntry *)iter = *reconvergenceStack.back();
+iter += sizeof(ReconvergenceStackEntry);
+reconvergenceStack.pop_back();
+} else {
+*(ReconvergenceStackEntry *)iter = empty;
+iter += sizeof(ReconvergenceStackEntry);
+}
+}
+
+int wf_size = computeUnit->wfSize();
+for (int i = 0; i < maxSpVgprs; i++) {
+uint32_t vgprIdx = remap(i, sizeof(uint32_t), 1);
+for (int lane = 0; lane < wf_size; lane++) {
+uint32_t regVal = computeUnit->vrf[simdId]->
+read(vgprIdx,lane);
+*(uint32_t *)iter = regVal; iter += sizeof(regVal);
+}
+}
+
+for (int i = 0; i < maxDpVgprs; i++) {
+uint32_t vgprIdx = remap(i, sizeof(uint64_t), 1);
+for (int lane = 0; lane < wf_size; lane++) {
+uint64_t regVal = computeUnit->vrf[simdId]->
+read(vgprIdx,lane);
+*(uint64_t *)iter = regVal; iter += sizeof(regVal);
+}
+}
+
+for (int i = 0; i < condRegState->numRegs(); i++) {
+for (int lane = 0; lane < wf_size; lane++) {
+uint64_t regVal = condRegState->read(i, lane);
+*(uint64_t *)iter = regVal; iter += sizeof(regVal);
+}
+}
+
+/* saving LDS content */
+if (ldsChunk)
+for (int i = 0; i < ldsChunk->size(); i++) {
+char val = ldsChunk->read(i);
+*(char *) iter = val; iter += sizeof(val);
+}
+}
+
+void
+Wavefront::setContext(const void *in)
+{
+uint8_t *iter = (uint8_t *)in;
+for (int i = 0; i < barCnt.size(); i++) {
+barCnt[i] = *(int *)iter; iter += sizeof(barCnt[i]);
+}
+wfId = *(int *)iter; iter += sizeof(wfId);
+maxBarCnt = *(int *)iter; iter += sizeof(maxBarCnt);
+oldBarrierCnt = *(int *)iter; iter += sizeof(oldBarrierCnt);
+barrierCnt = *(int *)iter; iter += sizeof(barrierCnt);
+computeUnit->cu_id = *(int *)iter; iter += sizeof(computeUnit->cu_id);
+wgId = *(uint32_t *)iter; iter += sizeof(wgId);
+barrierId = *(uint32_t *)iter; iter += sizeof(barrierId);
+initMask = VectorMask(*(uint64_t *)iter); iter += sizeof(initMask);
+privBase = *(Addr *)iter; iter += sizeof(privBase);
+spillBase = *(Addr *)iter; iter += sizeof(spillBase);
+
+for (int i = 0; i < workItemId[0].size(); i++) {
+ReconvergenceStackEntry newEntry = *(ReconvergenceStackEntry *)iter;
+iter += sizeof(ReconvergenceStackEntry);
+if (newEntry.pc != std::numeric_limits::max()) {
+pushToReconvergenceStack(newEntry.pc, newEntry.rpc,
+ newEntry.execMask);
+}
+}
+int wf_size = computeUnit->wfSize();
+
+for (int i = 0; i < maxSpVgprs; i++) {
+uint32_t vgprIdx = rema

[gem5-dev] changeset in gem5: gpu-compute: Adding vector register file debu...

[Alexandru Dutu]

changeset 46cffde5d8a6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=46cffde5d8a6
description:
gpu-compute: Adding vector register file debug messages
This patch introduces DPRINTFs for reading and writing to and from the 
vector
register file.

diffstat:

 src/gpu-compute/SConscript  |  4 +++-
 src/gpu-compute/vector_register_file.hh |  3 +++
 2 files changed, 6 insertions(+), 1 deletions(-)

diffs (45 lines):

diff -r a9f0711e7230 -r 46cffde5d8a6 src/gpu-compute/SConscript
--- a/src/gpu-compute/SConscriptFri Sep 16 12:29:01 2016 -0400
+++ b/src/gpu-compute/SConscriptFri Sep 16 12:30:05 2016 -0400
@@ -89,6 +89,7 @@
 DebugFlag('GPUReg')
 DebugFlag('GPUSync')
 DebugFlag('GPUTLB')
+DebugFlag('GPUVRF')
 DebugFlag('HSALoader')
 DebugFlag('HSAIL')
 DebugFlag('HSAILObject')
@@ -96,4 +97,5 @@
 DebugFlag('WavefrontStack')
 
 CompoundFlag('GPUALL', ['GPUCoalescer', 'GPUDisp', 'GPUExec', 'GPUFetch',
-'GPUMem', 'GPUPort', 'GPUSync', 'GPUTLB', 'HSAIL'])
+'GPUMem', 'GPUPort', 'GPUSync', 'GPUTLB', 'HSAIL',
+'GPUVRF'])
diff -r a9f0711e7230 -r 46cffde5d8a6 src/gpu-compute/vector_register_file.hh
--- a/src/gpu-compute/vector_register_file.hh   Fri Sep 16 12:29:01 2016 -0400
+++ b/src/gpu-compute/vector_register_file.hh   Fri Sep 16 12:30:05 2016 -0400
@@ -40,6 +40,7 @@
 
 #include "base/statistics.hh"
 #include "base/types.hh"
+#include "debug/GPUVRF.hh"
 #include "gpu-compute/vector_register_state.hh"
 #include "sim/sim_object.hh"
 
@@ -71,6 +72,7 @@
 read(int regIdx, int threadId=0)
 {
 T p0 = vgprState->read(regIdx, threadId);
+DPRINTF(GPUVRF, "reading vreg[%d][%d] = %u\n", regIdx, threadId, 
(uint64_t)p0);
 
 return p0;
 }
@@ -80,6 +82,7 @@
 void
 write(int regIdx, T value, int threadId=0)
 {
+DPRINTF(GPUVRF, "writing vreg[%d][%d] = %u\n", regIdx, threadId, 
(uint64_t)value);
 vgprState->write(regIdx, value, threadId);
 }
 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: gpu-compute: Refactoring Wavefront::dynWaveId

[Alexandru Dutu]

changeset 42a1873be45c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=42a1873be45c
description:
gpu-compute: Refactoring Wavefront::dynWaveId

diffstat:

 src/arch/hsail/gen.py   |   2 +-
 src/gpu-compute/compute_unit.cc |  24 
 src/gpu-compute/wavefront.cc|   2 +-
 src/gpu-compute/wavefront.hh|   3 ++-
 4 files changed, 16 insertions(+), 15 deletions(-)

diffs (115 lines):

diff -r 46cffde5d8a6 -r 42a1873be45c src/arch/hsail/gen.py
--- a/src/arch/hsail/gen.py Fri Sep 16 12:30:05 2016 -0400
+++ b/src/arch/hsail/gen.py Fri Sep 16 12:31:46 2016 -0400
@@ -755,7 +755,7 @@
 gen_special('GridGroups',
 'divCeil(w->gridSz[src0],w->workGroupSz[src0])')
 gen_special('LaneId', 'lane')
-gen_special('WaveId', 'w->dynWaveId')
+gen_special('WaveId', 'w->wfId')
 gen_special('Clock', 'w->computeUnit->shader->tick_cnt', 'U64')
 
 # gen_special('CU'', ')
diff -r 46cffde5d8a6 -r 42a1873be45c src/gpu-compute/compute_unit.cc
--- a/src/gpu-compute/compute_unit.cc   Fri Sep 16 12:30:05 2016 -0400
+++ b/src/gpu-compute/compute_unit.cc   Fri Sep 16 12:31:46 2016 -0400
@@ -221,7 +221,7 @@
 
 void
 ComputeUnit::StartWF(Wavefront *w, int trueWgSize[], int trueWgSizeTotal,
- int cnt, LdsChunk *ldsChunk, NDRange *ndr)
+ int waveId, LdsChunk *ldsChunk, NDRange *ndr)
 {
 static int _n_wave = 0;
 
@@ -232,20 +232,20 @@
 init_mask.reset();
 
 for (int k = 0; k < wfSize(); ++k) {
-if (k + cnt * wfSize() < trueWgSizeTotal)
+if (k + waveId * wfSize() < trueWgSizeTotal)
 init_mask[k] = 1;
 }
 
 w->kernId = ndr->dispatchId;
-w->dynWaveId = cnt;
+w->wfId = waveId;
 w->initMask = init_mask.to_ullong();
 
 for (int k = 0; k < wfSize(); ++k) {
-w->workItemId[0][k] = (k+cnt*wfSize()) % trueWgSize[0];
+w->workItemId[0][k] = (k + waveId * wfSize()) % trueWgSize[0];
 w->workItemId[1][k] =
-((k + cnt * wfSize()) / trueWgSize[0]) % trueWgSize[1];
+((k + waveId * wfSize()) / trueWgSize[0]) % trueWgSize[1];
 w->workItemId[2][k] =
-(k + cnt * wfSize()) / (trueWgSize[0] * trueWgSize[1]);
+(k + waveId * wfSize()) / (trueWgSize[0] * trueWgSize[1]);
 
 w->workItemFlatId[k] = w->workItemId[2][k] * trueWgSize[0] *
 trueWgSize[1] + w->workItemId[1][k] * trueWgSize[0] +
@@ -294,8 +294,8 @@
 // is this the last wavefront in the workgroup
 // if set the spillWidth to be the remaining work-items
 // so that the vector access is correct
-if ((cnt + 1) * wfSize() >= trueWgSizeTotal) {
-w->spillWidth = trueWgSizeTotal - (cnt * wfSize());
+if ((waveId + 1) * wfSize() >= trueWgSizeTotal) {
+w->spillWidth = trueWgSizeTotal - (waveId * wfSize());
 } else {
 w->spillWidth = wfSize();
 }
@@ -341,7 +341,7 @@
 
 // calculate the number of 32-bit vector registers required by wavefront
 int vregDemand = ndr->q.sRegCount + (2 * ndr->q.dRegCount);
-int cnt = 0;
+int wave_id = 0;
 
 // Assign WFs by spreading them across SIMDs, 1 WF per SIMD at a time
 for (int m = 0; m < shader->n_wf * numSIMDs; ++m) {
@@ -352,7 +352,7 @@
 if (w->status == Wavefront::S_STOPPED) {
 // if we have scheduled all work items then stop
 // scheduling wavefronts
-if (cnt * wfSize() >= trueWgSizeTotal)
+if (wave_id * wfSize() >= trueWgSizeTotal)
 break;
 
 // reserve vector registers for the scheduled wavefront
@@ -365,8 +365,8 @@
 w->reservedVectorRegs = normSize;
 vectorRegsReserved[m % numSIMDs] += w->reservedVectorRegs;
 
-StartWF(w, trueWgSize, trueWgSizeTotal, cnt, ldsChunk, ndr);
-++cnt;
+StartWF(w, trueWgSize, trueWgSizeTotal, wave_id, ldsChunk, ndr);
+++wave_id;
 }
 }
 ++barrier_id;
diff -r 46cffde5d8a6 -r 42a1873be45c src/gpu-compute/wavefront.cc
--- a/src/gpu-compute/wavefront.cc  Fri Sep 16 12:30:05 2016 -0400
+++ b/src/gpu-compute/wavefront.cc  Fri Sep 16 12:31:46 2016 -0400
@@ -935,7 +935,7 @@
 uint32_t
 Wavefront::getStaticContextSize() const
 {
-return barCnt.size() * sizeof(int) + sizeof(dynWaveId) + sizeof(maxBarCnt) 
+
+return barCnt.size() * sizeof(int) + sizeof(wfId) + sizeof(maxBarCnt) +
sizeof(oldBarrierCnt) + sizeof(barrierCnt) + sizeof(wgId) +
sizeof(computeUnit->cu_id) + sizeof(barrierId) + sizeof(initMask) +
sizeof(privBase) + sizeof(spillBase) + sizeof(ldsChunk) +
diff -r 46cffde5d8a6 -r 42a1873be45c src/gpu-compute/wavefront.hh
--- a/src/gpu-compute/wavefront.hh  Fri Sep 16 12:30:05 2016 -0400
+++ b/src/gpu-compute/wavefront.hh  Fri Sep 16 12:31:46 2016 -0400
@@ -194,7 +194,8 @@
 uint32_t gridSz[3];
 uint32_t wgId;
 uint32_t wgSz;
-uint32_t dynWaveId;
+// wavefront id within a 

[gem5-dev] changeset in gem5: gpu-compute: Adding ioctl for HW context size

[Alexandru Dutu]

changeset aa846ec8cd8d in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=aa846ec8cd8d
description:
gpu-compute: Adding ioctl for HW context size
Adding runtime support for determining the memory required by a SIMD 
engine
when executing a particular wavefront.

diffstat:

 src/gpu-compute/cl_driver.cc   |   7 +++
 src/gpu-compute/dispatcher.cc  |   6 ++
 src/gpu-compute/dispatcher.hh  |   3 +++
 src/gpu-compute/hsa_kernel_info.hh |   1 +
 src/gpu-compute/wavefront.cc   |  14 --
 src/gpu-compute/wavefront.hh   |   6 ++
 6 files changed, 35 insertions(+), 2 deletions(-)

diffs (99 lines):

diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/cl_driver.cc
--- a/src/gpu-compute/cl_driver.cc  Fri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/cl_driver.cc  Fri Sep 16 12:27:56 2016 -0400
@@ -242,6 +242,13 @@
 buf.copyOut(tc->getMemProxy());
 }
 break;
+  case HSA_GET_HW_STATIC_CONTEXT_SIZE:
+{
+BufferArg buf(buf_addr, sizeof(uint32_t));
+*((uint32_t*)buf.bufferPtr()) = dispatcher->getStaticContextSize();
+buf.copyOut(tc->getMemProxy());
+}
+break;
 
   default:
 fatal("ClDriver: bad ioctl %d\n", req);
diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/dispatcher.cc
--- a/src/gpu-compute/dispatcher.cc Fri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/dispatcher.cc Fri Sep 16 12:27:56 2016 -0400
@@ -398,3 +398,9 @@
 {
 shader->funcargs_size = funcargs_size;
 }
+
+uint32_t
+GPUDispatcher::getStaticContextSize() const
+{
+return shader->cuList[0]->wfList[0][0]->getStaticContextSize();
+}
diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/dispatcher.hh
--- a/src/gpu-compute/dispatcher.hh Fri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/dispatcher.hh Fri Sep 16 12:27:56 2016 -0400
@@ -159,6 +159,9 @@
 int getNumCUs();
 int wfSize() const;
 void setFuncargsSize(int funcargs_size);
+
+/** Returns the size of the static hardware context of a wavefront */
+uint32_t getStaticContextSize() const;
 };
 
 #endif // __GPU_DISPATCHER_HH__
diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/hsa_kernel_info.hh
--- a/src/gpu-compute/hsa_kernel_info.hhFri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/hsa_kernel_info.hhFri Sep 16 12:27:56 2016 -0400
@@ -48,6 +48,7 @@
 static const int HSA_GET_READONLY_DATA = 0x4805;
 static const int HSA_GET_CU_CNT = 0x4806;
 static const int HSA_GET_VSZ = 0x4807;
+static const int HSA_GET_HW_STATIC_CONTEXT_SIZE = 0x4808;
 
 // Return value (via buffer ptr) for HSA_GET_SIZES
 struct HsaDriverSizes
diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/wavefront.cc
--- a/src/gpu-compute/wavefront.cc  Fri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/wavefront.cc  Fri Sep 16 12:27:56 2016 -0400
@@ -155,9 +155,9 @@
 }
 
 void
-Wavefront::start(uint64_t _wfDynId,uint64_t _base_ptr)
+Wavefront::start(uint64_t _wf_dyn_id,uint64_t _base_ptr)
 {
-wfDynId = _wfDynId;
+wfDynId = _wf_dyn_id;
 basePtr = _base_ptr;
 status = S_RUNNING;
 }
@@ -931,3 +931,13 @@
 {
 reconvergenceStack.top()->pc = new_pc;
 }
+
+uint32_t
+Wavefront::getStaticContextSize() const
+{
+return barCnt.size() * sizeof(int) + sizeof(dynWaveId) + sizeof(maxBarCnt) 
+
+   sizeof(oldBarrierCnt) + sizeof(barrierCnt) + sizeof(wgId) +
+   sizeof(computeUnit->cu_id) + sizeof(barrierId) + sizeof(initMask) +
+   sizeof(privBase) + sizeof(spillBase) + sizeof(ldsChunk) +
+   computeUnit->wfSize() * sizeof(ReconvergenceStackEntry);
+}
diff -r 2e8d4bd8108d -r aa846ec8cd8d src/gpu-compute/wavefront.hh
--- a/src/gpu-compute/wavefront.hh  Fri Sep 16 12:26:52 2016 -0400
+++ b/src/gpu-compute/wavefront.hh  Fri Sep 16 12:27:56 2016 -0400
@@ -354,6 +354,12 @@
 
 void discardFetch();
 
+/**
+ * Returns the size of the static hardware context of a particular 
wavefront
+ * This should be updated everytime the context is changed
+ */
+uint32_t getStaticContextSize() const;
+
   private:
 /**
  * Stack containing Control Flow Graph nodes (i.e., kernel instructions)
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: gpu-compute: Remove WFContext

[Alexandru Dutu]

changeset b511733958d0 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b511733958d0
description:
gpu-compute: Remove WFContext
WFContext struct is currently unused and it has been rendered not 
useful in
saving and restoring the context of a Wavefront. Wavefront class should 
be
sufficient for that purpose and the runtime can figure out the memory 
size
it will need to allocate for a Wavefront through an IOCTL.

diffstat:

 src/gpu-compute/compute_unit.cc |  99 +++-
 src/gpu-compute/compute_unit.hh |   8 +--
 src/gpu-compute/qstruct.hh  |  53 -
 3 files changed, 30 insertions(+), 130 deletions(-)

diffs (245 lines):

diff -r 94fd30b3e1cb -r b511733958d0 src/gpu-compute/compute_unit.cc
--- a/src/gpu-compute/compute_unit.cc   Fri Sep 16 09:14:31 2016 +0100
+++ b/src/gpu-compute/compute_unit.cc   Fri Sep 16 12:26:03 2016 -0400
@@ -193,50 +193,6 @@
 }
 
 void
-ComputeUnit::InitializeWFContext(WFContext *wfCtx, NDRange *ndr, int cnt,
-int trueWgSize[], int trueWgSizeTotal,
-LdsChunk *ldsChunk, uint64_t origSpillMemStart)
-{
-wfCtx->cnt = cnt;
-
-VectorMask init_mask;
-init_mask.reset();
-
-for (int k = 0; k < wfSize(); ++k) {
-if (k + cnt * wfSize() < trueWgSizeTotal)
-init_mask[k] = 1;
-}
-
-wfCtx->init_mask = init_mask.to_ullong();
-wfCtx->exec_mask = init_mask.to_ullong();
-
-wfCtx->bar_cnt.resize(wfSize(), 0);
-
-wfCtx->max_bar_cnt = 0;
-wfCtx->old_barrier_cnt = 0;
-wfCtx->barrier_cnt = 0;
-
-wfCtx->privBase = ndr->q.privMemStart;
-ndr->q.privMemStart += ndr->q.privMemPerItem * wfSize();
-
-wfCtx->spillBase = ndr->q.spillMemStart;
-ndr->q.spillMemStart += ndr->q.spillMemPerItem * wfSize();
-
-wfCtx->pc = 0;
-wfCtx->rpc = UINT32_MAX;
-
-// set the wavefront context to have a pointer to this section of the LDS
-wfCtx->ldsChunk = ldsChunk;
-
-// WG state
-wfCtx->wg_id = ndr->globalWgId;
-wfCtx->barrier_id = barrier_id;
-
-// Kernel wide state
-wfCtx->ndr = ndr;
-}
-
-void
 ComputeUnit::updateEvents() {
 
 if (!timestampVec.empty()) {
@@ -264,19 +220,25 @@
 
 
 void
-ComputeUnit::StartWF(Wavefront *w, WFContext *wfCtx, int trueWgSize[],
- int trueWgSizeTotal)
+ComputeUnit::StartWF(Wavefront *w, int trueWgSize[], int trueWgSizeTotal,
+ int cnt, LdsChunk *ldsChunk, NDRange *ndr)
 {
 static int _n_wave = 0;
-int cnt = wfCtx->cnt;
-NDRange *ndr = wfCtx->ndr;
 
 // Fill in Kernel state
 FillKernelState(w, ndr);
 
+VectorMask init_mask;
+init_mask.reset();
+
+for (int k = 0; k < wfSize(); ++k) {
+if (k + cnt * wfSize() < trueWgSizeTotal)
+init_mask[k] = 1;
+}
+
 w->kern_id = ndr->dispatchId;
 w->dynwaveid = cnt;
-w->init_mask = wfCtx->init_mask;
+w->init_mask = init_mask.to_ullong();
 
 for (int k = 0; k < wfSize(); ++k) {
 w->workitemid[0][k] = (k+cnt*wfSize()) % trueWgSize[0];
@@ -290,32 +252,34 @@
 w->workitemid[0][k];
 }
 
-w->old_barrier_cnt = wfCtx->old_barrier_cnt;
-w->barrier_cnt = wfCtx->barrier_cnt;
 w->barrier_slots = divCeil(trueWgSizeTotal, wfSize());
 
-for (int i = 0; i < wfSize(); ++i) {
-w->bar_cnt[i] = wfCtx->bar_cnt[i];
-}
+w->bar_cnt.resize(wfSize(), 0);
 
-w->max_bar_cnt = wfCtx->max_bar_cnt;
-w->privBase = wfCtx->privBase;
-w->spillBase = wfCtx->spillBase;
+w->max_bar_cnt = 0;
+w->old_barrier_cnt = 0;
+w->barrier_cnt = 0;
 
-w->pushToReconvergenceStack(wfCtx->pc, wfCtx->rpc, wfCtx->exec_mask);
+w->privBase = ndr->q.privMemStart;
+ndr->q.privMemStart += ndr->q.privMemPerItem * wfSize();
+
+w->spillBase = ndr->q.spillMemStart;
+ndr->q.spillMemStart += ndr->q.spillMemPerItem * wfSize();
+
+w->pushToReconvergenceStack(0, UINT32_MAX, init_mask.to_ulong());
 
 // WG state
-w->wg_id = wfCtx->wg_id;
-w->dispatchid = wfCtx->ndr->dispatchId;
+w->wg_id = ndr->globalWgId;
+w->dispatchid = ndr->dispatchId;
 w->workgroupid[0] = w->wg_id % ndr->numWg[0];
 w->workgroupid[1] = (w->wg_id / ndr->numWg[0]) % ndr->numWg[1];
 w->workgroupid[2] = w->wg_id / (ndr->numWg[0] * ndr->numWg[1]);
 
-w->barrier_id = wfCtx->barrier_id;
+w->barrier_id = barrier_id;
 w->stalledAtBarrier = false;
 
-// move this from the context into the actual wavefront
-w->ldsChunk = wfCtx->ldsChunk;
+// set the wavefront context to have a pointer to this section of the LDS
+w->ldsChunk = ldsChunk;
 
 int32_t refCount M5_VAR_USED =
 lds.increaseRefCounter(w->dispatchid, w->wg_id);
@@ -340,7 +304,6 @@
 "WF[%d][%d]\n", _n_wave, barrier_id, cu_id, w->simdId, 
w->wfSlotId);
 
 w->start(++_n_wave, ndr->q.code_ptr);
-wfCtx->bar_cnt.clear();
 }
 
 v

[gem5-dev] changeset in gem5: gpu-compute: Changing reconvergenceStack type

[Alexandru Dutu]

changeset a9f0711e7230 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a9f0711e7230
description:
gpu-compute: Changing reconvergenceStack type
std::stack has no iterators, therefore the reconvergence stack can't be
iterated without poping elements off. We will be using std::list 
instead to be
able to iterate for saving and restoring purposes.

diffstat:

 src/gpu-compute/wavefront.cc |  14 ++--
 src/gpu-compute/wavefront.hh |  51 ++-
 2 files changed, 29 insertions(+), 36 deletions(-)

diffs (134 lines):

diff -r aa846ec8cd8d -r a9f0711e7230 src/gpu-compute/wavefront.cc
--- a/src/gpu-compute/wavefront.cc  Fri Sep 16 12:27:56 2016 -0400
+++ b/src/gpu-compute/wavefront.cc  Fri Sep 16 12:29:01 2016 -0400
@@ -873,7 +873,7 @@
 const VectorMask& mask)
 {
 assert(mask.count());
-reconvergenceStack.emplace(new ReconvergenceStackEntry(pc, rpc, mask));
+reconvergenceStack.emplace_back(new ReconvergenceStackEntry{pc, rpc, 
mask});
 }
 
 void
@@ -886,7 +886,7 @@
 execMask().to_string().c_str(), pc());
 
-reconvergenceStack.pop();
+reconvergenceStack.pop_back();
 
 DPRINTF(WavefrontStack, "%3i %s\n", pc(),
 execMask().to_stringpc;
+return reconvergenceStack.back()->pc;
 }
 
 uint32_t
 Wavefront::rpc() const
 {
-return reconvergenceStack.top()->rpc;
+return reconvergenceStack.back()->rpc;
 }
 
 VectorMask
 Wavefront::execMask() const
 {
-return reconvergenceStack.top()->execMask;
+return reconvergenceStack.back()->execMask;
 }
 
 bool
 Wavefront::execMask(int lane) const
 {
-return reconvergenceStack.top()->execMask[lane];
+return reconvergenceStack.back()->execMask[lane];
 }
 
 
 void
 Wavefront::pc(uint32_t new_pc)
 {
-reconvergenceStack.top()->pc = new_pc;
+reconvergenceStack.back()->pc = new_pc;
 }
 
 uint32_t
diff -r aa846ec8cd8d -r a9f0711e7230 src/gpu-compute/wavefront.hh
--- a/src/gpu-compute/wavefront.hh  Fri Sep 16 12:27:56 2016 -0400
+++ b/src/gpu-compute/wavefront.hh  Fri Sep 16 12:29:01 2016 -0400
@@ -52,6 +52,27 @@
 
 static const int MAX_NUM_INSTS_PER_WF = 12;
 
+/**
+ * A reconvergence stack entry conveys the necessary state to implement
+ * control flow divergence.
+ */
+struct ReconvergenceStackEntry {
+/**
+ * PC of current instruction.
+ */
+uint32_t pc;
+/**
+ * PC of the immediate post-dominator instruction, i.e., the value of
+ * @a pc for the first instruction that will be executed by the wavefront
+ * when a reconvergence point is reached.
+ */
+uint32_t rpc;
+/**
+ * Execution mask.
+ */
+VectorMask execMask;
+};
+
 /*
  * Arguments for the hsail opcode call, are user defined and variable length.
  * The hardware/finalizer can support arguments in hardware or use memory to
@@ -120,34 +141,6 @@
 }
 };
 
-/**
- * A reconvergence stack entry conveys the necessary state to implement
- * control flow divergence.
- */
-class ReconvergenceStackEntry {
-
-  public:
-ReconvergenceStackEntry(uint32_t new_pc, uint32_t new_rpc,
-VectorMask new_mask) : pc(new_pc), rpc(new_rpc),
-execMask(new_mask) {
-}
-
-/**
- * PC of current instruction.
- */
-uint32_t pc;
-/**
- * PC of the immediate post-dominator instruction, i.e., the value of
- * @a pc for the first instruction that will be executed by the wavefront
- * when a reconvergence point is reached.
- */
-uint32_t rpc;
-/**
- * Execution mask.
- */
-VectorMask execMask;
-};
-
 class Wavefront : public SimObject
 {
   public:
@@ -368,7 +361,7 @@
  * point (branch instruction), and shrinks every time the wavefront
  * reaches a reconvergence point (immediate post-dominator instruction).
  */
-std::stack> reconvergenceStack;
+std::deque> reconvergenceStack;
 };
 
 #endif // __WAVEFRONT_HH__
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: gpu-compute: Wavefront refactoring

[Alexandru Dutu]

changeset 2e8d4bd8108d in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=2e8d4bd8108d
description:
gpu-compute: Wavefront refactoring
Renaming members of the Wavefront class in accordance with the style 
guide.

diffstat:

 src/arch/hsail/gen.py |   30 +++---
 src/arch/hsail/insts/decl.hh  |   10 +-
 src/arch/hsail/insts/main.cc  |   14 +-
 src/arch/hsail/insts/mem_impl.hh  |   78 +-
 src/arch/hsail/insts/pseudo_inst.cc   |   90 ++--
 src/gpu-compute/compute_unit.cc   |   72 
 src/gpu-compute/dispatcher.cc |2 +-
 src/gpu-compute/fetch_unit.cc |2 +-
 src/gpu-compute/global_memory_pipeline.cc |6 +-
 src/gpu-compute/local_memory_pipeline.cc  |6 +-
 src/gpu-compute/wavefront.cc  |  130 +++---
 src/gpu-compute/wavefront.hh  |   78 +-
 12 files changed, 259 insertions(+), 259 deletions(-)

diffs (truncated from 1321 to 300 lines):

diff -r b511733958d0 -r 2e8d4bd8108d src/arch/hsail/gen.py
--- a/src/arch/hsail/gen.py Fri Sep 16 12:26:03 2016 -0400
+++ b/src/arch/hsail/gen.py Fri Sep 16 12:26:52 2016 -0400
@@ -233,7 +233,7 @@
 
 typedef Base::DestCType DestCType;
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -254,7 +254,7 @@
 typedef Base::DestCType DestCType;
 typedef Base::SrcCType  SrcCType;
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -275,7 +275,7 @@
 {
 Wavefront *w = gpuDynInst->wavefront();
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -310,7 +310,7 @@
 typedef typename Base::Src1CType Src1T;
 typedef typename Base::Src2CType Src2T;
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -344,7 +344,7 @@
 typedef CType Src0T;
 typedef typename Base::Src1CType Src1T;
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -371,7 +371,7 @@
 {
 Wavefront *w = gpuDynInst->wavefront();
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
 CType dest_val;
@@ -399,7 +399,7 @@
 {
 Wavefront *w = gpuDynInst->wavefront();
 
-const VectorMask &mask = w->get_pred();
+const VectorMask &mask = w->getPred();
 
 for (int lane = 0; lane < w->computeUnit->wfSize(); ++lane) {
 if (mask[lane]) {
@@ -745,17 +745,17 @@
 
 gen(brig_opcode, None, expr, base_class)
 
-gen_special('WorkItemId', 'w->workitemid[src0][lane]')
+gen_special('WorkItemId', 'w->workItemId[src0][lane]')
 gen_special('WorkItemAbsId',
-'w->workitemid[src0][lane] + (w->workgroupid[src0] * 
w->workgroupsz[src0])')
-gen_special('WorkGroupId', 'w->workgroupid[src0]')
-gen_special('WorkGroupSize', 'w->workgroupsz[src0]')
-gen_special('CurrentWorkGroupSize', 'w->workgroupsz[src0]')
-gen_special('GridSize', 'w->gridsz[src0]')
+'w->workItemId[src0][lane] + (w->workGroupId[src0] * 
w->workGroupSz[src0])')
+gen_special('WorkGroupId', 'w->workGroupId[src0]')
+gen_special('WorkGroupSize', 'w->workGroupSz[src0]')
+gen_special('CurrentWorkGroupSize', 'w->workGroupSz[src0]')
+gen_special('GridSize', 'w->gridSz[src0]')
 gen_special('GridGroups',
-'divCeil(w->gridsz[src0],w->workgroupsz[src0])')
+'divCeil(w->gridSz[src0],w->workGroupSz[src0])')
 gen_special('LaneId', 'lane')
-gen_special('WaveId', 'w->dynwaveid')
+gen_special('WaveId', 'w->dynWaveId')
 gen_special('Clock', 'w->computeUnit->shader->tick_cnt', 'U64')
 
 # gen_special('CU'', ')
diff -r b511733958d0 -r 2e8d4bd8108d src/arch/hsail/insts/decl.hh
--- a/src/arch/hsail/insts/decl.hh  Fri Sep 16 12:26:03 2016 -0400
+++ b/src/arch/hsail/insts/decl.hh  Fri Sep 16 12:26:52 2016 -0400
@@ -960,7 +960,7 @@
 gpuDynInst->simdId = w->simdId;
 gpuDynInst->wfSlotId = w->wfSlotId;
 gpuDynInst->wfDynId = w->wfDynId;
-gpuDynInst->kern_id = w->kern_id;
+gpuDynInst->kern_id = w->kernId;
 gpuDynInst->cu_id = w->computeUnit->cu_id;
 
 gpuDynInst->memoryOrder =
@@ -971,10 +971,10 @@
 GlobalMemPipeline* gmp = &(w->computeUnit->globalMemoryPip

Re: [gem5-dev] Review Request 3535: gpu-compute: Adding context serialization methods to Wavefront

[Alexandru Dutu]

> On June 30, 2016, 7:17 a.m., Andreas Hansson wrote:
> > src/gpu-compute/wavefront.hh, line 389
> > <http://reviews.gem5.org/r/3535/diff/1/?file=56852#file56852line389>
> >
> > Surely one of these should be const
> 
> Andreas Hansson wrote:
> I do not see this being addressed. getContext should be const I would 
> imagine.

I see, you meant the functions to be const. Well the functions can't actually 
be const as both of them are calling non-const functions (i.e. remap and 
emplace_back).


> On June 30, 2016, 7:17 a.m., Andreas Hansson wrote:
> > src/gpu-compute/wavefront.cc, line 946
> > <http://reviews.gem5.org/r/3535/diff/1/?file=56853#file56853line946>
> >
> > Not too many bonus points for comments here...that's for sure.
> 
> Alexandru Dutu wrote:
> I have added a comment in the header file which should describe the 
> behaviour of this method and added comments inside it where things are not 
> straight forward (i.e. recovergence stack and LDS). Please let me know what 
> is not clear and requires a comment, would be happy to add some more.
> 
> Andreas Hansson wrote:
> I find the code rather unfortunate. It would have been great to see this 
> implemented using e.g. protobuf or similar, but it's up to you if you really 
> think this is maintainable (and understandable).

Actually, I had 2 implementations for this: 1 using iostreams and the good old 
void * implementation you see currently. I've chosen this implementation for 
simplicity as there isn't much difference (in maintainability of readability) 
between "*(int *)iter = wfId; iter += sizeof(wfId);" and 
"ProtoMessage::PacketHeader out; out.set_wf_id(w->wfId); ... 
out->write(wavefront_context);". Meaning one still has to set all the 
attributes of the object to be serialized. I will be using protobufs more and I 
might change this code in the future if there is an advantage. Also, the 
reconvergence stack makes the use of protobufers less convenient as you still 
have to iterate over it and have a function call to set each entry.


- Alexandru


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


On July 8, 2016, 10:14 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3535/
> ---
> 
> (Updated July 8, 2016, 10:14 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11556:9e4c3b188fc5
> ---
> gpu-compute: Adding context serialization methods to Wavefront
> 
> This patch adds methods to serialize the context of a particular wavefront
> to the simulated system memory. Context serialization is used when a wavefront
> is preempeted (i.e. context switch).
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/wavefront.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/gpu-compute/wavefront.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
> 
> Diff: http://reviews.gem5.org/r/3535/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 3535: gpu: Adding serializing methods to Wavefront

[Alexandru Dutu]

> On June 30, 2016, 7:17 a.m., Andreas Hansson wrote:
> > src/gpu-compute/wavefront.cc, line 948
> > <http://reviews.gem5.org/r/3535/diff/1/?file=56853#file56853line948>
> >
> > Why the custom format? Why not stick to gem5's established methods for 
> > serializing and deserializing scalars and containers?
> 
> Alexandru Dutu wrote:
> Andreas, are you refering to the Serializable class? If so, my 
> understanding is that Serializable is used in the context of creating a 
> Checkpoint, therefore it includes the names of the classes and class members 
> in the serialized stream. This something which is not desired in our case as 
> we want the serialized context to be something available to the actual 
> simulated hardware and not just to the simulator. It seems that even 
> SERIALIZE_CONTAINER calls arrayParamOut which includes names in the output 
> stream. Serializable seems quite heavy weight, as it includes this extra 
> class for handling checkpoints (ScopedCheckpointSection) and it does not do 
> what we need.
> 
> Andreas Hansson wrote:
> Ok, then I really do not understand what the patch is trying to do :-). 
> Perhaps you can explain the use-case in the description?

The functionality which we want to enable is context switching, so this patch 
adds the methods that get the context of a wavefront ready to be written to the 
simulated memory. I will update the description.


- Alexandru


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


On June 29, 2016, 4:02 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3535/
> ---
> 
> (Updated June 29, 2016, 4:02 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11556:e46e9a28e2aa
> ---
> gpu: Adding serializing methods to Wavefront
> This patch adds methods to serialize the context of a particular wavefront.
> It should be a neat feature to have for wavefront preemption.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/wavefront.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/gpu-compute/wavefront.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
> 
> Diff: http://reviews.gem5.org/r/3535/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 3535: gpu: Adding serializing methods to Wavefront

[Alexandru Dutu]

> On June 30, 2016, 7:17 a.m., Andreas Hansson wrote:
> > src/gpu-compute/wavefront.cc, line 948
> > 
> >
> > Why the custom format? Why not stick to gem5's established methods for 
> > serializing and deserializing scalars and containers?

Andreas, are you refering to the Serializable class? If so, my understanding is 
that Serializable is used in the context of creating a Checkpoint, therefore it 
includes the names of the classes and class members in the serialized stream. 
This something which is not desired in our case as we want the serialized 
context to be something available to the actual simulated hardware and not just 
to the simulator. It seems that even SERIALIZE_CONTAINER calls arrayParamOut 
which includes names in the output stream. Serializable seems quite heavy 
weight, as it includes this extra class for handling checkpoints 
(ScopedCheckpointSection) and it does not do what we need.


> On June 30, 2016, 7:17 a.m., Andreas Hansson wrote:
> > src/gpu-compute/wavefront.cc, line 946
> > 
> >
> > Not too many bonus points for comments here...that's for sure.

I have added a comment in the header file which should describe the behaviour 
of this method and added comments inside it where things are not straight 
forward (i.e. recovergence stack and LDS). Please let me know what is not clear 
and requires a comment, would be happy to add some more.


- Alexandru


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


On June 29, 2016, 4:02 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3535/
> ---
> 
> (Updated June 29, 2016, 4:02 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11556:e46e9a28e2aa
> ---
> gpu: Adding serializing methods to Wavefront
> This patch adds methods to serialize the context of a particular wavefront.
> It should be a neat feature to have for wavefront preemption.
> 
> 
> Diffs
> -
> 
>   src/gpu-compute/wavefront.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/gpu-compute/wavefront.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
> 
> Diff: http://reviews.gem5.org/r/3535/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 3401: x86: fix TLB issue

[Alexandru Dutu]

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


The AMD64 manual does not mention this case something the hardware will do an 
implicit invalidation of. It seems that just having PDE.PS bit different should 
trigger a TLB miss and the hardware will walk the page table and replace the 
TLB entry with the new one. I can understand the intention though I am not sure 
if the implementation should be done in this way. A more accurate 
implementation seems to be to update the TLB::lookup function such that it does 
not return the entry when the logBits are different.

- Alexandru Dutu


On April 13, 2016, 1:37 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3401/
> ---
> 
> (Updated April 13, 2016, 1:37 p.m.)
> 
> 
> Review request for Default, Jason Lowe-Power and Steve Reinhardt.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11369:52df7c56508b
> ---
> x86: fix TLB issue
> 
> In case we have a 4k page mapping and we will later add a 2M
> mapping at the same address, we will return the still existing
> 4k entry.  It is unclear to me why this is, but by deleting any
> entry at the same address with a different size we avoid this problem.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/tlb.cc 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3401/diff/
> 
> 
> Testing
> ---
> 
> Observed booting FreeBSD amd64;  did a manual run to dump the trie to verify 
> a few weeks back.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

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

[gem5-dev] changeset in gem5: syscall_emul: add extra debug support for sys...

[Alexandru Dutu]

changeset 3370547fa302 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3370547fa302
description:
syscall_emul: add extra debug support for syscalls

Breaks the debug output from system calls into two levels: Base and 
Verbose.
A macro is added specifically for system calls which allows developers 
to
easily add new debug messages in a consistent manner. The macro also 
contains
a field to print thread IDs along with the CPU ID.

diffstat:

 src/sim/SConscript  |   3 +++
 src/sim/syscall_emul.cc |  27 ---
 src/sim/syscall_emul.hh |  11 ++-
 3 files changed, 29 insertions(+), 12 deletions(-)

diffs (115 lines):

diff -r bfe4c2a8ad36 -r 3370547fa302 src/sim/SConscript
--- a/src/sim/SConscriptThu Mar 17 10:22:39 2016 -0700
+++ b/src/sim/SConscriptThu Mar 17 10:22:39 2016 -0700
@@ -91,6 +91,7 @@
 DebugFlag('Loader')
 DebugFlag('PseudoInst')
 DebugFlag('Stack')
+DebugFlag('SyscallBase')
 DebugFlag('SyscallVerbose')
 DebugFlag('TimeSync')
 DebugFlag('Thread')
@@ -100,3 +101,5 @@
 DebugFlag('ClockDomain')
 DebugFlag('VoltageDomain')
 DebugFlag('DVFS')
+
+CompoundFlag('SyscallAll', [ 'SyscallBase', 'SyscallVerbose'])
diff -r bfe4c2a8ad36 -r 3370547fa302 src/sim/syscall_emul.cc
--- a/src/sim/syscall_emul.cc   Thu Mar 17 10:22:39 2016 -0700
+++ b/src/sim/syscall_emul.cc   Thu Mar 17 10:22:39 2016 -0700
@@ -42,6 +42,7 @@
 #include "config/the_isa.hh"
 #include "cpu/base.hh"
 #include "cpu/thread_context.hh"
+#include "debug/SyscallBase.hh"
 #include "debug/SyscallVerbose.hh"
 #include "mem/page_table.hh"
 #include "sim/process.hh"
@@ -55,28 +56,31 @@
 void
 SyscallDesc::doSyscall(int callnum, LiveProcess *process, ThreadContext *tc)
 {
-if (DTRACE(SyscallVerbose)) {
+if (DTRACE(SyscallBase)) {
 int index = 0;
-IntReg arg[4] M5_VAR_USED;
+IntReg arg[6] M5_VAR_USED;
 
 // we can't just put the calls to getSyscallArg() in the
 // DPRINTF arg list, because C++ doesn't guarantee their order
-for (int i = 0; i < 4; ++i)
+for (int i = 0; i < 6; ++i)
 arg[i] = process->getSyscallArg(tc, index);
 
-DPRINTFNR("%d: %s: syscall %s called w/arguments %d,%d,%d,%d\n",
-  curTick(), tc->getCpuPtr()->name(), name,
-  arg[0], arg[1], arg[2], arg[3]);
+// Linux supports up to six system call arguments through registers
+// so we want to print all six. Check to the relevant man page to
+// verify how many are actually used by a given system call.
+DPRINTF_SYSCALL(Base,
+"%s called w/arguments %d, %d, %d, %d, %d, %d\n",
+name, arg[0], arg[1], arg[2], arg[3], arg[4],
+arg[5]);
 }
 
 SyscallReturn retval = (*funcPtr)(this, callnum, process, tc);
 
 if (retval.needsRetry()) {
-DPRINTFS(SyscallVerbose, tc->getCpuPtr(), "syscall %s needs retry\n",
- name);
+DPRINTF_SYSCALL(Base, "%s needs retry\n", name);
 } else {
-DPRINTFS(SyscallVerbose, tc->getCpuPtr(), "syscall %s returns %d\n",
- name, retval.encodedValue());
+DPRINTF_SYSCALL(Base, "%s returns %d\n", name,
+retval.encodedValue());
 }
 
 if (!(flags & SyscallDesc::SuppressReturnValue) && !retval.needsRetry())
@@ -201,7 +205,8 @@
 }
 
 p->brk_point = new_brk;
-DPRINTF(SyscallVerbose, "Break Point changed to: %#X\n", p->brk_point);
+DPRINTF_SYSCALL(Verbose, "brk: break point changed to: %#X\n",
+p->brk_point);
 return p->brk_point;
 }
 
diff -r bfe4c2a8ad36 -r 3370547fa302 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Thu Mar 17 10:22:39 2016 -0700
+++ b/src/sim/syscall_emul.hh   Thu Mar 17 10:22:39 2016 -0700
@@ -74,6 +74,7 @@
 #include "config/the_isa.hh"
 #include "cpu/base.hh"
 #include "cpu/thread_context.hh"
+#include "debug/SyscallBase.hh"
 #include "debug/SyscallVerbose.hh"
 #include "mem/page_table.hh"
 #include "sim/byteswap.hh"
@@ -83,6 +84,14 @@
 #include "sim/syscallreturn.hh"
 #include "sim/system.hh"
 
+// This wrapper macro helps out with readability a bit. FLAGEXT specifies
+// the verbosity and FMT is the message to be appended to the syscall
+// header information. The syscall header information contains the cpuid
+// and thread id.
+#define DPRINTF_SYSCALL(FLAGEXT, FMT, ...)  \
+DPRINTFS(Syscall##FLAGEXT, tc->getCpuPtr(), "T%d : syscall " FMT,   \
+ tc->threadId(), __VA_ARGS__)
+
 ///
 /// System call descriptor.
 ///
@@ -1100,7 +1109,7 @@
 int tgt_fd = process->getSyscallArg(tc, index);
 Addr bufPtr = process->getSyscallArg(tc, index);
 
-DPRINTF(SyscallVerbose, "fstat(%d, ...)\n", tgt_fd);
+DPRINTF_SYSCALL(Verbose, "fstat(%d, ...)\n", tgt_fd);
 
 int sim_fd = process->getSimFD(tgt_fd);
 if (sim_fd < 0)
_

Re: [gem5-dev] Review Request 3388: kvm: Add an option to force context sync on kvm entry/exit

[Alexandru Dutu]

> On March 18, 2016, 9:11 p.m., Alexandru Dutu wrote:
> >

I am not sure I understand why it is required to sync on every exit and not 
just on a gdb breakpoint exit. Also, I am curious about your motivation for a 
kvm-specific thread context. Can you please detail a bit?


- Alexandru


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


On March 16, 2016, 5:44 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3388/
> ---
> 
> (Updated March 16, 2016, 5:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11374:74c2b67b2684
> ---
> kvm: Add an option to force context sync on kvm entry/exit
> 
> This changeset adds an option to force the kvm-based CPUs to always
> synchronize the gem5 thread context representation on entry/exit into
> the kernel. This is very useful for debugging. Unfortunately, it is
> also the only way to get reliable register contents when using remote
> gdb functionality. The long-term solution for the latter would be to
> implement a kvm-specific thread context.
> 
> Signed-off-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/BaseKvmCPU.py 3234b429fe04 
>   src/cpu/kvm/base.hh 3234b429fe04 
>   src/cpu/kvm/base.cc 3234b429fe04 
> 
> Diff: http://reviews.gem5.org/r/3388/diff/
> 
> 
> Testing
> ---
> 
> Used extensively for debugging.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3388: kvm: Add an option to force context sync on kvm entry/exit

[Alexandru Dutu]

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

Ship it!


- Alexandru Dutu


On March 16, 2016, 5:44 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3388/
> ---
> 
> (Updated March 16, 2016, 5:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11374:74c2b67b2684
> ---
> kvm: Add an option to force context sync on kvm entry/exit
> 
> This changeset adds an option to force the kvm-based CPUs to always
> synchronize the gem5 thread context representation on entry/exit into
> the kernel. This is very useful for debugging. Unfortunately, it is
> also the only way to get reliable register contents when using remote
> gdb functionality. The long-term solution for the latter would be to
> implement a kvm-specific thread context.
> 
> Signed-off-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/BaseKvmCPU.py 3234b429fe04 
>   src/cpu/kvm/base.hh 3234b429fe04 
>   src/cpu/kvm/base.cc 3234b429fe04 
> 
> Diff: http://reviews.gem5.org/r/3388/diff/
> 
> 
> Testing
> ---
> 
> Used extensively for debugging.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 3342: mem: Remove threadId from memory request class

[Alexandru Dutu]

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

Ship it!


Seems a good cleanup to me!

- Alexandru Dutu


On Feb. 23, 2016, 8:58 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3342/
> ---
> 
> (Updated Feb. 23, 2016, 8:58 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> mem: Remove threadId from memory request class
> 
> In general, the ThreadID parameter is unnecessary in the memory system
> as the ContextID is what is used for the purposes of locks/wakeups.
> Since we allocate sequential ContextIDs for each thread on MT-enabled
> CPUs, ThreadID is unnecessary as the CPUs can identify the requesting
> thread through sideband info (SenderState / LSQ entries) or ContextID
> offset from the base ContextID for a cpu.
> 
> 
> Diffs
> -
> 
>   ext/sst/ExtMaster.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/arch/arm/isa.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/arch/arm/vtophys.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/base.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/base_dyn_inst.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/checker/cpu.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/checker/cpu_impl.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/kvm/base.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/kvm/x86_cpu.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/minor/fetch1.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/minor/lsq.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/o3/fetch_impl.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/o3/lsq.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/o3/lsq_impl.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/simple/atomic.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/simple/timing.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/testers/memtest/memtest.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/testers/networktest/networktest.cc 
> ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/testers/rubytest/Check.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/cpu/trace/trace_cpu.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/mem/cache/prefetch/queued.cc ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
>   src/mem/request.hh ef6e57ac0d708aff0af51c77ff0aee2c069993cf 
> 
> Diff: http://reviews.gem5.org/r/3342/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3279: sim: Add support for forking

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 14, 2016, 6:31 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3279/
> ---
> 
> (Updated Jan. 14, 2016, 6:31 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11299:a3879dcefc27
> ---
> sim: Add support for forking
> 
> This changeset adds forking capabilities to the gem5 python scripts. A fork
> method is added to simulate.py. This method is responsible for forking the
> simulator itself, and will direct all output files to a new output directory
> based on the fork sequence number. The default name of the output directory is
> the same as the parent with the suffix ".fN" added where N is the fork 
> sequence
> number. The fork method provides the option to specify if the system should be
> drained prior to forking, or not. By default the system is drained to ensure
> that there are no in-flight transactions.
> 
> When forking the simulator, the fork method returns the PID of the child
> process, or returns 0 if running in the child. This is in line with the 
> standard
> Python forking interface.
> 
> Signed-off-by: Andreas Sandberg 
> [sascha.bisch...@arm.com: Rebased patches onto a newer gem5 version]
> Signed-off-by: Sascha Bischoff 
> [andreas.sandb...@arm.com: Updated to comply with modern draining semantics ]
> Signed-off-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/python/m5/simulate.py 14029d75688d 
>   src/python/swig/core.i 14029d75688d 
> 
> Diff: http://reviews.gem5.org/r/3279/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 3278: dev: Add post-fork handling for disk images

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 14, 2016, 6:30 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3278/
> ---
> 
> (Updated Jan. 14, 2016, 6:30 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11298:b421f396097a
> ---
> dev: Add post-fork handling for disk images
> 
> This changeset adds support for notifying the disk images that the simulator 
> has
> been forked. We need to disable the saving of the CoW disk image from the 
> child
> process, and we need to make sure that systems which use a raw disk image are
> not allowed to fork to avoid two or more gem5 processes writing to the same 
> disk
> image.
> 
> Signed-off-by: Andreas Sandberg 
> [sascha.bisch...@arm.com: Rebased patches onto a newer gem5 version]
> Signed-off-by: Sascha Bischoff 
> Signed-off-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/dev/storage/disk_image.hh 14029d75688d 
>   src/dev/storage/disk_image.cc 14029d75688d 
> 
> Diff: http://reviews.gem5.org/r/3278/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 3277: sim: Add support for notifying Drainable objects of a fork

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On Jan. 14, 2016, 6:30 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3277/
> ---
> 
> (Updated Jan. 14, 2016, 6:30 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11297:80ea5f59f09a
> ---
> sim: Add support for notifying Drainable objects of a fork
> 
> When forking a gem5 process, some objects need to clean up resources
> (mainly file descriptions) shared between the child and the parent of
> the fork. This changeset adds the notifyFork() method to Drainable,
> which is called in the child process.
> 
> Signed-off-by: Andreas Sandberg 
> [sascha.bisch...@arm.com: Rebased patches onto a newer gem5 version]
> Signed-off-by: Sascha Bischoff 
> Signed-off-by: Andreas Sandberg 
> 
> 
> Diffs
> -
> 
>   src/python/m5/simulate.py 14029d75688d 
>   src/sim/drain.hh 14029d75688d 
> 
> Diff: http://reviews.gem5.org/r/3277/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

[gem5-dev] changeset in gem5: x86: revamp cmpxchg8b/cmpxchg16b implementation

[Alexandru Dutu]

changeset 82bb3ee706b3 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=82bb3ee706b3
description:
x86: revamp cmpxchg8b/cmpxchg16b implementation

The previous implementation did a pair of nested RMW operations,
which isn't compatible with the way that locked RMW operations are
implemented in the cache models.  It was convenient though in that
it didn't require any new micro-ops, and supported cmpxchg16b using
64-bit memory ops.  It also worked in AtomicSimpleCPU where
atomicity was guaranteed by the core and not by the memory system.
It did not work with timing CPU models though.

This new implementation defines new 'split' load and store micro-ops
which allow a single memory operation to use a pair of registers as
the source or destination, then uses a single ldsplit/stsplit RMW
pair to implement cmpxchg.  This patch requires support for 128-bit
memory accesses in the ISA (added via a separate patch) to support
cmpxchg16b.

diffstat:

 src/arch/x86/insts/microldstop.cc|   18 +
 src/arch/x86/insts/microldstop.hh|   86 ++-
 src/arch/x86/isa/insts/general_purpose/semaphores.py |   10 +-
 src/arch/x86/isa/microops/ldstop.isa |  225 +-
 src/arch/x86/isa/operands.isa|2 +
 5 files changed, 302 insertions(+), 39 deletions(-)

diffs (truncated from 554 to 300 lines):

diff -r 9512d2e25f14 -r 82bb3ee706b3 src/arch/x86/insts/microldstop.cc
--- a/src/arch/x86/insts/microldstop.cc Sat Feb 06 17:21:20 2016 -0800
+++ b/src/arch/x86/insts/microldstop.cc Sat Feb 06 17:21:20 2016 -0800
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2007 The Hewlett-Packard Development Company
+ * Copyright (c) 2015 Advanced Micro Devices, Inc.
  * All rights reserved.
  *
  * The license below extends only to copyright in the software and shall
@@ -58,4 +59,21 @@
 addressSize, false);
 return response.str();
 }
+
+std::string LdStSplitOp::generateDisassembly(Addr pc,
+const SymbolTable *symtab) const
+{
+std::stringstream response;
+
+printMnemonic(response, instMnem, mnemonic);
+int baseRegIdx = flags[IsLoad] ? 0 : 2;
+response << "[";
+printDestReg(response, baseRegIdx, dataSize);
+response << ", ";
+printDestReg(response, baseRegIdx+1, dataSize);
+response << "], ";
+printMem(response, segment, scale, index, base, disp,
+addressSize, false);
+return response.str();
+}
 }
diff -r 9512d2e25f14 -r 82bb3ee706b3 src/arch/x86/insts/microldstop.hh
--- a/src/arch/x86/insts/microldstop.hh Sat Feb 06 17:21:20 2016 -0800
+++ b/src/arch/x86/insts/microldstop.hh Sat Feb 06 17:21:20 2016 -0800
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2007 The Hewlett-Packard Development Company
+ * Copyright (c) 2015 Advanced Micro Devices, Inc.
  * All rights reserved.
  *
  * The license below extends only to copyright in the software and shall
@@ -49,9 +50,9 @@
 namespace X86ISA
 {
 /**
- * Base class for load and store ops
+ * Base class for memory ops
  */
-class LdStOp : public X86MicroopBase
+class MemOp : public X86MicroopBase
 {
   protected:
 const uint8_t scale;
@@ -59,13 +60,43 @@
 const RegIndex base;
 const uint64_t disp;
 const uint8_t segment;
-const RegIndex data;
 const uint8_t dataSize;
 const uint8_t addressSize;
 const Request::FlagsType memFlags;
 RegIndex foldOBit, foldABit;
 
 //Constructor
+MemOp(ExtMachInst _machInst,
+const char * mnem, const char * _instMnem,
+uint64_t setFlags,
+uint8_t _scale, InstRegIndex _index, InstRegIndex _base,
+uint64_t _disp, InstRegIndex _segment,
+uint8_t _dataSize, uint8_t _addressSize,
+Request::FlagsType _memFlags,
+OpClass __opClass) :
+X86MicroopBase(_machInst, mnem, _instMnem, setFlags, __opClass),
+scale(_scale), index(_index.idx), base(_base.idx),
+disp(_disp), segment(_segment.idx),
+dataSize(_dataSize), addressSize(_addressSize),
+memFlags(_memFlags | _segment.idx)
+{
+assert(_segment.idx < NUM_SEGMENTREGS);
+foldOBit =
+(dataSize == 1 && !_machInst.rex.present) ? 1 << 6 : 0;
+foldABit =
+(addressSize == 1 && !_machInst.rex.present) ? 1 << 6 : 0;
+}
+};
+
+/**
+ * Base class for load and store ops using one register
+ */
+class LdStOp : public MemOp
+{
+  protected:
+const RegIndex data;
+
+//Constructor
 LdStOp(ExtMachInst _machInst,
 const char * mnem, const char * _instMnem,
 

Re: [gem5-dev] Review Request 3235: stats: organize and clarify resettable stats

[Alexandru Dutu]

> On Jan. 11, 2016, 11:52 p.m., Joel Hestness wrote:
> > src/cpu/kvm/base.cc, line 495
> > 
> >
> > We should probably check with Andreas Sandberg on this one. It looks 
> > like ctrInsts is already a cummulative stat for the KVM CPU. This might be 
> > required by the KVM CPU for fast-forwarding correctness? This could cause 
> > changes in KVM correctness and/or regressions (if any are maintained). 
> > Hopefully, it is harmless to allow the stat to reset, though?
> 
> Lena Olson wrote:
> I think it should be okay -- ctrInsts and numInsts both already existed 
> and I don't modify them, I just changed which is used by totalInsts(), which 
> looks like it never gets called by anything besides the stats stuff. Another 
> pair of eyes wouldn't hurt though.

This seems fine to me both ctrInsts and numInsts are incremented with the value 
from hwInstructions performance counter.


- Alexandru


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


On Jan. 6, 2016, 10:07 p.m., Lena Olson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3235/
> ---
> 
> (Updated Jan. 6, 2016, 10:07 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11230:374d79447577
> ---
> stats: organize and clarify resettable stats
> 
> Some stats (e.g. sim_insts) were traditionally not reset, because they were
> intended for simulator-level measurement. However, some other stats (e.g.
> sim_ticks) WERE reset. In addition, some derived stats used both reset and
> unreset stats in the calculation, resulting in nonsense values. This patch
> creates two sets of overall stats: one set that respects reset, and is useful
> for measuring the simulated program, and one set that does not reset, useful 
> for
> studying the simulator itself.  The non-resettable stats are prefixed with
> "simulator_", as they behave different from other stats.
> 
> 
> Diffs
> -
> 
>   src/arch/null/cpu_dummy.hh 021524c21cbc 
>   src/cpu/BaseCPU.py 021524c21cbc 
>   src/cpu/base.hh 021524c21cbc 
>   src/cpu/checker/cpu.hh 021524c21cbc 
>   src/cpu/kvm/base.hh 021524c21cbc 
>   src/cpu/kvm/base.cc 021524c21cbc 
>   src/cpu/minor/cpu.cc 021524c21cbc 
>   src/cpu/o3/cpu.hh 021524c21cbc 
>   src/cpu/o3/cpu.cc 021524c21cbc 
>   src/cpu/simple/base.hh 021524c21cbc 
>   src/cpu/simple/base.cc 021524c21cbc 
>   src/sim/stat_control.hh 021524c21cbc 
>   src/sim/stat_control.cc 021524c21cbc 
> 
> Diff: http://reviews.gem5.org/r/3235/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lena Olson
> 
>

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

Re: [gem5-dev] Review Request 3207: arm: remote GDB: rationalize structure of register offsets

[Alexandru Dutu]

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

Ship it!


I have been testing this a bit with the hello world program in SE mode for x86. 
It seems fine to me. Thanks for cleaning this up!

- Alexandru Dutu


On Dec. 3, 2015, 9:53 a.m., Boris Shingarov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3207/
> ---
> 
> (Updated Dec. 3, 2015, 9:53 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm: remote GDB: rationalize structure of register offsets
> 
> Currently, the wire format of register values in g- and G-packets is
> modelled using a union of uint8/16/32/64 arrays.  The offset positions
> of each register are expressed as a "register count" scaled according
> to the width of the register in question.  This results in counter-
> intuitive and error-prone "register count arithmetic", and some
> formats would even be altogether unrepresentable in such model, e.g.
> a 64-bit register following a 32-bit one would have a fractional index
> in the regs64 array.
> Another difficulty is that the array is allocated before the actual
> architecture of the workload is known (and therefore before the correct 
> size for the array can be calculated).
> 
> With this patch I propose a simpler mechanism for expressing the
> register set structure.  In the new code, GdbRegCache is an abstract
> class; its subclasses contain straightforward structs reflecting the
> register representation.  The determination whether to use e.g. the
> AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made 
> by polymorphically dispatching getregs() to the concrete subclass.
> The subclass is not instantiated until it is needed for actual
> g-/G-packet processing, when the mode is already known.
> 
> This patch is not meant to be merged in on its own, because it changes
> the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*,
> so as it stands right now, it would break the other architectures.
> In this patch only the base and the ARM code are provided for review;
> once we agree on the structure, I will provide src/arch/*/remote_gdb.*
> for the other architectures; those patches could then be merged in
> together.
> 
> 
> Diffs
> -
> 
>   src/arch/arm/remote_gdb.cc 135c16fa409d 
>   src/arch/mips/remote_gdb.hh 135c16fa409d 
>   src/arch/mips/remote_gdb.cc 135c16fa409d 
>   src/arch/power/remote_gdb.hh 135c16fa409d 
>   src/arch/power/remote_gdb.cc 135c16fa409d 
>   src/arch/sparc/remote_gdb.hh 135c16fa409d 
>   src/arch/sparc/remote_gdb.cc 135c16fa409d 
>   src/arch/x86/remote_gdb.hh 135c16fa409d 
>   src/arch/x86/remote_gdb.cc 135c16fa409d 
>   src/base/remote_gdb.hh 135c16fa409d 
>   src/base/remote_gdb.cc 135c16fa409d 
>   src/arch/alpha/kgdb.h 135c16fa409d 
>   src/arch/alpha/remote_gdb.hh 135c16fa409d 
>   src/arch/alpha/remote_gdb.cc 135c16fa409d 
>   src/arch/arm/remote_gdb.hh 135c16fa409d 
> 
> Diff: http://reviews.gem5.org/r/3207/diff/
> 
> 
> Testing
> ---
> 
> Tested in SE mode with both AArch32 and AArch64, using gdb 7.10 configured 
> with --target=arm-linux-gnueabihf and --target=aarch64-linux-gnu, as well as 
> with our internal gdb RSP client.
> 
> 
> Thanks,
> 
> Boris Shingarov
> 
>

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

Re: [gem5-dev] Review Request 2999: cpu, isa, mem: Adds per-thread wakeup logic

[Alexandru Dutu]

> On July 30, 2015, 11:59 p.m., Steve Reinhardt wrote:
> > so what is the difference between
> > xc->getCpuPtr()->wakeup(xc->threadId());
> > and
> > xc->activate();
> > ?  I think we need to clarify whether or not these are equivalent, and if 
> > so, why we need both, and if not, what the differences are and when you 
> > should be using one vs. the other.
> 
> Mitch Hayenga wrote:
> From what I can tell, wakeup does more...  Making sure the CPU knows to 
> clock itself, setting the adress monitor to reflect that a wakeup occured, 
> etc.  In general wakeup is related to quiesce events (WFI/WFE on ARM).  
> Activate looks to be more just related to setting the thread to be listed as 
> runnable + a few statistics.  Wakeup seems to call activate.

Just looking at the O3 cpu model, FullO3CPU::wakeCPU() and 
FullO3CPU::activateContext(ThreadID tid) are equivalent. Even more, it 
seems that FullO3CPU::wakeup() calls both of them and schedules 2 wakeup 
events instead of one. It might be that I am missing something, though I will 
expose my understanding in a mere effort to sparkle a discussion which will 
clarify some hindered aspects. The intent seems to be for wakeCPU to be used 
whenever there is no particular hardware thread which needs to wakeup (i.e. 
during a drain) and activateContext when the thread to be activated is known. 
As far I can tell wakeup seems bogus and should be replaced with 
activateContext.


- Alexandru


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


On July 30, 2015, 6:47 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2999/
> ---
> 
> (Updated July 30, 2015, 6:47 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changes wakeup functionality so that only specific threads on SMT
> capable cpus are woken.
> 
> 
> Diffs
> -
> 
>   src/mem/abstract_mem.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/checker/cpu.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/kvm/base.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/kvm/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/minor/cpu.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/minor/cpu.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/o3/cpu.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/o3/cpu.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/atomic.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/base.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/timing.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/arch/x86/interrupts.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/base.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/arch/arm/locked_mem.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/arch/null/cpu_dummy.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
> 
> Diff: http://reviews.gem5.org/r/2999/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 2996: cpu: Add per-thread monitors

[Alexandru Dutu]

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


At a first glance this patch seems to make all the modifications that 
http://reviews.gem5.org/r/2857/ does plus enabling monitor for SMT in minor cpu.

- Alexandru Dutu


On July 30, 2015, 6:47 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2996/
> ---
> 
> (Updated July 30, 2015, 6:47 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Adds per-thread address monitors to support FullSystem SMT.
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/checker/cpu.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/minor/exec_context.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/minor/fetch1.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/base.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/exec_context.hh PRE-CREATION 
>   src/cpu/simple/timing.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/timing.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/atomic.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/simple/atomic.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/minor/lsq.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/cpu/o3/cpu.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
> 
> Diff: http://reviews.gem5.org/r/2996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 2994: cpu: Change thread assignents for heterogenous SMT

[Alexandru Dutu]

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



src/sim/system.hh (line 199)
<http://reviews.gem5.org/r/2994/#comment5956>

Not sure I understand why this is needed, it seems one can already figure 
out if it is a multi-threaded system configured by checking numThreads.


- Alexandru Dutu


On July 30, 2015, 6:46 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2994/
> ---
> 
> (Updated July 30, 2015, 6:46 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Trying to run an SE system with varying threads per core (SMT cores + Non-SMT
> cores) caused failures due to the CPU id assignment logic.  The comment
> about thread assignment (worrying about core 0 not having tid 0) seems
> not to be valid given that our configuration scripts initialize them in
> order.
> 
> This removes that constraint so a heterogenously threaded sytem can work.
> 
> 
> Diffs
> -
> 
>   src/cpu/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/System.py 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/system.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/system.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
> 
> Diff: http://reviews.gem5.org/r/2994/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 2979: ruby: eliminate type uint64 and int64

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On July 19, 2015, 11:41 p.m., Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2979/
> ---
> 
> (Updated July 19, 2015, 11:41 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10935:514ddcac7c76
> ---
> ruby: eliminate type uint64 and int64
> 
> These types are being replaced with uint64_t and int64_t.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/directedtest/RubyDirectedTester.hh 3a925f9856b1 
>   src/cpu/testers/rubytest/RubyTester.hh 3a925f9856b1 
>   src/mem/ruby/common/Histogram.hh 3a925f9856b1 
>   src/mem/ruby/common/Histogram.cc 3a925f9856b1 
>   src/mem/ruby/common/TypeDefines.hh 3a925f9856b1 
>   src/mem/ruby/filters/H3BloomFilter.hh 3a925f9856b1 
>   src/mem/ruby/filters/H3BloomFilter.cc 3a925f9856b1 
>   src/mem/ruby/filters/MultiBitSelBloomFilter.hh 3a925f9856b1 
>   src/mem/ruby/filters/MultiBitSelBloomFilter.cc 3a925f9856b1 
>   src/mem/ruby/network/MessageBuffer.hh 3a925f9856b1 
>   src/mem/ruby/profiler/AccessTraceForAddress.hh 3a925f9856b1 
>   src/mem/ruby/profiler/AddressProfiler.hh 3a925f9856b1 
>   src/mem/ruby/profiler/AddressProfiler.cc 3a925f9856b1 
>   src/mem/ruby/profiler/StoreTrace.hh 3a925f9856b1 
>   src/mem/ruby/profiler/StoreTrace.cc 3a925f9856b1 
>   src/mem/ruby/structures/AbstractReplacementPolicy.hh 3a925f9856b1 
>   src/mem/ruby/structures/BankedArray.hh 3a925f9856b1 
>   src/mem/ruby/structures/BankedArray.cc 3a925f9856b1 
>   src/mem/ruby/structures/CacheMemory.hh 3a925f9856b1 
>   src/mem/ruby/structures/CacheMemory.cc 3a925f9856b1 
>   src/mem/ruby/structures/LRUPolicy.hh 3a925f9856b1 
>   src/mem/ruby/structures/PseudoLRUPolicy.hh 3a925f9856b1 
>   src/mem/ruby/structures/RubyMemoryControl.hh 3a925f9856b1 
>   src/mem/ruby/structures/RubyMemoryControl.cc 3a925f9856b1 
>   src/mem/ruby/system/CacheRecorder.hh 3a925f9856b1 
>   src/mem/ruby/system/CacheRecorder.cc 3a925f9856b1 
>   src/mem/ruby/system/System.hh 3a925f9856b1 
>   src/mem/ruby/system/System.cc 3a925f9856b1 
>   src/mem/slicc/symbols/StateMachine.py 3a925f9856b1 
> 
> Diff: http://reviews.gem5.org/r/2979/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

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

Re: [gem5-dev] Review Request 2827: x86: decode instructions with vex prefix

[Alexandru Dutu]

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


I see incremental changes between revisions and plenty of vector instructions 
still unimplemented, is this considered complete or it is still in development?

- Alexandru Dutu


On June 16, 2015, 11:15 p.m., Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2827/
> ---
> 
> (Updated June 16, 2015, 11:15 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10874:65214a5bb5a6
> ---
> x86: decode instructions with vex prefix
> 
> This patch updates the x86 decoder so that it can decode instructions with vex
> prefix. It also updates the isa with opcodes from vex opcode maps 1, 2 and 3.
> Note that none of the instructions have been implemented yet. The
> implementations would be provided in due course of time.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/decoder.hh ebb3d0737aa7 
>   src/arch/x86/decoder.cc ebb3d0737aa7 
>   src/arch/x86/decoder_tables.cc ebb3d0737aa7 
>   src/arch/x86/isa/bitfields.isa ebb3d0737aa7 
>   src/arch/x86/isa/decoder/decoder.isa ebb3d0737aa7 
>   src/arch/x86/isa/decoder/vex_opcodes.isa PRE-CREATION 
>   src/arch/x86/isa_traits.hh ebb3d0737aa7 
>   src/arch/x86/types.hh ebb3d0737aa7 
>   src/arch/x86/types.cc ebb3d0737aa7 
> 
> Diff: http://reviews.gem5.org/r/2827/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

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

Re: [gem5-dev] Review Request 2828: cpu: implements vector registers

[Alexandru Dutu]

> On July 6, 2015, 12:42 p.m., Giacomo Gabrielli wrote:
> > These are my current thoughts about this patch:
> > 
> > 1. My impression is that there is still not enough architectural support to 
> > understand if the new vector register type as it stands can address all the
> > different corner cases efficiently; I'd leave to the wider gem5 community 
> > decide where we want to draw that line...
> > 
> > 2. Legacy SSE requires merging of upper lanes, while AVX does zeroing; also 
> > ARMv8 AArch64 scalar FP and NEON instructions perform zeroing. Assuming that
> > destination vectors are always read is going to introduce unneded 
> > serialization for those ISA extensions if they are going to be ported to 
> > the new scheme, so I'd suggest to avoid to implicitly read on write.
> > Also for cases where merging is required, maybe something smarter should be 
> > done to avoid unneded serialization; without optimizations, any sequence of 
> > x86 FP scalar instructions could be significantly slow compared to real hw 
> > implementations.

Could you please detail a bit the merging issue for legacy SSE?


- Alexandru


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


On July 1, 2015, 10:13 p.m., Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2828/
> ---
> 
> (Updated July 1, 2015, 10:13 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10880:f9a35df0dce5
> ---
> cpu: implements vector registers
> 
> This patch aims at adding vector registers type.  The type is defined
> as a std::array of some fixed number of uint64_ts.  The isa_parser.py
> has been modified to parse vector register operands and generate the
> required code.  Different cpus have vector register files now.
> 
> 
> Diffs
> -
> 
>   src/cpu/StaticInstFlags.py 73d4798871a5 
>   src/cpu/base_dyn_inst.hh 73d4798871a5 
>   src/cpu/checker/cpu.hh 73d4798871a5 
>   src/cpu/checker/cpu_impl.hh 73d4798871a5 
>   src/cpu/checker/thread_context.hh 73d4798871a5 
>   src/cpu/exec_context.hh 73d4798871a5 
>   src/cpu/minor/dyn_inst.cc 73d4798871a5 
>   src/cpu/minor/exec_context.hh 73d4798871a5 
>   src/cpu/minor/scoreboard.hh 73d4798871a5 
>   src/cpu/minor/scoreboard.cc 73d4798871a5 
>   src/cpu/o3/O3CPU.py 73d4798871a5 
>   src/cpu/o3/cpu.hh 73d4798871a5 
>   src/cpu/o3/cpu.cc 73d4798871a5 
>   src/cpu/o3/dyn_inst.hh 73d4798871a5 
>   src/cpu/o3/free_list.hh 73d4798871a5 
>   src/cpu/o3/inst_queue_impl.hh 73d4798871a5 
>   src/cpu/o3/regfile.hh 73d4798871a5 
>   src/cpu/o3/regfile.cc 73d4798871a5 
>   src/cpu/o3/rename_impl.hh 73d4798871a5 
>   src/cpu/o3/rename_map.hh 73d4798871a5 
>   src/cpu/o3/rename_map.cc 73d4798871a5 
>   src/cpu/o3/thread_context.hh 73d4798871a5 
>   src/cpu/o3/thread_context_impl.hh 73d4798871a5 
>   src/cpu/reg_class.hh 73d4798871a5 
>   src/cpu/simple/base.hh 73d4798871a5 
>   src/cpu/simple_thread.hh 73d4798871a5 
>   src/cpu/static_inst.hh 73d4798871a5 
>   src/cpu/thread_context.hh 73d4798871a5 
>   src/cpu/thread_context.cc 73d4798871a5 
>   src/sim/insttracer.hh 73d4798871a5 
>   src/arch/SConscript 73d4798871a5 
>   src/arch/alpha/isa.hh 73d4798871a5 
>   src/arch/alpha/registers.hh 73d4798871a5 
>   src/arch/alpha/utility.cc 73d4798871a5 
>   src/arch/arm/insts/static_inst.cc 73d4798871a5 
>   src/arch/arm/isa.hh 73d4798871a5 
>   src/arch/arm/registers.hh 73d4798871a5 
>   src/arch/arm/utility.cc 73d4798871a5 
>   src/arch/isa_parser.py 73d4798871a5 
>   src/arch/mips/isa.hh 73d4798871a5 
>   src/arch/mips/registers.hh 73d4798871a5 
>   src/arch/mips/utility.cc 73d4798871a5 
>   src/arch/null/registers.hh 73d4798871a5 
>   src/arch/power/isa.hh 73d4798871a5 
>   src/arch/power/registers.hh 73d4798871a5 
>   src/arch/power/utility.cc 73d4798871a5 
>   src/arch/sparc/isa.hh 73d4798871a5 
>   src/arch/sparc/registers.hh 73d4798871a5 
>   src/arch/sparc/utility.cc 73d4798871a5 
>   src/arch/x86/insts/static_inst.cc 73d4798871a5 
>   src/arch/x86/isa.hh 73d4798871a5 
>   src/arch/x86/registers.hh 73d4798871a5 
>   src/arch/x86/utility.cc 73d4798871a5 
> 
> Diff: http://reviews.gem5.org/r/2828/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

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

Re: [gem5-dev] Review Request 2774: cpu, kvm: fix MMIO handling

[Alexandru Dutu]

> On June 18, 2015, 10:07 p.m., Nilay Vaish wrote:
> > Can you give a more detailed example as to what's wrong with the current 
> > version?
> 
> Nikos Nikoleris wrote:
> Forcing kvm to update the register state breaks the m5_readfile, this 
> patch fixes it. The problem is that m5_readfile expects the numbers of bytes 
> that were read from the MMIO to be written to rax which is not happening at 
> the current version.
> 
> When we mark the thread context as dirty, a sync with the kvm state is 
> forced and an ioctl with KVM_SET_REGS is executed. I don't fully understand 
> how the kernel handles the update of the registers in the middle of an MMIO 
> request but it seems that the update to the registers overwrites the value of 
> rax.
> 
> When I wrote this patch I had a look at the pseudoInsts that are 
> implemented through MMIO requests but I missed a couple that explictly change 
> the register state like m5Syscall. So while the patch fixes m5_readfile and 
> probably other pseudoInsts, it breaks m5Syscall and maybe others.

I see, indeed m5Syscall in particular requires the context to be updated in 
order to be able to read RAX which specifies the syscall to perform. However, 
the context needs to updated as it is required for the finalization of MMIO 
operations; I am sure Andreas can have a more detailed comment on this. Are you 
running in SE mode? Maybe the solution to this is to handle differently m5 ops.


- Alexandru


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


On May 11, 2015, 3:52 p.m., Nikos Nikoleris wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2774/
> ---
> 
> (Updated May 11, 2015, 3:52 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10833:9fd3d5837e1e
> ---
> cpu, kvm: Don't flag TC as dirty after m5op
> 
> Currently, none of the m5ops changes the TC, and therefore it cannot be
> dirty. Syncing the TC results in incorrect register state for the
> simulated system, since the kernel will first emulate the instruction
> and then update the guest's register state.
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/base.cc fbdaa08aaa42 
> 
> Diff: http://reviews.gem5.org/r/2774/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nikos Nikoleris
> 
>

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

Re: [gem5-dev] Review Request 2851: cpu: o3: Mapping the ZeroRegister for all hardware threads

[Alexandru Dutu]

> On June 22, 2015, 8:59 p.m., Andreas Sandberg wrote:
> > Looks good. I assume this means that the register ordering problem you 
> > outlined earlier turned out to be a non-issue.

Actually, while doing more testing I remembered that this ordering has to be 
enforced as the rest of the code that handles zero register exceptions assumes 
the physical register assigned for the it is the same with the architectural 
register. Is there a way to revert to the previous revision in review board or 
discard the current one?


- Alexandru


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


On June 22, 2015, 6:44 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2851/
> ---
> 
> (Updated June 22, 2015, 6:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10864:716172760d78
> ---
> cpu: o3: Mapping the ZeroRegister for all hardware threads
> This patch helps enabling SMT in x86 by mapping the ZeroRegister to one
> physical register across all hardware threads.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/cpu.cc 9141d87c7f71099d6256b179b7819eab878cbb67 
> 
> Diff: http://reviews.gem5.org/r/2851/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed for all ISAs.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2855: cpu: o3: Fetch stage updates for hw threads priority list

[Alexandru Dutu]

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

(Updated June 22, 2015, 8:59 p.m.)


Review request for Default.


Changes
---

Refactored startupStage and resetStage.


Repository: gem5


Description (updated)
---

Changeset 10866:616c230e9722
---
cpu: o3: Fetch stage updates for hw threads priority list
This patch makes sure the priority_list in the fetch stage is kept in sync
with suspendContext and activateContext calls.


Diffs (updated)
-

  src/cpu/o3/cpu.cc 9141d87c7f71099d6256b179b7819eab878cbb67 
  src/cpu/o3/fetch.hh 9141d87c7f71099d6256b179b7819eab878cbb67 
  src/cpu/o3/fetch_impl.hh 9141d87c7f71099d6256b179b7819eab878cbb67 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2856: cpu: o3: Commit stage updates for hw threads priority list

[Alexandru Dutu]

> On June 21, 2015, 6:18 a.m., Nilay Vaish wrote:
> > src/cpu/o3/cpu.cc, line 741
> > <http://reviews.gem5.org/r/2856/diff/1/?file=45659#file45659line741>
> >
> > Why do we have different names for the functions called on Fetch and 
> > Commit stages?

For the fetch stage there already was a function which was handleing status 
update, however just for thread 0. So that function needed to be updated and I 
kept the name. For commit there is no notion of a quiesce state, so I chose a 
different name that makes sense for this stage.


- Alexandru


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


On May 28, 2015, 3:40 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2856/
> ---
> 
> (Updated May 28, 2015, 3:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10862:c32578991199
> ---
> cpu: o3: Commit stage updates for hw threads priority list
> This patch makes sure the priority_list in the fetch stage is kept in sync
> with suspendContext and activateContext calls.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/commit.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/commit_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2856/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed for all ISAs.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2851: cpu: o3: Mapping the ZeroRegister for all hardware threads

[Alexandru Dutu]

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

(Updated June 22, 2015, 6:44 p.m.)


Review request for Default.


Changes
---

Actually, giving this a second thought I like better the compressed version of 
this patch after Andreas's suggestion. Initially I was overly concerned with 
the unorderred initial mapping this will bring and the extra debugging 
confussion, however initial mappings change and there should not be much 
debugging on the register renaming front. So a compact code is the way to go.


Repository: gem5


Description (updated)
---

Changeset 10864:716172760d78
---
cpu: o3: Mapping the ZeroRegister for all hardware threads
This patch helps enabling SMT in x86 by mapping the ZeroRegister to one
physical register across all hardware threads.


Diffs (updated)
-

  src/cpu/o3/cpu.cc 9141d87c7f71099d6256b179b7819eab878cbb67 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2849: config, SMT: Enabling SMT for multi-threaded programs

[Alexandru Dutu]

> On June 15, 2015, 7:28 p.m., Andreas Sandberg wrote:
> > configs/example/se.py, line 237
> > <http://reviews.gem5.org/r/2849/diff/2/?file=45922#file45922line237>
> >
> > This seems a bit smelly. Shouldn't you at least provide a warning if 
> > this happens? I'd almost consider it a fatal error.

I don't see a good reason to provide a warning. Just because we are 
initializing the cpu object with a bogus process it does not mean that the 
process will start executing. Clone will make sure later on that the process is 
switched with a valid one and only then execution is started.


> On June 15, 2015, 7:28 p.m., Andreas Sandberg wrote:
> > src/cpu/o3/cpu.cc, line 364
> > <http://reviews.gem5.org/r/2849/diff/2/?file=45923#file45923line364>
> >
> > Will this still be empty? Won't this just reuse an existing workload?

Again, this will not start executing. Clone will make sure the right process 
will execute. Unfortunately, the CPU model constructor requires a workload to 
be assigned and passing a NULL will cause problems for other threads when the 
TLBs are initialize if I remember correctly.


- Alexandru


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


On June 1, 2015, 2:07 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2849/
> ---
> 
> (Updated June 1, 2015, 2:07 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10858:cc93e6609fc3
> ---
> config, SMT: Enabling SMT for multi-threaded programs
> This patch helps enabling SMT by adding a new argument to specify the number
> of hardware threads.
> 
> 
> Diffs
> -
> 
>   configs/common/Options.py d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   configs/example/se.py d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/inst_queue_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2849/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed for all ISAs.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2851: cpu: o3: Mapping the ZeroRegister for all hardware threads

[Alexandru Dutu]

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



src/cpu/o3/cpu.cc (line 295)
<http://reviews.gem5.org/r/2851/#comment5565>

Initially, physical register are assigned consecutively to architectural 
register. We want to have just one physical register for all hardware threads. 
It seems that moving this outside the loop will accomplish the same behavior.



src/cpu/o3/cpu.cc (line 300)
<http://reviews.gem5.org/r/2851/#comment5566>

This does not take care of different threads.


- Alexandru Dutu


On May 28, 2015, 3:38 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2851/
> ---
> 
> (Updated May 28, 2015, 3:38 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10859:9c783a1367cd
> ---
> cpu: o3: Mapping the ZeroRegister for all hardware threads
> This patch helps enabling SMT in x86 by mapping the ZeroRegister to one
> physical register across all hardware threads.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2851/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed for all ISAs.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2849: config, SMT: Enabling SMT for multi-threaded programs

[Alexandru Dutu]

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

(Updated June 1, 2015, 2:07 p.m.)


Review request for Default.


Changes
---

Resubmitting because of broken diffs.


Repository: gem5


Description (updated)
---

Changeset 10858:cc93e6609fc3
---
config, SMT: Enabling SMT for multi-threaded programs
This patch helps enabling SMT by adding a new argument to specify the number
of hardware threads.


Diffs (updated)
-

  configs/common/Options.py d02b45a554b52c68cce41e1b3895fb8582a639dd 
  configs/example/se.py d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/inst_queue_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2852: x86, o3: Enabling x86 TLBs for multiple hardware threads

[Alexandru Dutu]

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

(Updated May 29, 2015, 9:06 p.m.)


Review request for Default.


Changes
---

Updating commit message.


Repository: gem5


Description (updated)
---

Changeset 10860:f4565ce598dd
---
x86, o3: Enabling x86 TLBs for multiple hardware threads
This patch extends the x86 TLB to be shared among multiple hardware threads.
Its size will represent the total number of TLB entries that can be allocated
to all threads.


Diffs
-

  src/arch/x86/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/tlb.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/generic/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/isa.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable_walker.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2852: x86, o3: Enabling x86 TLBs for multiple hardware threads

[Alexandru Dutu]

> On May 29, 2015, 4:25 p.m., Joel Hestness wrote:
> > I'm confused about the commit message: Based on the handling of the 
> > freeList and evictions, it seems like the only limit on TLB entries per 
> > thread is the total TLB size, so there isn't a statically set number of 
> > entries per thread. Am I missing something? If not, can you please fix the 
> > commit message?

Actually the commit message has not got updated to reflect the changes in the 
code. Thanks for pointing this!


- Alexandru


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


On May 28, 2015, 3:38 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2852/
> ---
> 
> (Updated May 28, 2015, 3:38 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10860:f4565ce598dd
> ---
> x86, o3: Enabling x86 TLBs for multiple hardware threads
> This patch extends the x86 TLB to be shared among multiple hardware threads.
> Its size will represent the number of all TLB entries that can be allocated to
> all threads, therefore there is statically assigned number of entries per
> thread.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/tlb.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/generic/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/isa.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/pagetable.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/pagetable.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/pagetable_walker.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2852/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed for all ISAs.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2846: cpu: o3: Merging haltContext with suspendContext

[Alexandru Dutu]

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

(Updated May 28, 2015, 7:02 p.m.)


Review request for Default.


Changes
---

Solved the first 2 issues Joel raised.


Repository: gem5


Description (updated)
---

Changeset 10857:5dd0809b9662
---
cpu: o3: Merging haltContext with suspendContext
This patch improves suspendContext by flushing the pipeline, which frees
resources for other hardware threads. Secondly, it makes haltContext call
suspendContext which is not freeing architectural registers mappings on halt.
Something that haltContext previously did and was not realistic.
For example, in SMT implementations the architectural registers for a
particular hardware thread will always have mapped some physical registers and
having one thread finish execution will never create more available physical
registers for other hardware threads as there will be scheduled a different
software thread to execute on that hardware thread anyway.
As a consequence, this patch helps enabling SMT in x86 by not putting the
physical registered mapped to the ZeroRegister on the freeList for a different
thread to pick up when one of the threads has finished executing and called
exit.


Diffs (updated)
-

  src/arch/x86/isa/microops/specop.isa d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/decode_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/fetch_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2846: cpu: o3: Merging haltContext with suspendContext

[Alexandru Dutu]

> On May 27, 2015, 4:21 p.m., Joel Hestness wrote:
> > src/cpu/o3/cpu.cc, line 754
> > <http://reviews.gem5.org/r/2846/diff/1/?file=45420#file45420line754>
> >
> > Is there a reason not to include code to clear stalls within 
> > fetch.squash() and decode.squash()? The stalls[tid] arrays are only 
> > accessed within their respective pipe stages and set/reset based on signals 
> > from adjacent pipe stages. Exposing them publicly through the removeStall() 
> > functions seems like it breaks the existing pipe stage stall signalling 
> > abstraction.
> 
> Alexandru Dutu wrote:
> It seems that there are other stall signals exposed publicly (e.g. 
> drainStall()). The main reason these can not go into the squash method is 
> that there are scenarious when squashes w/ decode and fetchs stall signals 
> enabled seem to be required. This seems a bit unintuitive and haven't digged 
> into why this is happening, however having these stall signals reset in 
> squash causes the pipeline to stop executing at some point.

Actually, this can be placed in the squash functions. The reason it was not 
working when I tried it is that decode has two overloaded squash functions and 
I was reseting the signal just in one of them.


- Alexandru


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


On May 26, 2015, 4:45 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2846/
> ---
> 
> (Updated May 26, 2015, 4:45 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10858:2fb10c49dd93
> ---
> cpu: o3: Merging haltContext with suspendContext
> This patch improves suspendContext by flushing the pipeline, which frees
> resources for other hardware threads. Secondly, it makes haltContext call
> suspendContext which is not freeing architectural registers mappings on halt.
> Something that haltContext previously did and was not realistic.
> For example, in SMT implementations the architectural registers for a
> particular hardware thread will always have mapped some physical registers and
> having one thread finish execution will never create more available physical
> registers for other hardware threads as there will be scheduled a different
> software thread to execute on that hardware thread anyway.
> As a consequence, this patch helps enabling SMT in x86 by not putting the
> physical registered mapped to the ZeroRegister on the freeList for a different
> thread to pick up when one of the threads has finished executing and called
> exit.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/fetch_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/isa/microops/specop.isa 
> d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/decode.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/decode_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/fetch.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2846/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

Re: [gem5-dev] Review Request 2846: cpu: o3: Merging haltContext with suspendContext

[Alexandru Dutu]

> On May 27, 2015, 4:21 p.m., Joel Hestness wrote:
> >

Thanks for the insightful comments Joel!


> On May 27, 2015, 4:21 p.m., Joel Hestness wrote:
> > src/arch/x86/isa/microops/specop.isa, line 70
> > <http://reviews.gem5.org/r/2846/diff/1/?file=45418#file45418line70>
> >
> > Can you please set flags consistently for this instruction? Either move 
> > this up into the X86MicroopBase constructor call, or move the setFlags bits 
> > (IsNonSpeculative, IsQuiesce) down into the body here to be consistent with 
> > this line of code? I don't see any other examples of flag setting in 
> > micro-op code, but x86 macro-op code seems to follow the latter convention.

Yeah, having them set in the MicroHalt constructor instead of in the 
constructor call of X86MicroopBase seems cleaner as well. Thanks for catching 
this!


> On May 27, 2015, 4:21 p.m., Joel Hestness wrote:
> > src/cpu/o3/fetch_impl.hh, line 996
> > <http://reviews.gem5.org/r/2846/diff/1/?file=45424#file45424line996>
> >
> > Removing this assertion seems to be a symptom of changing the 
> > abstraction for communicating stalls between pipe stages.

Hypothetically, even if DefaultFetch::doSquash() resets the stall signal from 
decode, there still is a situation when decode is unblocked and there is no 
need to assert the decode stall signal.


> On May 27, 2015, 4:21 p.m., Joel Hestness wrote:
> > src/cpu/o3/cpu.cc, line 754
> > <http://reviews.gem5.org/r/2846/diff/1/?file=45420#file45420line754>
> >
> > Is there a reason not to include code to clear stalls within 
> > fetch.squash() and decode.squash()? The stalls[tid] arrays are only 
> > accessed within their respective pipe stages and set/reset based on signals 
> > from adjacent pipe stages. Exposing them publicly through the removeStall() 
> > functions seems like it breaks the existing pipe stage stall signalling 
> > abstraction.

It seems that there are other stall signals exposed publicly (e.g. 
drainStall()). The main reason these can not go into the squash method is that 
there are scenarious when squashes w/ decode and fetchs stall signals enabled 
seem to be required. This seems a bit unintuitive and haven't digged into why 
this is happening, however having these stall signals reset in squash causes 
the pipeline to stop executing at some point.


- Alexandru


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


On May 26, 2015, 4:45 p.m., Alexandru Dutu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2846/
> ---
> 
> (Updated May 26, 2015, 4:45 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10858:2fb10c49dd93
> ---
> cpu: o3: Merging haltContext with suspendContext
> This patch improves suspendContext by flushing the pipeline, which frees
> resources for other hardware threads. Secondly, it makes haltContext call
> suspendContext which is not freeing architectural registers mappings on halt.
> Something that haltContext previously did and was not realistic.
> For example, in SMT implementations the architectural registers for a
> particular hardware thread will always have mapped some physical registers and
> having one thread finish execution will never create more available physical
> registers for other hardware threads as there will be scheduled a different
> software thread to execute on that hardware thread anyway.
> As a consequence, this patch helps enabling SMT in x86 by not putting the
> physical registered mapped to the ZeroRegister on the freeList for a different
> thread to pick up when one of the threads has finished executing and called
> exit.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/fetch_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/arch/x86/isa/microops/specop.isa 
> d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/decode.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/decode_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
>   src/cpu/o3/fetch.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
> 
> Diff: http://reviews.gem5.org/r/2846/diff/
> 
> 
> Testing
> ---
> 
> Quick regressions passed.
> 
> 
> Thanks,
> 
> Alexandru Dutu
> 
>

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

[gem5-dev] Review Request 2857: cpu: Adding AddressMonitor structs for every hardware thread

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10863:27ededc60d38
---
cpu: Adding AddressMonitor structs for every hardware thread
This patch builds toward having the ability to mwait on a ThreadContext,
rather then on a CPU core. This is achieved by having a vector of
AddressMonitor structs in BaseCPU.


Diffs
-

  src/cpu/base.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/base.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/base_dyn_inst.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/checker/cpu.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/minor/exec_context.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/simple/atomic.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/simple/base.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/simple/timing.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2858: cpu, o3: Checking AddressMonitor structures on every store for SMT

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10864:d90ce6b66612
---
cpu, o3: Checking AddressMonitor structures on every store for SMT
This patch adds the ability to run binaries which contain mwait on systems
configured with SMT. It does so by checking the AddressMonitor structures on
every store.


Diffs
-

  src/cpu/base.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/lsq_unit_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2859: cpu, o3: Remove assertion on buffer from rename being empty

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10865:ea6f1011ab07
---
cpu, o3: Remove assertion on buffer from rename being empty
This patch removes assertion in sortInsts() regarding the insts buffer from
rename to issue being empty. The assertion makes little sense as insts, the
queue used to buffer instructions from rename to iew should not be empty in
every tick of iew. Issue can be slower than rename.


Diffs
-

  src/cpu/o3/iew_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2855: cpu: o3: Fetch stage updates for hw threads priority list

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10861:2a0f7f75fe9c
---
cpu: o3: Fetch stage updates for hw threads priority list
This patch makes sure the priority_list in the fetch stage is kept in sync
with suspendContext and activateContext calls.


Diffs
-

  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/fetch.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/fetch_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2856: cpu: o3: Commit stage updates for hw threads priority list

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10862:c32578991199
---
cpu: o3: Commit stage updates for hw threads priority list
This patch makes sure the priority_list in the fetch stage is kept in sync
with suspendContext and activateContext calls.


Diffs
-

  src/cpu/o3/commit.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/commit_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2860: x86: Mwait reimplementation

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10866:d60219f33c24
---
x86: Mwait reimplementation
This patch gets rid of the MicroHalt microop mwait was using in its
implementation.


Diffs
-

  src/arch/x86/isa/decoder/two_byte_opcodes.isa 
d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/isa/formats/monitor_mwait.isa 
d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2853: x86, o3: Enabling x86 TLBs for multiple hardware threads

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10860:f4565ce598dd
---
x86, o3: Enabling x86 TLBs for multiple hardware threads
This patch extends the x86 TLB to be shared among multiple hardware threads.
Its size will represent the number of all TLB entries that can be allocated to
all threads, therefore there is statically assigned number of entries per
thread.


Diffs
-

  src/arch/generic/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/isa.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable_walker.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/tlb.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2852: x86, o3: Enabling x86 TLBs for multiple hardware threads

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10860:f4565ce598dd
---
x86, o3: Enabling x86 TLBs for multiple hardware threads
This patch extends the x86 TLB to be shared among multiple hardware threads.
Its size will represent the number of all TLB entries that can be allocated to
all threads, therefore there is statically assigned number of entries per
thread.


Diffs
-

  src/arch/x86/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/tlb.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/generic/tlb.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/isa.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/pagetable_walker.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2851: cpu: o3: Mapping the ZeroRegister for all hardware threads

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10859:9c783a1367cd
---
cpu: o3: Mapping the ZeroRegister for all hardware threads
This patch helps enabling SMT in x86 by mapping the ZeroRegister to one
physical register across all hardware threads.


Diffs
-

  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2849: config, SMT: Enabling SMT for multi-threaded programs

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10858:ea9cc1cc8ec4
---
config, SMT: Enabling SMT for multi-threaded programs
This patch helps enabling SMT by adding a new argument to specify the number
of hardware threads.


Diffs
-

  configs/common/Options.py 8d5d12993c63ab032b292ccf3d63d101d2f5ad4b 
  configs/example/se.py 8d5d12993c63ab032b292ccf3d63d101d2f5ad4b 
  src/cpu/o3/cpu.cc 8d5d12993c63ab032b292ccf3d63d101d2f5ad4b 
  src/cpu/o3/inst_queue_impl.hh 8d5d12993c63ab032b292ccf3d63d101d2f5ad4b 

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


Testing
---

Quick regressions passed for all ISAs.


Thanks,

Alexandru Dutu

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

[gem5-dev] Review Request 2846: cpu: o3: Merging haltContext with suspendContext

[Alexandru Dutu]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 10858:2fb10c49dd93
---
cpu: o3: Merging haltContext with suspendContext
This patch improves suspendContext by flushing the pipeline, which frees
resources for other hardware threads. Secondly, it makes haltContext call
suspendContext which is not freeing architectural registers mappings on halt.
Something that haltContext previously did and was not realistic.
For example, in SMT implementations the architectural registers for a
particular hardware thread will always have mapped some physical registers and
having one thread finish execution will never create more available physical
registers for other hardware threads as there will be scheduled a different
software thread to execute on that hardware thread anyway.
As a consequence, this patch helps enabling SMT in x86 by not putting the
physical registered mapped to the ZeroRegister on the freeList for a different
thread to pick up when one of the threads has finished executing and called
exit.


Diffs
-

  src/cpu/o3/fetch_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/arch/x86/isa/microops/specop.isa d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/cpu.cc d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/decode.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/decode_impl.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 
  src/cpu/o3/fetch.hh d02b45a554b52c68cce41e1b3895fb8582a639dd 

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


Testing
---

Quick regressions passed.


Thanks,

Alexandru Dutu

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

Re: [gem5-dev] Review Request 2764: arm: Get rid of pointless have_generic_timer param

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On May 7, 2015, 11 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2764/
> ---
> 
> (Updated May 7, 2015, 11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10841:5bbc826fb52e
> ---
> arm: Get rid of pointless have_generic_timer param
> 
> The ArmSystem class has a parameter to indicate whether it is
> configured to use the generic timer extension or not. This parameter
> doesn't affect any feature flags in the current implementation and is
> therefore completely unnecessary. In fact, we usually don't set it
> even if a system has a generic timer. If we ever need to check if
> there is a generic timer present, we should just request a pointer and
> check if it is non-null instead.
> 
> 
> Diffs
> -
> 
>   src/arch/arm/ArmSystem.py fbdaa08aaa42 
>   src/arch/arm/system.hh fbdaa08aaa42 
>   src/arch/arm/system.cc fbdaa08aaa42 
> 
> Diff: http://reviews.gem5.org/r/2764/diff/
> 
> 
> Testing
> ---
> 
> ARM regressions pass. All backends build.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 2762: dev, arm: Refactor and clean up the generic timer model

[Alexandru Dutu]

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



src/dev/arm/generic_timer.hh (line 70)
<http://reviews.gem5.org/r/2762/#comment5478>

Would it be possible to change the name to something a bit simpler?


Now I see where GIC can be useful, neat\!

- Alexandru Dutu


On May 7, 2015, 10:59 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2762/
> ---
> 
> (Updated May 7, 2015, 10:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10839:97a0dceec537
> ---
> dev, arm: Refactor and clean up the generic timer model
> 
> This changeset cleans up the generic timer a bit and moves most of the
> register juggling from the ISA code into a separate class in the same
> source file as the rest of the generic timer. It also removes the
> assumption that there is always 8 or fewer CPUs in the system. Instead
> of having a fixed limit, we now instantiate per-core timers as they
> are requested. This is all in preparation for other patches that add
> support for virtual timers and a memory mapped interface.
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa.hh fbdaa08aaa42 
>   src/arch/arm/isa.cc fbdaa08aaa42 
>   src/arch/arm/system.hh fbdaa08aaa42 
>   src/arch/arm/system.cc fbdaa08aaa42 
>   src/dev/arm/RealView.py fbdaa08aaa42 
>   src/dev/arm/generic_timer.hh fbdaa08aaa42 
>   src/dev/arm/generic_timer.cc fbdaa08aaa42 
> 
> Diff: http://reviews.gem5.org/r/2762/diff/
> 
> 
> Testing
> ---
> 
> ARM regressions pass. All backends build.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 2838: kvm: Handle inst events at the current instruction count

[Alexandru Dutu]

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



src/cpu/kvm/base.cc (line 539)
<http://reviews.gem5.org/r/2838/#comment5477>

"complete any pending IO" right?


- Alexandru Dutu


On May 18, 2015, 12:31 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2838/
> ---
> 
> (Updated May 18, 2015, 12:31 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10850:2dca1e24a806
> ---
> kvm: Handle inst events at the current instruction count
> 
> There are cases (particularly when attaching GDB) when instruction
> events are scheduled at the current instruction tick. This used to
> trigger an assertion error in kvm. This changeset adds a check for
> this condition and forces KVM to do a quick entry that completes any
> pending IO operations, but does not execute any new instructions,
> before servicing the event. We could check if we need to enter KVM at
> all, but forcing a quick entry is makes the code slightly cleaner and
> does not hurt correctness (performance is hardly an issue in these
> cases).
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/base.cc 9b424e7adac5 
> 
> Diff: http://reviews.gem5.org/r/2838/diff/
> 
> 
> Testing
> ---
> 
> Extensively tested with kvm and gdb on aarch64. Doesn't fixes the assertion 
> error mentioned in the description.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 2837: kvm, arm, dev: Add an in-kernel GIC implementation

[Alexandru Dutu]

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



src/cpu/kvm/vm.hh (line 265)
<http://reviews.gem5.org/r/2837/#comment5476>

Should this go in a different file?


Just curious what is the usage scenario for this, it seems that it can be used 
to interrupt the VM even if there is no physical interrupt.

- Alexandru Dutu


On May 18, 2015, 12:29 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2837/
> ---
> 
> (Updated May 18, 2015, 12:29 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10849:d59f9d2d90f7
> ---
> kvm, arm, dev: Add an in-kernel GIC implementation
> 
> This changeset adds a GIC implementation that uses the kernel's
> built-in support for simulating the interrupt controller. Since there
> is currently no support for state transfer between gem5 and the
> kernel, the device model does not support serialization and CPU
> switching (which would require switching to a gem5-simulated GIC).
> 
> 
> Diffs
> -
> 
>   src/arch/arm/kvm/KvmGic.py PRE-CREATION 
>   src/arch/arm/kvm/SConscript PRE-CREATION 
>   src/arch/arm/kvm/gic.hh PRE-CREATION 
>   src/arch/arm/kvm/gic.cc PRE-CREATION 
>   src/cpu/kvm/vm.hh 9b424e7adac5 
>   src/cpu/kvm/vm.cc 9b424e7adac5 
> 
> Diff: http://reviews.gem5.org/r/2837/diff/
> 
> 
> Testing
> ---
> 
> Tested with the gem5's aarch64 kvm implementation (see separate review 
> request). Boots Linux and interacts nicely with the interactive console. 
> Note: The kernel requires simulated devices to be well behaved and clear 
> interrupts. This means that the PCI IDE device model doesn't work. Use the 
> VirtIO block device instead.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 2759: kvm: Remove KvmVM APIs for in-kernel IRQ chip simulation

[Alexandru Dutu]

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


Will this wrapper encompass BaseKvmCPU::kvmInterrupt as well or is it meant to 
be just for in-kernel interrupts?

- Alexandru Dutu


On May 7, 2015, 10:54 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2759/
> ---
> 
> (Updated May 7, 2015, 10:54 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10836:24b2d17c9b85
> ---
> kvm: Remove KvmVM APIs for in-kernel IRQ chip simulation
> 
> The APIs for in-kernel IRQ chip simulation in the KvmVM class are
> currently unused and use deprecated KVM APIs. This changeset removes
> these APIs. A future patch will add a wrapper around the new, more
> general, in-kernel device emulation API.
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/vm.hh fbdaa08aaa42 
>   src/cpu/kvm/vm.cc fbdaa08aaa42 
> 
> Diff: http://reviews.gem5.org/r/2759/diff/
> 
> 
> Testing
> ---
> 
> ARM regressions pass. All backends build. Tested building with KVM support on 
> x86 and ARMv8.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

Re: [gem5-dev] Review Request 2760: kvm, x86: Guard x86-specific APIs in KvmVM

[Alexandru Dutu]

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

Ship it!


Ship It!

- Alexandru Dutu


On May 7, 2015, 10:55 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2760/
> ---
> 
> (Updated May 7, 2015, 10:55 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10837:40beaa8357a6
> ---
> kvm, x86: Guard x86-specific APIs in KvmVM
> 
> Protect x86-specific APIs in KvmVM with compile-time guards to avoid
> breaking ARM builds.
> 
> 
> Diffs
> -
> 
>   src/cpu/kvm/vm.hh fbdaa08aaa42 
>   src/cpu/kvm/vm.cc fbdaa08aaa42 
> 
> Diff: http://reviews.gem5.org/r/2760/diff/
> 
> 
> Testing
> ---
> 
> ARM regressions pass. All backends build. Tested building with KVM support on 
> x86 and ARMv8.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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