Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

There are a few things that I have identified that need to be implemented
or created, including memory attributes/protection and a kernel+boot image,
and a few more things that need to be tested somehow, including switching
privilege modes and interrupts.  I think the most important issue is the
creation of a kernel+boot image so we can try to run code and debug
problems.  This patch
 contains an
example for running bare-metal code which does nothing but enter an
infinite loop, but I think a kernel will be necessary if we want to be able
to see output.

I have a GitHub repository I use to work on these in my old lab group's
organization and have created some issues to track them.  I don't consider
these issues to necessarily be exhaustive and expect that more will be
added by me or other contributors in the future.  Would you like me to
invite you to it?

Also, I've uploaded an update to the hartid patch that should fix the
problem.  Please test it yourself and let me know via review if it works or
not.

On Sat, Mar 9, 2019 at 12:14 AM Rishabh Jain  wrote:

> 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 

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Rishabh Jain]

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

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

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 

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Rishabh Jain]

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 your program
>>> with both, and it works with the Linux toolchain.  Try that and let me know
>>> if it still fails.
>>>
>>> -Alec
>>>
>>> On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain 
>>> wrote:
>>>
 Hi everyone,

 I have started working with gem5 from past 2 weeks and am trying to
 simulate a multi-core CPU system with RISC-V ISA on gem5.

 I have written a C file where I use inline assembly snippet to grab the
 value of mhartid (Hardware Thread id), marchid and mstatus.
 I used this command to statically compile C code: $
 riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
 The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.

 I have written my multi-core python configuration code: where the
 system has two CPU cores, each having a private
 I cache and D cache. These cache memories are connected to shared L2
 cache via L2 bus. The L2 cache memory
 is connected to the memory controller via membus.
 The code is attached or available at (python configuration file)
 https://pastebin.com/utxxNfJg
 I used the cache python file which Jason has provided as part of
 learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
 The command used to simulate on gem5: $ build/RISCV/gem5.opt
 configs/multi_core/two_core/two_core_copy.py

 After running this command, I get the console log : (console log
 without loop) https://pastebin.com/t8rM9thk
 From 

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

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 your program
>> with both, and it works with the Linux toolchain.  Try that and let me know
>> if it still fails.
>>
>> -Alec
>>
>> On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I have started working with gem5 from past 2 weeks and am trying to
>>> simulate a multi-core CPU system with RISC-V ISA on gem5.
>>>
>>> I have written a C file where I use inline assembly snippet to grab the
>>> value of mhartid (Hardware Thread id), marchid and mstatus.
>>> I used this command to statically compile C code: $
>>> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
>>> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>>>
>>> I have written my multi-core python configuration code: where the system
>>> has two CPU cores, each having a private
>>> I cache and D cache. These cache memories are connected to shared L2
>>> cache via L2 bus. The L2 cache memory
>>> is connected to the memory controller via membus.
>>> The code is attached or available at (python configuration file)
>>> https://pastebin.com/utxxNfJg
>>> I used the cache python file which Jason has provided as part of
>>> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
>>> The command used to simulate on gem5: $ build/RISCV/gem5.opt
>>> configs/multi_core/two_core/two_core_copy.py
>>>
>>> After running this command, I get the console log : (console log without
>>> loop) https://pastebin.com/t8rM9thk
>>> From this log, I am able to get the values as follows:
>>> CPU1:
>>> mhartid = 0
>>>  marchid = 8192
>>> mstatus = 0
>>>
>>> CPU2:
>>> mhartid = 0
>>>  marchid = 8192
>>> mstatus = 0
>>>
>>> I strongly feel that mhartid of each processor should be different. Can
>>> someone explain to me why they are the same?
>>>
>>> Out of curiosity, I had put a loop in the C code to observe cache
>>> misses! (please uncomment the loop in above C code to run! )
>>> Again, I compiled the C code using the above command and simulated using
>>> gem5.
>>> I get a long message starting with "panic: Page table fault when
>>> accessing 

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Rishabh Jain]

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 your program with
> both, and it works with the Linux toolchain.  Try that and let me know if
> it still fails.
>
> -Alec
>
> On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain  wrote:
>
>> Hi everyone,
>>
>> I have started working with gem5 from past 2 weeks and am trying to
>> simulate a multi-core CPU system with RISC-V ISA on gem5.
>>
>> I have written a C file where I use inline assembly snippet to grab the
>> value of mhartid (Hardware Thread id), marchid and mstatus.
>> I used this command to statically compile C code: $
>> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
>> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>>
>> I have written my multi-core python configuration code: where the system
>> has two CPU cores, each having a private
>> I cache and D cache. These cache memories are connected to shared L2
>> cache via L2 bus. The L2 cache memory
>> is connected to the memory controller via membus.
>> The code is attached or available at (python configuration file)
>> https://pastebin.com/utxxNfJg
>> I used the cache python file which Jason has provided as part of
>> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
>> The command used to simulate on gem5: $ build/RISCV/gem5.opt
>> configs/multi_core/two_core/two_core_copy.py
>>
>> After running this command, I get the console log : (console log without
>> loop) https://pastebin.com/t8rM9thk
>> From this log, I am able to get the values as follows:
>> CPU1:
>> mhartid = 0
>>  marchid = 8192
>> mstatus = 0
>>
>> CPU2:
>> mhartid = 0
>>  marchid = 8192
>> mstatus = 0
>>
>> I strongly feel that mhartid of each processor should be different. Can
>> someone explain to me why they are the same?
>>
>> Out of curiosity, I had put a loop in the C code to observe cache misses!
>> (please uncomment the loop in above C code to run! )
>> Again, I compiled the C code using the above command and simulated using
>> gem5.
>> I get a long message starting with "panic: Page table fault when
>> accessing virtual address 0x8000".
>> (console log with loop) https://pastebin.com/0xNyGkCE
>>
>> Also, my max_miss_count parameter in config.ini remains to be 0 for all
>> caches.
>> I am unable to understand this error?
>>
>> Other than this, may someone guide me to the steps of finding memory
>> trace and instruction trace for a binary executed on gem5 in RISC-V isa.
>>
>> Thanks and regards,
>> Rishabh Jain
>>
>>
>>
>>
>>
>>
>>
>>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Alec Roelke]

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 your program with
both, and it works with the Linux toolchain.  Try that and let me know if
it still fails.

