[gem5-users] Marking Region of Interest

[Muhammet Abdullah Soytürk]

Hi all,

I want to simulate an application in full system simulation with region of
interest. I want to mark the region of interest (ROI) in the application,
simulate the system with kvm until the beginning of ROI, switch to detailed
cpu for ROI, and switch back to kvm for the rest of the simulation just
like in the NAS Parallel Benchmarks tutorial:
https://gem5art.readthedocs.io/en/latest/tutorials/npb-tutorial.html. But
the problem is that I don't really know how to mark the region of interest
and I could not find any documentation about it. Can someone explain how to
do it step by step?

Best,
Muhammet
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] RISCV nop executed as c.addi...

[Anuj Falcon]

c.addi instruction executes with zero immediate value, which is wrong
according to ISA specification and it is the opcode for nop (0x0001 in
hex). Can someone let me know why?

-- 
-
J ANUJ
-
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] gem5 segfault with DPRINTFs

[Daniel Gerzhoy]

Hi all,

I've added a series of DPRINTFs into the coherence protocol (GPU_VIPER)
and its been working ok, up until this morning when I added a bunch all at
once and it started segfaulting. This only happens if I have my debug flag
enabled, otherwise the program runs to completion (this is syscall
emulation mode, apu_se.py in /examples)

I've been trying to think of a way to figure out what the problem is using
some semblance of thought but I haven't been able to do anything so I'm
going to binary search my way through the files commenting out all of my
prints.

In the meantime, if anyone could explain how I might use this LIBC
backtrace, either in this situation or the future, that would be amazing.

Cheers,

Dan Gerzhoy

gem5 has encountered a segmentation fault
--- BEGIN LIBC BACKTRACE ---
build/GCN3_X86/gem5.opt(_Z15print_backtracev+0x28)[0x1a06bc8]
build/GCN3_X86/gem5.opt[0x1a19783]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f6d0bb39390]
build/GCN3_X86/gem5.opt(_ZlsRSoRK9MachineID+0x1c)[0x199fcac]
build/GCN3_X86/gem5.opt(_Z8ccprintfIJm9MachineID11TriggerType15Directory_StateEEvRSoPKcDpRKT_+0xebb)[0x19c2c7b]
build/GCN3_X86/gem5.opt(_ZN5Trace6Logger7dprintfIJm9MachineID11TriggerType15Directory_StateEEEvmRKNSt7__cxx1112basic_strinzgIcSt11char_traitsIcESaIcEEEPKcDpRKT_+0xcd)[0x19c316d]
build/GCN3_X86/gem5.opt(_ZN20Directory_Controller6wakeupEv+0x7a0)[0x1957130]
build/GCN3_X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xc5)[0x1a0d3b5]
build/GCN3_X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x50)[0x1a25e40]
build/GCN3_X86/gem5.opt(_Z8simulatem+0xd1b)[0x1a26f2b]
build/GCN3_X86/gem5.opt[0x9bf1aa]
build/GCN3_X86/gem5.opt[0x99d167]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7852)[0x7f6d0bdf67b2]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f6d0bf2d11c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f6d0bdf5f5d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f6d0bf2d11c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f6d0bdeede9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x613b)[0x7f6d0bdf509b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f6d0bf2d11c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f6d0bdf5f5d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f6d0bf2d11c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f6d0bdeede9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7f6d0be69236]
build/GCN3_X86/gem5.opt(_Z6m5MainiPPc+0x8f)[0x1a1813f]
build/GCN3_X86/gem5.opt(main+0x33)[0x8d4dd3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6d0a52c830]
build/GCN3_X86/gem5.opt(_start+0x29)[0x8f9dd9]
--- END LIBC BACKTRACE ---
Failed to execute default signal handler!
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] Illegal instruction error for csrrwi instruction

[Ali Hajiabadi]

Hi,

I am trying to simulate SPEC CPU2006 applications on gem5 with RISC-V
application. For bzip2 application, I get illegal instruction error for
this instruction:

10336:   8010d073csrwi   0x801,1

which will be decoded as csrrwi. Here is the debugging output of gem5:

2727000: system.cpu: A0 T0 : @main+28: csrrwi zero, ?? (0x801):
No_OpClass :   flags=(IsInteger|IsNonSpeculative)

Is the problem with the privilege level of instruction (which I assume
privilege mode is not supported in gem5)? Adding some flags for compilation
can solve the problem?

This my compilation command:

riscv64-unknown-linux-gnu-gcc X.o -o X -march=rv64gc -mabi=lp64 -static

Also, what RISC-V ISA specifications are supported in gem5?

Thanks,
Ali
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Getting the virtual address of a specific physical address in x86 se mode

