Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000
Hi Alec,
Thanks for welcoming me!
What is current status in the implementation RISC-V FS mode?
Also, what are the open issues and where are you tracking them?
For now, I will check the above files pointed by you.
Thanks and Regards,
Rishabh Jain
On Fri, Mar 8, 2019 at 8:17 PM Alec Roelke wrote:
> The RISC-V CSRs are implemented as misc regs, which are the responsibility
> of the ISA to maintain. ISA traits for RISC-V are implemented in
> src/arch/riscv/isa.cc and .hh. The ISA object itself does not have any
> references to CPUs or threads, so CSRs such as performance counters and
> MHARTID can't be initialized and continuously updated by them. However,
> their methods for getting the values of these registers take ThreadContexts
> as arguments (implemented in src/cpu/thread_context.cc and .hh), which
> *do* have pointers the CPU they are running on and can thus be used to
> get that information. So, to get performance counts or a hartid, rather
> than reading from the misc reg file, these methods return data stored by
> the ThreadContext making the request. This is why trying to read directly
> from the misc reg file won't work, because that is technically never
> updated. For hartid, I tried implementing it using the ThreadContext's
> threadId() method, but as you noticed that seems to not always work, so I
> will have to find another solution.
>
> As for FS mode, yes, I have been slowly working toward implementing it. I
> am always happy for others to contribute to RISC-V development, so I invite
> you to contribute if you can. If you want any help or have any questions
> about what is already there, I'll be happy to answer them.
>
> On Thu, Mar 7, 2019 at 4:58 AM Rishabh Jain wrote:
>
>> Hi Alec,
>>
>> Thanks for the reply.
>> For the mhart id issue, could you please point out the file which
>> implements mhart id?
>> I will give a shot to understand the necessary files.
>> If you can let me know, I can send a pull request regarding the same
>> which you can check and merge.
>> Also, do you plan to implement RISC-V FS mode? If yes, I wish to help by
>> contributing to gem5.
>>
>> Please let me know how to get started.
>>
>> Thanks and regards,
>> Rishabh Jain
>>
>>
>>
>> On Thu, Mar 7, 2019 at 8:19 AM Alec Roelke wrote:
>>
>>> When gem5 runs in SE mode, it is intended to mainly run user-level code,
>>> which higher-privilege code that executes during system calls offloaded to
>>> the host. The privileged instructions do have definitions and at least
>>> partial implementations, and you can run them in SE mode because privilege
>>> checking hasn't been implemented yet (and would only matter for FS mode
>>> anyway).
>>>
>>> You should be able to run garnet2.0 and ruby, since they are separate
>>> from the ISA definitions and I didn't see anything in the ISAs that needs
>>> to be implemented for them while poking around when I was implementing
>>> RISC-V. I haven't actually used them myself, though.
>>>
>>> Yes, inline assembly with CSRR is what I had intended. I'll take a
>>> closer look at it this weekend and try to fix it.
>>>
>>> On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain
>>> wrote:
>>>
Hi Alec,
Thanks for the reply.
First, I have a few queries (for RISCV ISA):
1. In which privilege mode does gem5 boot in? If it is supervisor mode
or user mode, then how do I run binaries in machine mode?
2. Can I use garnet2.0 and ruby model for riscv?
I applied the patch by updating the src/arch/riscv/isa.cc file. Then, I
rebuilt the system using "$ scons build/RISCV/gem5.opt -j4".
I compiled my C program file using the command: "
riscv64-unknown-linux-gnu-gcc-7.2.0 -static hello1.c -o a.out"
Again, I ran my python config file using the command " $
build/RISCV/gem5.opt configs/multi_core/two_core/two_core_copy.py "
and I got the same previous value of mhartid. Both 0.
I used inline assembly :
asm ("csrr %0,0xF14\n\t"
:"=r" (hartID)
);
to read the value of mhartid and store in variable hartID. But here, I
am using the csrr instruction, right?
As you mentioned earlier, may you please elaborate on reading CSRR
instruction?
Thanks and Regards,
Rishabh Jain
On Mon, Mar 4, 2019 at 1:57 AM Alec Roelke wrote:
> Hi Rishabh,
>
> You're right that mhartid should not be the same for every CPU. It
> looks like you may have found a bug in RISC-V in that mhartid had not been
> implemented yet. This is odd, though, because I thought I had implemented
> it. In any case, try this patch (
> https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
> implements this CSR by returning the current thread's ID. Note that
> trying
> to manually get the contents of the register by inspecting it as you did
> will still get 0 for all CPUs, but reading it using the CSRR instruction
[gem5-users] SPEC 2017 runs on gem5
Hi All, When I am running a lot of the SPEC '17 applications on gem5, I am getting a warning message that says *warn: instruction 'movntdq_Mo_Vo' unimplemented*. The source code for the binary does not seem to indicate the usage of the movntdq instruction. I assume it is the glibc that is using this instruction, because of indication from the cpuid that there is support for SSE2. I tried disabling both the bits for SSE2 and SSE in the edx register, which ought to cause glibc to not use the binary that contains the same instruction, but I continue to see the same error. Is there something I am missing? Or is there an easier workaround? Thanks, Shyam ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] MevBench on gem5-gpu
Hi Jason, Is there support for Mevbench benchmark suite in gem5-gpu, say if I want to configure an integrated cpu-gpu system? Regards, Abhishek Bhattacharyya Graduate Research Assistant Electrical and Computer Engineering Department University of Wisconsin-Madison ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Commonitor
Hi, A smart way to know how many instruction to Fastforward is to use dump stats just after boot up for the first run and then see instruction count. Second way is to use checkpointing technique for the boot-up and then restore from that and then run your application. For monitoring accesses I would have defined new stats if it’s already not there. On Thu, Mar 7, 2019 at 4:03 AM Morteza Soltani < morteza.soltani8...@gmail.com> wrote: > Hi > I want to monitor DRAM access after LLC request in full system simulation > of gem5. I want to know that, how can i enable commonitor feature after > going to run benchmark (into ROI)? > "I am familiar with fast-forward mode but i don't have any information > about the number of instruction before running each benchmark" > > > -- > >*Sincerely Yours,* > >*Morteza Soltani* > > > ___ > 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] gem5 X86 Full System fails with DerivO3CPU
Hi Abhishek, I wonder if you are using the default CPU configuration for full-system or do you have any changes? Regards -Ayaz On Wed, Mar 6, 2019 at 2:20 PM Abhishek Singh < abhishek.singh199...@gmail.com> wrote: > Hello Everyone, > > I am trying to run the gem5 full system with X86 ISA and DerivO3CPU > > I have built image and kernel following Jason's Website (ref: > http://www.lowepower.com/jason/setting-up-gem5-full-system.html) > My image is* Ubuntu 16.04.5 LTS* > My kernel is *Linux-4.8.13* > Gem5 version: Latest as of 6th March 2019 > > The image and kernel work fine with Atomic and Timing CPU for x86. > But for O3CPU, it gives an error as shown below: > " > > command line: *./build/X86/gem5.opt configs/example/fs.py > --script=./script.rcS > --disk-image=/home/abs218/image_kernel/ubuntu-test.img > --kernel=/home/abs218/new_fs/gem5/linux-4.8.13/vmlinux --caches --l2cache > --cpu-type=DerivO3CPU* > > > Global frequency set at 1 ticks per second > > warn: DRAM device capacity (8192 Mbytes) does not match the address range > assigned (512 Mbytes) > > info: kernel located at: /home/abs218/new_fs/gem5/linux-4.8.13/vmlinux > > system.pc.com_1.device: Listening for connections on port 3456 > > 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 > > 0: system.remote_gdb: listening for remote gdb on port 7000 > > warn: Reading current count from inactive timer. > > REAL SIMULATION > > info: Entering event queue @ 0. Starting simulation... > > *gem5.opt: build/X86/mem/packet.hh:1047: T* Packet::getPtr() [with T = > unsigned char]: Assertion `flags.isSet(STATIC_DATA|DYNAMIC_DATA)' failed*. > > Program aborted at tick 11637500 > > --- BEGIN LIBC BACKTRACE --- > > ./build/X86/gem5.opt(_Z15print_backtracev+0x2c)[0x561f4b44d8bc] > > ./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x561f4b45fc8a] > > /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f25466db890] > > /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f2544e02e97] > > /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f2544e04801] > > /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f2544df439a] > > /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f2544df4412] > > > ./build/X86/gem5.opt(_ZN6X86ISA13handleIprReadEP13ThreadContextP6Packet+0x17c)[0x561f4ace817c] > > > ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE4readEPN3LSQIS0_E10LSQRequestEi+0x431)[0x561f4aca8781] > > > ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE4readEPNS1_10LSQRequestEi+0xad)[0x561f4acee75d] > > > ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11pushRequestERK14RefCountingPtrI13BaseO3DynInstIS0_EEbPhjm5FlagsImEPmP15AtomicOpFunctor+0x523)[0x561f4aceecf3] > > > ./build/X86/gem5.opt(_ZN11BaseDynInstI9O3CPUImplE15initiateMemReadEmj5FlagsImE+0x7b)[0x561f4ac8cb3b] > > > ./build/X86/gem5.opt(_ZNK10X86ISAInst5LdBig11initiateAccEP11ExecContextPN5Trace10InstRecordE+0xd1)[0x561f4b99e521] > > > ./build/X86/gem5.opt(_ZN13BaseO3DynInstI9O3CPUImplE11initiateAccEv+0x45)[0x561f4acbfc15] > > > ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x57)[0x561f4acf87e7] > > > ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x3b)[0x561f4ace8a0b] > > > ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE12executeInstsEv+0xf06)[0x561f4acd6e96] > > > ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x8c0)[0x561f4acda9a0] > > > ./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x144)[0x561f4acac574] > > ./build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x561f4b455699] > > ./build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x87)[0x561f4b470e77] > > ./build/X86/gem5.opt(_Z8simulatem+0xcaa)[0x561f4b471eba] > > ./build/X86/gem5.opt(+0x5b4d4e)[0x561f4aaedd4e] > > ./build/X86/gem5.opt(+0x591bf4)[0x561f4aacabf4] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x64d7)[0x7f2546995697] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] > > --- END LIBC BACKTRACE --- > > Aborted (core dumped) > > > When I tried to use AtomicCPU for boot up by fast forwarding it, as soon > as its fast forwarded, simulations get killed with the message shown below: > > > """ > > Switched CPUS @ tick 7034903342000 > > switching cpus > > warn: ClockedObject: Already in the requested power state, request ignored > > REAL SIMULATION > > info: Entering event queue @ 7034903342000.
Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000
The RISC-V CSRs are implemented as misc regs, which are the responsibility
of the ISA to maintain. ISA traits for RISC-V are implemented in
src/arch/riscv/isa.cc and .hh. The ISA object itself does not have any
references to CPUs or threads, so CSRs such as performance counters and
MHARTID can't be initialized and continuously updated by them. However,
their methods for getting the values of these registers take ThreadContexts
as arguments (implemented in src/cpu/thread_context.cc and .hh), which
*do* have
pointers the CPU they are running on and can thus be used to get that
information. So, to get performance counts or a hartid, rather than
reading from the misc reg file, these methods return data stored by the
ThreadContext making the request. This is why trying to read directly from
the misc reg file won't work, because that is technically never updated.
For hartid, I tried implementing it using the ThreadContext's threadId()
method, but as you noticed that seems to not always work, so I will have to
find another solution.
As for FS mode, yes, I have been slowly working toward implementing it. I
am always happy for others to contribute to RISC-V development, so I invite
you to contribute if you can. If you want any help or have any questions
about what is already there, I'll be happy to answer them.
On Thu, Mar 7, 2019 at 4:58 AM Rishabh Jain wrote:
> Hi Alec,
>
> Thanks for the reply.
> For the mhart id issue, could you please point out the file which
> implements mhart id?
> I will give a shot to understand the necessary files.
> If you can let me know, I can send a pull request regarding the same which
> you can check and merge.
> Also, do you plan to implement RISC-V FS mode? If yes, I wish to help by
> contributing to gem5.
>
> Please let me know how to get started.
>
> Thanks and regards,
> Rishabh Jain
>
>
>
> On Thu, Mar 7, 2019 at 8:19 AM Alec Roelke wrote:
>
>> When gem5 runs in SE mode, it is intended to mainly run user-level code,
>> which higher-privilege code that executes during system calls offloaded to
>> the host. The privileged instructions do have definitions and at least
>> partial implementations, and you can run them in SE mode because privilege
>> checking hasn't been implemented yet (and would only matter for FS mode
>> anyway).
>>
>> You should be able to run garnet2.0 and ruby, since they are separate
>> from the ISA definitions and I didn't see anything in the ISAs that needs
>> to be implemented for them while poking around when I was implementing
>> RISC-V. I haven't actually used them myself, though.
>>
>> Yes, inline assembly with CSRR is what I had intended. I'll take a
>> closer look at it this weekend and try to fix it.
>>
>> On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain
>> wrote:
>>
>>> Hi Alec,
>>>
>>> Thanks for the reply.
>>>
>>> First, I have a few queries (for RISCV ISA):
>>> 1. In which privilege mode does gem5 boot in? If it is supervisor mode
>>> or user mode, then how do I run binaries in machine mode?
>>> 2. Can I use garnet2.0 and ruby model for riscv?
>>>
>>> I applied the patch by updating the src/arch/riscv/isa.cc file. Then, I
>>> rebuilt the system using "$ scons build/RISCV/gem5.opt -j4".
>>> I compiled my C program file using the command: "
>>> riscv64-unknown-linux-gnu-gcc-7.2.0 -static hello1.c -o a.out"
>>> Again, I ran my python config file using the command " $
>>> build/RISCV/gem5.opt configs/multi_core/two_core/two_core_copy.py "
>>> and I got the same previous value of mhartid. Both 0.
>>> I used inline assembly :
>>> asm ("csrr %0,0xF14\n\t"
>>> :"=r" (hartID)
>>> );
>>> to read the value of mhartid and store in variable hartID. But here, I
>>> am using the csrr instruction, right?
>>> As you mentioned earlier, may you please elaborate on reading CSRR
>>> instruction?
>>>
>>> Thanks and Regards,
>>> Rishabh Jain
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Mar 4, 2019 at 1:57 AM Alec Roelke wrote:
>>>
Hi Rishabh,
You're right that mhartid should not be the same for every CPU. It
looks like you may have found a bug in RISC-V in that mhartid had not been
implemented yet. This is odd, though, because I thought I had implemented
it. In any case, try this patch (
https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
implements this CSR by returning the current thread's ID. Note that trying
to manually get the contents of the register by inspecting it as you did
will still get 0 for all CPUs, but reading it using the CSRR instruction
should produce correct results. It would also be helpful if you review the
patch (just +1 or -1 is okay unless you have more information you want to
share) so I know it works on others' machines.
As for your other problem, did you compile with the Linux toolchain or
the Newlib one? Gem5 is generally intended to run Linux binaries, so there
may be problems running code compiled for Newlib. I tried