-Alec

On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain  wrote:

> Hi everyone,
>
> I have started working with gem5 from past 2 weeks and am trying to
> simulate a multi-core CPU system with RISC-V ISA on gem5.
>
> I have written a C file where I use inline assembly snippet to grab the
> value of mhartid (Hardware Thread id), marchid and mstatus.
> I used this command to statically compile C code: $
> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>
> I have written my multi-core python configuration code: where the system
> has two CPU cores, each having a private
> I cache and D cache. These cache memories are connected to shared L2 cache
> via L2 bus. The L2 cache memory
> is connected to the memory controller via membus.
> The code is attached or available at (python configuration file)
> https://pastebin.com/utxxNfJg
> I used the cache python file which Jason has provided as part of
> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
> The command used to simulate on gem5: $ build/RISCV/gem5.opt
> configs/multi_core/two_core/two_core_copy.py
>
> After running this command, I get the console log : (console log without
> loop) https://pastebin.com/t8rM9thk
> From this log, I am able to get the values as follows:
> CPU1:
> mhartid = 0
>  marchid = 8192
> mstatus = 0
>
> CPU2:
> mhartid = 0
>  marchid = 8192
> mstatus = 0
>
> I strongly feel that mhartid of each processor should be different. Can
> someone explain to me why they are the same?
>
> Out of curiosity, I had put a loop in the C code to observe cache misses!
> (please uncomment the loop in above C code to run! )
> Again, I compiled the C code using the above command and simulated using
> gem5.
> I get a long message starting with "panic: Page table fault when accessing
> virtual address 0x8000".
> (console log with loop) https://pastebin.com/0xNyGkCE
>
> Also, my max_miss_count parameter in config.ini remains to be 0 for all
> caches.
> I am unable to understand this error?
>
> Other than this, may someone guide me to the steps of finding memory trace
> and instruction trace for a binary executed on gem5 in RISC-V isa.
>
> Thanks and regards,
> Rishabh Jain
>
>
>
>
>
>
>
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] panic: Page table fault when accessing virtual address 0x8000000000000000