[Jason Lowe-Power]

Hello,

You can use the "map" function on the Process SimObject to set a specific
virtual to physical mapping. See
https://gem5.googlesource.com/public/gem5/+/refs/heads/master/src/sim/Process.py#39

After you instantiate the process in your python config script, you can
call map() on it and then the mapping will be set up. Then, inside your
guest application, when you access that particular virtual address it will
go to the physical address that you set in your config file. This should do
exactly what you need (if I understand correctly).

BTW, this will only work in SE mode. If you need to do this in FS mode,
you'll most likely have to write a new kernel driver for your scratchpads
(just like if they were real hardware!).

Cheers,
Jason

On Thu, Feb 13, 2020 at 8:40 AM Muhammad Aamir 
wrote:

> Hi everyone,
>
> I have basically initialized some simplememory class as a Scratchpad
> memories, and I intend to write to them.
> One way that i have figured to access them is using addresses, As I know
> once initialized they are assigned some virtual addresses by the
> pagetables, and since each virtual address is mapped on to a
> physical address and I know where the physical addresses of my scratchpad
> can begin from.
>
> How can I find the virtual address corresponding to that specific physical
> address so that I can access it?
>
> The physical address of where my "new simpememory" begins can be found
> like this
>
> const std::vector 
> (thread->getSystemPtr()->getPhysMem().getBackingStore());
> const AddrRange (memories[1].range); //where range will give me start 
> of my scratchpad memory
>
>
> Can the AddrRange "range" be converted to a virtual address?
>
>
> If there is a better way to write on to the simplememory class,that would be 
> great as well.
>
> Thanks
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] Getting the virtual address of a specific physical address in x86 se mode

[Muhammad Aamir]

Hi everyone,

I have basically initialized some simplememory class as a Scratchpad
memories, and I intend to write to them.
One way that i have figured to access them is using addresses, As I know
once initialized they are assigned some virtual addresses by the
pagetables, and since each virtual address is mapped on to a
physical address and I know where the physical addresses of my scratchpad
can begin from.

How can I find the virtual address corresponding to that specific physical
address so that I can access it?

The physical address of where my "new simpememory" begins can be found like
this

const std::vector
(thread->getSystemPtr()->getPhysMem().getBackingStore());
const AddrRange (memories[1].range); //where range will give me
start of my scratchpad memory


Can the AddrRange "range" be converted to a virtual address?


If there is a better way to write on to the simplememory class,that
would be great as well.

Thanks
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How to attach second image to full system emulation.

[iagosilvestrehp]

Thank you, yes this did indeed solve the problem. I was not aware a second image file is now officially supported by the tool without further modificationsOn Feb 13, 2020 11:55 AM, Ciro Santilli  wrote:Hi Iago,

I have managed to get it working recently without any patches as
explained at:
https://stackoverflow.com/questions/50862906/how-to-attach-multiple-disk-images-in-a-simulation-with-gem5-fs-py/60210181#60210181

If that doesn't solve the problem for you, let me know.

On 2/7/20 2:38 PM, Iago . wrote:
> I've been trying to reproduce some tests i've done last year but with
> some of the latest updates to the tool the way to append a second image
> to the FSConfig.py script has changed, i've been trying to just change this:
>
> def makeCowDisks(disk_paths):
>  disks = []
>  for disk_path in disk_paths:
>  disk = CowIdeDisk(driveID='master')
>  disk.childImage(disk_path);
>  disks.append(disk)
>  return disks
>
> changing the childimage line to :
> disk.childImage('/home/iago/fs/disks/workloads.img');
> But ive been getting kernel panics on my simulation.
> Thanks in advance
>
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
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.

___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How to attach second image to full system emulation.

[Ciro Santilli]

Hi Iago,

I have managed to get it working recently without any patches as 
explained at: 
https://stackoverflow.com/questions/50862906/how-to-attach-multiple-disk-images-in-a-simulation-with-gem5-fs-py/60210181#60210181


If that doesn't solve the problem for you, let me know.

On 2/7/20 2:38 PM, Iago . wrote:
I've been trying to reproduce some tests i've done last year but with 
some of the latest updates to the tool the way to append a second image 
to the FSConfig.py script has changed, i've been trying to just change this:


def makeCowDisks(disk_paths):
 � � disks = []
 � � for disk_path in disk_paths:
 � � � � disk = CowIdeDisk(driveID='master')
 � � � � disk.childImage(disk_path);
 � � � � disks.append(disk)
 � � return disks

changing the childimage line to :
disk.childImage('/home/iago/fs/disks/workloads.img');
But ive been getting kernel panics on my simulation.
Thanks in advance


