Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Sorry for the delayed reply. This is something I referred to when I was
looking into the CPUID stuff recently.
http://support.amd.com/TechDocs/25481.pdf
Gabe
On Fri, Feb 20, 2015 at 3:17 PM, Joel Hestness via gem5-dev <
gem5-dev@gem5.org> wrote:
> Hi guys,
> I think I figure some of this out. The Wikipedia page on CPUID (
> http://en.wikipedia.org/wiki/CPUID) indicates that xsave is bit 26 of ECX.
> Unsetting this bit allowed me to successfully boot these older versions of
> Linux. For anyone running into the same issue, here is the patch for that
> change:
>
> --
> diff --git a/src/arch/x86/cpuid.cc b/src/arch/x86/cpuid.cc
> --- a/src/arch/x86/cpuid.cc
> +++ b/src/arch/x86/cpuid.cc
> @@ -154,7 +154,7 @@
> break;
>case FamilyModelStepping:
> result = CpuidResult(0x00020f51, 0x0805,
> - 0xe7dbfbff, 0x04000209);
> + 0xe7dbfbff, 0x0209);
> break;
>default:
> warn("x86 cpuid: unimplemented function %u", funcNum);
> --
>
> I also discovered that the reason Linux falls into this kernel panic is
> that it executes a CPUID operation that is not currently implemented in
> gem5 (src/arch/x86/cpuid.cc). Specifically, the cpuid_count function call
> (here:
> http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L319
> )
> tries to execute CPUID function EAX=0xd (13), EAX=0x0. gem5 prints a
> warning saying that this function is unimplemented, and does not update any
> registers, causing the resulting EAX to be incorrect.
>
> It looks like more recent Linux versions contain more checks, and so may
> not reach this cpuid_count call:
> http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c#L618
>
>
> Joel
>
>
>
>
> On Fri, Feb 20, 2015 at 2:17 PM, Joel Hestness
> wrote:
>
> > Hey Gabe,
> > When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm
> > running into a kernel panic related to xsave (
> >
> http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323
> > ):
> >
> > *FP/SSE not shown under xsave features 0xd*
> > [ cut here ]
> > kernel BUG at arch/x86/kernel/xsave.c:323!
> > invalid opcode: [#1] SMP
> > last sysfs file:
> > CPU 0
> > Modules linked in:
> > Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5
> > RIP: 0010:[] []
> > xsave_cntxt_init+0x35/0x130
> > RSP: 0018:808c3f18 EFLAGS: 00b8
> > RAX: 002d RBX: 808c3f48 RCX:
> > RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4
> > RBP: R08: R09: 03fd
> > R10: R11: R12: 807a8340
> > R13: 0005 R14: 8800 R15: 88000101f000
> > FS: () GS:808bd980()
> > knlGS:
> > CS: 0010 DS: 0018 ES: 0018 CR0: 80050033
> > CR2: CR3: 00201000 CR4: 06a0
> > DR0: DR1: DR2:
> > DR3: DR6: 0ff0 DR7:
> > Process swapper (pid: 0, threadinfo 808c2000, task
> > 807a8340)
> > Stack:
> > 808c3f48 8060e2b1 0010 8060fa3f
> > 0020 fff0 0100890239802087 8800
> > 808c3f88 0040 808f7700
> > Call Trace:
> > [] fpu_init+0x4a/0x97
> > [] cpu_init+0x319/0x33f
> > [] start_kernel+0x1b2/0x321
> > [] x86_64_start_kernel+0xd9/0xdd
> > Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0
> 03
> > 48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff <0f> 0b eb fe
> > f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00
> > RIP [] xsave_cntxt_init+0x35/0x130
> > RSP
> > ---[ end trace 4eaa2a86a8e2da22 ]---
> > Kernel panic - not syncing: Attempted to kill the idle task!
> > [ cut here ]
> > WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250()
> > Modules linked in:
> > Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5
> > Call Trace:
> > [] warn_on_slowpath+0x62/0xa0
> > [] vsnprintf+0x449/0x6b0
> > [] string+0x34/0xf0
> > [] vsnprintf+0x408/0x6b0
> > [] up+0xd/0x40
> > [] release_console_sem+0x1ae/0x200
> > [] stop_this_cpu+0x0/0x30
> > [] smp_call_function_mask+0x1de/0x250
> > [] vsnprintf+0x268/0x6b0
> > [] printk+0x40/0x45
> > [] native_smp_send_stop+0x20/0x30
> > [] panic+0x82/0x129
> > [] do_exit+0x7de/0x890
> > [] printk+0x40/0x45
> > [] oops_end+0x7a/0xc0
> > [] do_invalid_op+0x84/0xa0
> > [] xsave_cntxt_init+0x35/0x130
> > [] release_console_sem+0x1ae/0x200
> > [] up+0xd/0x40
> > [] error_exit+0
Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Hi guys,
I think I figure some of this out. The Wikipedia page on CPUID (
http://en.wikipedia.org/wiki/CPUID) indicates that xsave is bit 26 of ECX.
Unsetting this bit allowed me to successfully boot these older versions of
Linux. For anyone running into the same issue, here is the patch for that
change:
--
diff --git a/src/arch/x86/cpuid.cc b/src/arch/x86/cpuid.cc
--- a/src/arch/x86/cpuid.cc
+++ b/src/arch/x86/cpuid.cc
@@ -154,7 +154,7 @@
break;
case FamilyModelStepping:
result = CpuidResult(0x00020f51, 0x0805,
- 0xe7dbfbff, 0x04000209);
+ 0xe7dbfbff, 0x0209);
break;
default:
warn("x86 cpuid: unimplemented function %u", funcNum);
--
I also discovered that the reason Linux falls into this kernel panic is
that it executes a CPUID operation that is not currently implemented in
gem5 (src/arch/x86/cpuid.cc). Specifically, the cpuid_count function call
(here:
http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L319)
tries to execute CPUID function EAX=0xd (13), EAX=0x0. gem5 prints a
warning saying that this function is unimplemented, and does not update any
registers, causing the resulting EAX to be incorrect.
It looks like more recent Linux versions contain more checks, and so may
not reach this cpuid_count call:
http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c#L618
Joel
On Fri, Feb 20, 2015 at 2:17 PM, Joel Hestness wrote:
> Hey Gabe,
> When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm
> running into a kernel panic related to xsave (
> http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323
> ):
>
> *FP/SSE not shown under xsave features 0xd*
> [ cut here ]
> kernel BUG at arch/x86/kernel/xsave.c:323!
> invalid opcode: [#1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5
> RIP: 0010:[] []
> xsave_cntxt_init+0x35/0x130
> RSP: 0018:808c3f18 EFLAGS: 00b8
> RAX: 002d RBX: 808c3f48 RCX:
> RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4
> RBP: R08: R09: 03fd
> R10: R11: R12: 807a8340
> R13: 0005 R14: 8800 R15: 88000101f000
> FS: () GS:808bd980()
> knlGS:
> CS: 0010 DS: 0018 ES: 0018 CR0: 80050033
> CR2: CR3: 00201000 CR4: 06a0
> DR0: DR1: DR2:
> DR3: DR6: 0ff0 DR7:
> Process swapper (pid: 0, threadinfo 808c2000, task
> 807a8340)
> Stack:
> 808c3f48 8060e2b1 0010 8060fa3f
> 0020 fff0 0100890239802087 8800
> 808c3f88 0040 808f7700
> Call Trace:
> [] fpu_init+0x4a/0x97
> [] cpu_init+0x319/0x33f
> [] start_kernel+0x1b2/0x321
> [] x86_64_start_kernel+0xd9/0xdd
> Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0 03
> 48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff <0f> 0b eb fe
> f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00
> RIP [] xsave_cntxt_init+0x35/0x130
> RSP
> ---[ end trace 4eaa2a86a8e2da22 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> [ cut here ]
> WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250()
> Modules linked in:
> Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5
> Call Trace:
> [] warn_on_slowpath+0x62/0xa0
> [] vsnprintf+0x449/0x6b0
> [] string+0x34/0xf0
> [] vsnprintf+0x408/0x6b0
> [] up+0xd/0x40
> [] release_console_sem+0x1ae/0x200
> [] stop_this_cpu+0x0/0x30
> [] smp_call_function_mask+0x1de/0x250
> [] vsnprintf+0x268/0x6b0
> [] printk+0x40/0x45
> [] native_smp_send_stop+0x20/0x30
> [] panic+0x82/0x129
> [] do_exit+0x7de/0x890
> [] printk+0x40/0x45
> [] oops_end+0x7a/0xc0
> [] do_invalid_op+0x84/0xa0
> [] xsave_cntxt_init+0x35/0x130
> [] release_console_sem+0x1ae/0x200
> [] up+0xd/0x40
> [] error_exit+0x0/0x51
> [] xsave_cntxt_init+0x35/0x130
> [] xsave_cntxt_init+0x35/0x130
> [] fpu_init+0x4a/0x97
> [] cpu_init+0x319/0x33f
> [] start_kernel+0x1b2/0x321
> [] x86_64_start_kernel+0xd9/0xdd
> ---[ end trace 4eaa2a86a8e2da22 ]---
>
> Based on the commit message, it looks like this patch might have enabled
> Linux boot features through the xsave setting. Can you please let me know
> which of the bits in the CpuidResult vector I should disable to test if
> xsave is the
Re: [gem5-dev] changeset in gem5: x86: Enable three bits in the FamilyModelStep...
Hey Gabe,
When I try to boot older versions of Linux (2.6.28.4, 2.6.22.9), I'm
running into a kernel panic related to xsave (
http://lxr.free-electrons.com/source/arch/x86/kernel/xsave.c?v=2.6.32#L323):
*FP/SSE not shown under xsave features 0xd*
[ cut here ]
kernel BUG at arch/x86/kernel/xsave.c:323!
invalid opcode: [#1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 0, comm: swapper Tainted: GW 2.6.28-rc4-dirty #5
RIP: 0010:[] []
xsave_cntxt_init+0x35/0x130
RSP: 0018:808c3f18 EFLAGS: 00b8
RAX: 002d RBX: 808c3f48 RCX:
RDX: 807c3c38 RSI: 0074 RDI: 8094a5f4
RBP: R08: R09: 03fd
R10: R11: R12: 807a8340
R13: 0005 R14: 8800 R15: 88000101f000
FS: () GS:808bd980() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 80050033
CR2: CR3: 00201000 CR4: 06a0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7:
Process swapper (pid: 0, threadinfo 808c2000, task 807a8340)
Stack:
808c3f48 8060e2b1 0010 8060fa3f
0020 fff0 0100890239802087 8800
808c3f88 0040 808f7700
Call Trace:
[] fpu_init+0x4a/0x97
[] cpu_init+0x319/0x33f
[] start_kernel+0x1b2/0x321
[] x86_64_start_kernel+0xd9/0xdd
Code: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 90 96 05 00 83 e0 03
48 83 f8 03 74 12 48 c7 c7 10 82 71 80 31 c0 e8 4d e6 d3 ff <0f> 0b eb fe
f6 05 b5 70 fe ff 04 48 c7 05 63 96 05 00 03 00 00
RIP [] xsave_cntxt_init+0x35/0x130
RSP
---[ end trace 4eaa2a86a8e2da22 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
[ cut here ]
WARNING: at kernel/smp.c:333 smp_call_function_mask+0x1de/0x250()
Modules linked in:
Pid: 0, comm: swapper Tainted: G D W 2.6.28-rc4-dirty #5
Call Trace:
[] warn_on_slowpath+0x62/0xa0
[] vsnprintf+0x449/0x6b0
[] string+0x34/0xf0
[] vsnprintf+0x408/0x6b0
[] up+0xd/0x40
[] release_console_sem+0x1ae/0x200
[] stop_this_cpu+0x0/0x30
[] smp_call_function_mask+0x1de/0x250
[] vsnprintf+0x268/0x6b0
[] printk+0x40/0x45
[] native_smp_send_stop+0x20/0x30
[] panic+0x82/0x129
[] do_exit+0x7de/0x890
[] printk+0x40/0x45
[] oops_end+0x7a/0xc0
[] do_invalid_op+0x84/0xa0
[] xsave_cntxt_init+0x35/0x130
[] release_console_sem+0x1ae/0x200
[] up+0xd/0x40
[] error_exit+0x0/0x51
[] xsave_cntxt_init+0x35/0x130
[] xsave_cntxt_init+0x35/0x130
[] fpu_init+0x4a/0x97
[] cpu_init+0x319/0x33f
[] start_kernel+0x1b2/0x321
[] x86_64_start_kernel+0xd9/0xdd
---[ end trace 4eaa2a86a8e2da22 ]---
Based on the commit message, it looks like this patch might have enabled
Linux boot features through the xsave setting. Can you please let me know
which of the bits in the CpuidResult vector I should disable to test if
xsave is the problem?
Thanks!
Joel
On Wed, Jan 7, 2015 at 12:06 AM, Gabe Black via gem5-dev
wrote:
> changeset 5d119a460f15 in /z/repo/gem5
> details: http://repo.gem5.org/gem5?cmd=changeset;node=5d119a460f15
> description:
> x86: Enable three bits in the FamilyModelStepping ECX CPUID
> bitfield.
>
> These are for the monitor/mwait instructions, SSSE3, and XSAVE.
>
> diffstat:
>
> src/arch/x86/cpuid.cc | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diffs (12 lines):
>
> diff -r e9bc4cde5d8e -r 5d119a460f15 src/arch/x86/cpuid.cc
> --- a/src/arch/x86/cpuid.cc Tue Jan 06 22:13:56 2015 -0800
> +++ b/src/arch/x86/cpuid.cc Tue Jan 06 22:15:00 2015 -0800
> @@ -154,7 +154,7 @@
> break;
>case FamilyModelStepping:
> result = CpuidResult(0x00020f51, 0x0805,
> - 0xe7dbfbff, 0x0001);
> + 0xe7dbfbff, 0x04000209);
> break;
>default:
> warn("x86 cpuid: unimplemented function %u", funcNum);
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2669: config: Add --sst configuration option
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2669/ --- Review request for Default. Repository: gem5 Description --- Changeset 10710:98bd34bb7a39 --- config: Add --sst configuration option This new option expands to the following: --external-memory-system --initialize-only These are required when running gem5 within SST. Diffs - configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION Diff: http://reviews.gem5.org/r/2669/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs - configs/common/CacheConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/FSConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/MemConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/example/fs.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py c6cb94a14fea4c59780d73d1623d7031bcede6af src/mem/ExternalSlave.py c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2667: ext: Add SST connector
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory <-> I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2666: config: Add ability to exit simulation after initialization
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2666/ --- Review request for Default. Repository: gem5 Description --- Changeset 10707:3cc618608259 --- config: Add ability to exit simulation after initialization When using gem5 as a slave simulator, it will not advance the clock on its own and depends on the master simulator calling simulate(). This new option lets us use the Python scripts to do all the configuration while stopping short of actually simulating anything. Diffs - configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/Simulation.py c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2666/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can call getLimitEvent() and compare it to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Reading Memory Traces
Hi Gregory, The traffic generators should work just fine with Ruby, and they already have trace players. There is nothing precluding you from using the non-Ruby memory system. Ruby gives you the option of having a more elaborate network topology, but if you are fine with crossbars the non-Ruby memory system is probably a more sensible starting point. gem5 also has trace capturing facilities through the CommMonitor, so if you capture the traces on gem5 it should be easy to replay them (and avoid the PA VA issues). Andreas On 20/02/2015 14:17, "VAUMOURIN Grégory via gem5-dev" wrote: >Hello, > >I'm new to the Gem5 ! > >I want to read some pre-recorded memory traces (it's a file that contains >a serie of memory access) with Gem5. I want to stress the interconnection >network and the memories with it, I need precises simulations so I want >to use the Ruby Simulator. > >I've starting to implement a CPU that just read an access on my memory >trace and convert it into a request for Ruby, this is quite similar to >the Ruby Tester that generate some traffic with randomly addresses. I >don't know if some works have already been done in this direction. > >Anyway I'm having trouble with the address of my request, cause I >recorded my memory traces on my computer so the addresses that I have >recorded are 48-bits virtual addresses and I don't know how to convert it >to physical addresses (which seem to be on 27 bits in my case ?) > >If anyone has a clue , or can point be to a better direction to stimulate >the Ruby system with some pre-recorded file ? I can't use the TrafficGen >generators if I use Ruby Systems right ? > >-- >Grégory Vaumourin >Doctorant - Phd Student >Laboratoire Adéquation Algorithme Architecture -- Matching >Algorithm Architecture Laboratory >Phone: +33 (1) 69080069 > > > > >___ >gem5-dev mailing list >gem5-dev@gem5.org >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Reading Memory Traces
Hello, I'm new to the Gem5 ! I want to read some pre-recorded memory traces (it's a file that contains a serie of memory access) with Gem5. I want to stress the interconnection network and the memories with it, I need precises simulations so I want to use the Ruby Simulator. I've starting to implement a CPU that just read an access on my memory trace and convert it into a request for Ruby, this is quite similar to the Ruby Tester that generate some traffic with randomly addresses. I don't know if some works have already been done in this direction. Anyway I'm having trouble with the address of my request, cause I recorded my memory traces on my computer so the addresses that I have recorded are 48-bits virtual addresses and I don't know how to convert it to physical addresses (which seem to be on 27 bits in my case ?) If anyone has a clue , or can point be to a better direction to stimulate the Ruby system with some pre-recorded file ? I can't use the TrafficGen generators if I use Ruby Systems right ? -- Grégory Vaumourin Doctorant - Phd Student Laboratoire Adéquation Algorithme Architecture -- Matching Algorithm Architecture Laboratory Phone: +33 (1) 69080069 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/02.insttest/spar
