changeset 94901e131a7f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=94901e131a7f
description:
cpu: Idle CPU status logic revised
This patch sets the CPU status to idle when the last active thread gets
suspended.
diffstat:
src/cpu/o3/cpu.cc | 7
On Jan. 21, 2015, 8:23 a.m., Andreas Hansson wrote:
It looks sensible, but I wonder if we could not somehow move all this to
the BaseCPU?
Also, what do these states mean for an SMT? Is there a need for threadIdle
and coreIdle?
It seems that this is a special case for cores that
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2549/#review5778
---
It seems that this patch is breaking ALPHA/quick/se regressions;
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2607/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
There is some issue with AMD platforms. A test that used to run in 30 sec
is not finishing.
mike upton wrote:
hello world passes. SPEC apps hang.
Gabe Black wrote:
Can you identify where it's getting stuck? It could be
On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
There is some issue with AMD platforms. A test that used to run in 30 sec
is not finishing.
mike upton wrote:
hello world passes. SPEC apps hang.
Gabe Black wrote:
Can you identify where it's getting stuck? It could be
changeset fe2e2f06a7c8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=fe2e2f06a7c8
description:
x86: Segment initialization to support KvmCPU in SE
This patch sets up low and high privilege code and data segments and
places them
in the following
changeset 1e3b3c7a0cba in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1e3b3c7a0cba
description:
mem: Page Table long lines
Trimmed down all the lines greater than 78 characters.
diffstat:
src/mem/multi_level_page_table.hh | 3 ++-
changeset c1ad57c53a36 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c1ad57c53a36
description:
kvm, x86: Adding support for SE mode execution
This patch adds methods in KvmCPU model to handle KVM exits caused by
syscall
instructions and page faults.
changeset 3a17e8c018b4 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3a17e8c018b4
description:
mem: Multi Level Page Table bug fix
The multi level page table was giving false positives for already mapped
translations. This patch fixes the bogus
changeset 426665ec11a9 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=426665ec11a9
description:
mem: Page Table map api modification
This patch adds uncacheable/cacheable and read-only/read-write
attributes to
the map method of PageTableBase. It
changeset 9f456b5cc474 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=9f456b5cc474
description:
config, kvm: Enabling KvmCPU in SE mode
This patch modifies se.py such that it can now use kvm cpu model.
diffstat:
configs/example/se.py | 16
changeset 41ebfed1dc89 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=41ebfed1dc89
description:
cpuid, x86: Enabling more features in CPUid
Adding more features in the CPUid with the purpose of supporting
running the
KvmCPU in SE mode.
diffstat:
On Nov. 18, 2014, 10:43 p.m., Gabe Black wrote:
util/m5/m5ops.h, line 57
http://reviews.gem5.org/r/2313/diff/4/?file=42082#file42082line57
Why do we need psuedo ops for syscalls when there are actual syscall
instructions? The same goes for page faults. I'm not saying I know that
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2313/
---
(Updated Nov. 20, 2014, 12:36 a.m.)
Review request for Default.
Changes
---
On Nov. 18, 2014, 4:30 p.m., Andreas Hansson wrote:
src/mem/page_table.hh, line 95
http://reviews.gem5.org/r/2462/diff/1/?file=42140#file42140line95
I'd suggest to specify the storage type (uint32_t)
Thought it is the only enum that will have an explicit storage type.
- Alexandru
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2462/
---
(Updated Nov. 20, 2014, 6:27 a.m.)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2462/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2313/
---
(Updated Sept. 30, 2014, 4:21 p.m.)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2460/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2461/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On Sept. 30, 2014, 7:57 p.m., Andreas Hansson wrote:
Should this not be folded into the original patch?
I am not sure, that patch has already been commited. I thought once commited, a
patch becomes a commit and one can't modify it.
- Alexandru
On Sept. 30, 2014, 8:43 p.m., Andreas Hansson wrote:
src/mem/multi_level_page_table_impl.hh, line 151
http://reviews.gem5.org/r/2460/diff/1/?file=42083#file42083line151
Is fatal really suitable here? Is it a user error, or should it rather
be a panic?
I interpret this as the
On Sept. 30, 2014, 8:45 p.m., Andreas Hansson wrote:
src/mem/multi_level_page_table_impl.hh, line 181
http://reviews.gem5.org/r/2461/diff/1/?file=42085#file42085line181
I'm not sure I'm a massive fan...but then again, I don't quite know
what to suggest instead.
Steve Reinhardt
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2461/
---
(Updated Sept. 30, 2014, 9:25 p.m.)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2313/
---
(Updated Sept. 16, 2014, 3:34 p.m.)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2322/
---
(Updated Sept. 16, 2014, 3:37 p.m.)
Review request for Default.
Changes
---
On Aug. 14, 2014, 10:05 a.m., Andreas Sandberg wrote:
I'm really not happy about the use of kvm-specific ports magic here. It
would have been nicer having a m5ops based interface that just passes the
fault/syscall to the arch-specific code from any CPU model that uses the
m5ops
On Aug. 14, 2014, 10:05 a.m., Andreas Sandberg wrote:
I'm really not happy about the use of kvm-specific ports magic here. It
would have been nicer having a m5ops based interface that just passes the
fault/syscall to the arch-specific code from any CPU model that uses the
m5ops
On Aug. 14, 2014, 10:05 a.m., Andreas Sandberg wrote:
I'm really not happy about the use of kvm-specific ports magic here. It
would have been nicer having a m5ops based interface that just passes the
fault/syscall to the arch-specific code from any CPU model that uses the
m5ops
On Aug. 14, 2014, 9:28 a.m., Andreas Sandberg wrote:
src/mem/multi_level_page_table.hh, line 57
http://reviews.gem5.org/r/2312/diff/2/?file=40429#file40429line57
In general, I prefer having a abstract base classes for interfaces
since that makes documentation and compile-time
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2312/
---
(Updated Aug. 25, 2014, 9:08 p.m.)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2319/
---
(Updated Aug. 25, 2014, 9:10 p.m.)
Review request for Default.
Repository: gem5
On Aug. 14, 2014, 10:05 a.m., Andreas Sandberg wrote:
I'm really not happy about the use of kvm-specific ports magic here. It
would have been nicer having a m5ops based interface that just passes the
fault/syscall to the arch-specific code from any CPU model that uses the
m5ops
On Aug. 14, 2014, 9:28 a.m., Andreas Sandberg wrote:
src/mem/page_table.hh, line 71
http://reviews.gem5.org/r/2312/diff/2/?file=40432#file40432line71
Any particular reason why these aren't const any more? I kinda like
having constants declared as such since that means the
On Aug. 14, 2014, 9:22 a.m., Andreas Sandberg wrote:
src/arch/x86/pagetable.hh, line 169
http://reviews.gem5.org/r/2319/diff/1/?file=40442#file40442line169
I'd prefer to see this refactored so that the X86 architectural page
table inherits from the multi-level page table instead.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2322/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On July 14, 2014, 4:42 p.m., Andreas Sandberg wrote:
I have two high-level comments that need to be fixed:
* This is should be four different commits (configuration, CPUID updates,
segment initialization, kvm, process).
* Write a proper commit message (see
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2319/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On July 14, 2014, 5:36 p.m., Andreas Sandberg wrote:
In general, I like the idea of having a proper, architected, page table in
SE-mode. Long-term, this could hopefully mean that we can get rid of many
of the differences between SE- and FS-mode.
High-level comments:
* Write a
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2312/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2313/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
42 matches
Mail list logo