___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Inconsistency detected by ld.so: rtld.c: 1273: dl_main: Assertion `GL(dl_rtld_map).l_libname' failed!

[Ciro Santilli]

Full system or syscall emulation? Always give full gem5 CLI :-)

If syscall emulation and the binary is dynamically linked, try to 
produce a statically linked version of it, since this seems dynamic 
loader related.


On 2/10/20 3:30 PM, 616653241 wrote:

hi, everyone,
 � � I was running spec2017 in gem5, but an error occurred. The os is 
ubuntu 19.04, and the case is running as X86.
 � �Inconsistency detected by ld.so: rtld.c: 1273: dl_main: Assertion 
`GL(dl_rtld_map).l_libname' failed!

 � � It's in every benchmark.
 � � can anyone give me some advices?
 � � Thank you.

___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

[Abhishek Singh]

Hi,
I will try my best to get the fix and share with the community. Also, if
you guys need help in testing the commit when submitted to review, please
let the community know. So however is interested can run tests and post the
result on online which is viewable by the maintainer and when important
features like multi core/multithreaded/multi programmed simulations and
others more have problem the developer can fix it so that previous
developers commit are not nullified
In this particular scenario someone did develop the environment for multi
core/multi threaded/multi programmed and now his/her effort needs to be
redone because we as community as whole did not pay attention when a commit
is submitted.
Currently in my free time I have personally started testing all the merged
commit in git review and test atleast the applications which is there in
gem5 directory.
And I have already submitted a Jira ticket. And in the mailing list I did
mention which gem5 commit is still supporting multi programmed simulations.
I will try to fix the problem and submit