[Rishabh Jain]

Hi everyone,

I have started working with gem5 from past 2 weeks and am trying to
simulate a multi-core CPU system with RISC-V ISA on gem5.

I have written a C file where I use inline assembly snippet to grab the
value of mhartid (Hardware Thread id), marchid and mstatus.
I used this command to statically compile C code: $
riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.

I have written my multi-core python configuration code: where the system
has two CPU cores, each having a private
I cache and D cache. These cache memories are connected to shared L2 cache
via L2 bus. The L2 cache memory
is connected to the memory controller via membus.
The code is attached or available at (python configuration file)
https://pastebin.com/utxxNfJg
I used the cache python file which Jason has provided as part of
learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
The command used to simulate on gem5: $ build/RISCV/gem5.opt
configs/multi_core/two_core/two_core_copy.py

After running this command, I get the console log : (console log without
loop) https://pastebin.com/t8rM9thk
>From this log, I am able to get the values as follows:
CPU1:
mhartid = 0
 marchid = 8192
mstatus = 0

CPU2:
mhartid = 0
 marchid = 8192
mstatus = 0

I strongly feel that mhartid of each processor should be different. Can
someone explain to me why they are the same?

Out of curiosity, I had put a loop in the C code to observe cache misses!
(please uncomment the loop in above C code to run! )
Again, I compiled the C code using the above command and simulated using
gem5.
I get a long message starting with "panic: Page table fault when accessing
virtual address 0x8000".
(console log with loop) https://pastebin.com/0xNyGkCE

Also, my max_miss_count parameter in config.ini remains to be 0 for all
caches.
I am unable to understand this error?

Other than this, may someone guide me to the steps of finding memory trace
and instruction trace for a binary executed on gem5 in RISC-V isa.

Thanks and regards,
Rishabh Jain
# -*- coding: utf-8 -*-
# Copyright (c) 2015 Jason Power
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met: redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer;
# redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution;
# neither the name of the copyright holders nor the names of its
# contributors may be used to endorse or promote products derived from
# this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Authors: Jason Power

""" Caches with options for a simple gem5 configuration script

This file contains L1 I/D and L2 caches to be used in the simple
gem5 configuration script. It uses the SimpleOpts wrapper to set up command
line options from each individual class.
"""
import m5
from m5.objects import Cache

# Add the common scripts to our path
m5.util.addToPath('../../')

from common import SimpleOpts

# Some specific options for caches
# For all options see src/mem/cache/BaseCache.py

class L1Cache(Cache):
"""Simple L1 Cache with default values"""

assoc = 2
tag_latency = 2
data_latency = 2
response_latency = 2
mshrs = 4
tgts_per_mshr = 20

def __init__(self, options=None):
super(L1Cache, self).__init__()
pass

def connectBus(self, bus):
"""Connect this cache to a memory-side bus"""
self.mem_side = bus.slave

def connectCPU(self, cpu):
"""Connect this cache's port to a CPU-side port
   This must be defined in a subclass"""
raise NotImplementedError

class L1ICache(L1Cache):
"""Simple L1 instruction cache with default values"""

# Set the default size
size = '16kB'

SimpleOpts.add_option('--l1i_size',
  help="L1 instruction cache size. Default: %s" % size)

def __init__(self, opts=None):