On Thu, Feb 13, 2020 at 9:12 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Abhishek,
>
> Let me first thank you for finding and reporting the problem.
> Since you are asking
>
>
> *"please also inform all the developers to not push commit if their commit
> disturbs the dependencies then try to fix them and after everything is
> fixed then only merge to public gem5!" *
>
> I'd like to take the opportunity to explain which is the gem5 contribution
> workflow.
>
> Every time we post a patch for review, before it gets merged we
> automatically run a set of tests to verify the patch isn't breaking anything
> .
> If one (or more) of the tests fails, it won't be possible to merge the
> patch.
> Please have a look at
>
> https://github.com/gem5/gem5/blob/master/TESTING.md
>
> to have an idea on how this works.
>
> So why things break?
>
> Gem5 has a lot of features that could be tested (SE mode, FS mode, Ruby
> mem, Classic mem, AtomicCPU, TimingCPU, MinorCPU, O3CPU, Checkpointing,
> FastForwarding, SMT, SMP ... just to mention few)
>
> We try to cover the most significant ones but the combination of all this
> parameters makes it IMPOSSIBLE to test EVERYTHING.
> What we can do though is to prioritize some tests over some others. Or, if
> the test is fairly simple, we can consider adding it to the regression list.
>
> If you find that a feature is broken, you can use JIRA (
> https://gem5.atlassian.net/jira/your-work) to raise a ticket.
> We try to address the problems in a reasonable amount of time. It usually
> helps if, rather than saying "things are broken", we actually get a link to
> the commit which breaks the feature you are interested on (you can easilly
> bisect until you find the culprit).
>
> This will make it very likely for the bug to get a quick fix; or, by being
> an open source project, we would be very happy to receive a contribution
> fix from you if you feel like handling it yourself. I would be happy to
> provide all the support needed so it is up to you.
>
> Once the issue has been solved we can discuss to add an SMT test to the
> list so that we are sure things won't break again.
>
> Kind Regards
>
> Giacomo
>
> 
> gem5/TESTING.md at master · gem5/gem5 · GitHub
> 
> With this method, you can only run a single suite at a time. If you want
> to run more than one uid, you must call ./main.py multiple times..
> Currently, you must specify --skip-build if you want to run a single suite
> or run in batch mode. Otherwise, you will build gem5 for all architectures.
> github.com
>
>
>
>
>
>
> --
> *From:* gem5-users  on behalf of Abhishek
> Singh 
> *Sent:* 11 February 2020 19:34
> *To:* gem5 users mailing list 
> *Subject:* [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is
> broken
>
> Hello Everyone,
>
> The latest commit *135595a* is unable to support multi-core
> (multi-programmed) simulation on x86 O3CPU. I am pasting the terminal
> output showing a simple hello world program. The older commits of gem5 do
> support such multi-core (multi-programmed) simulation.
> Please note if we do not use SMT and use the number of CPUs as 2 for 2
> core simulation, the simulation reaches a point and goes in a never-ending
> loop.
>
> These problems are due to cause of recent commits, *please also inform
> all the developers *to not push commit if their commit disturbs the
> dependencies then try to fix them and after everything is fixed then only
> merge to public gem5!
>
> *Using SMT:*
> /build/X86/gem5.opt configs/example/se.py -c
> 'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
> --caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB
> --l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --cacheline_size=64
> --cpu-type=DerivO3CPU --mem-type=DDR4_2400_8x8 

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

[Giacomo Travaglini]

Hi Abhishek,

Let me first thank you for finding and reporting the problem.
Since you are asking

"please also inform all the developers to not push commit if their commit 
disturbs the dependencies then try to fix them and after everything is fixed 
then only merge to public gem5!"

I'd like to take the opportunity to explain which is the gem5 contribution 
workflow.

Every time we post a patch for review, before it gets merged we automatically 
run a set of tests to verify the patch isn't breaking anything.
If one (or more) of the tests fails, it won't be possible to merge the patch.
Please have a look at

https://github.com/gem5/gem5/blob/master/TESTING.md

to have an idea on how this works.

So why things break?

Gem5 has a lot of features that could be tested (SE mode, FS mode, Ruby mem, 
Classic mem, AtomicCPU, TimingCPU, MinorCPU, O3CPU, Checkpointing, 
FastForwarding, SMT, SMP ... just to mention few)

We try to cover the most significant ones but the combination of all this 
parameters makes it IMPOSSIBLE to test EVERYTHING.
What we can do though is to prioritize some tests over some others. Or, if the 
test is fairly simple, we can consider adding it to the regression list.

If you find that a feature is broken, you can use JIRA 
(https://gem5.atlassian.net/jira/your-work) to raise a ticket.
We try to address the problems in a reasonable amount of time. It usually helps 
if, rather than saying "things are broken", we actually get a link to the 
commit which breaks the feature you are interested on (you can easilly bisect 
until you find the culprit).

This will make it very likely for the bug to get a quick fix; or, by being an 
open source project, we would be very happy to receive a contribution fix from 
you if you feel like handling it yourself. I would be happy to provide all the 
support needed so it is up to you.

Once the issue has been solved we can discuss to add an SMT test to the list so 
that we are sure things won't break again.

Kind Regards

Giacomo

[https://avatars2.githubusercontent.com/u/1524926?s=400=4]
gem5/TESTING.md at master · gem5/gem5 · 
GitHub
With this method, you can only run a single suite at a time. If you want to run 
more than one uid, you must call ./main.py multiple times.. Currently, you must 
specify --skip-build if you want to run a single suite or run in batch mode. 
Otherwise, you will build gem5 for all architectures.
github.com







From: gem5-users  on behalf of Abhishek Singh 

Sent: 11 February 2020 19:34
To: gem5 users mailing list 
Subject: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

Hello Everyone,


The latest commit 135595a is unable to support multi-core (multi-programmed) 
simulation on x86 O3CPU. I am pasting the terminal output showing a simple 
hello world program. The older commits of gem5 do support such multi-core 
(multi-programmed) simulation.
Please note if we do not use SMT and use the number of CPUs as 2 for 2 core 
simulation, the simulation reaches a point and goes in a never-ending loop.

These problems are due to cause of recent commits, please also inform all the 
developers to not push commit if their commit disturbs the dependencies then 
try to fix them and after everything is fixed then only merge to public gem5!

Using SMT:
/build/X86/gem5.opt configs/example/se.py -c 
'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
 --caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB --l1d_assoc=8 
--l1i_assoc=8 --l2_assoc=16 --cacheline_size=64 --cpu-type=DerivO3CPU 
--mem-type=DDR4_2400_8x8 --mem-size=8GB --sys-clock=2.6GHz --cpu-clock=2.6GHz 
--smt

Global frequency set at 1 ticks per second
warn: DRAM device capacity (16384 Mbytes) does not match the address range 
assigned (8192 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7002
0: system.remote_gdb: listening for remote gdb on port 7003
panic: panic condition

Memory Usage: 8560136 KBytes
Program aborted at tick 0
— BEGIN LIBC BACKTRACE —
./build/X86/gem5.opt(_Z15print_backtracev+0x29)[0x55b3ff0e54e9]
./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x55b3ff0f7d9a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f379da2f890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f379b999e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f379b99b801]
./build/X86/gem5.opt(+0x59bd8f)[0x55b3fe8cdd8f]
./build/X86/gem5.opt(_ZN6X86ISA10Interrupts4initEv+0x110)[0x55b3feb80820]
./build/X86/gem5.opt(+0x15feaaa)[0x55b3ff930aaa]
./build/X86/gem5.opt(+0x6d960e)[0x55b3fea0b60e]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7a70)[0x7f379dceb010]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6364)[0x7f379dce9904]