[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

If you're using regular magic instruction based calls to the m5 ops, then
that should work fine since you don't have to set up any virtual/physical
mappings for that to work. That also means you can just call the non _addr
version, so no problems there either. The store method will be called by
the generic GuestABI code when the return type matches the partial
specialization, which in this case is any type T. I think I see the
problem, actually. There are two versions of the pseudoInst function, one
which returns the result to the caller, and one which doesn't. The one that
returns it assumes that you don't want to store it also, although you can
tell it to do both. The one that does not return it makes the opposite
assumption. The code in the decoder passes the return value back to the
caller, so that will not automatically store the result. What it should do
is either not call the version that passes back the result (preferred), or
keep calling the current one but tell it to store the result for it anyway.
I'm not sure why I didn't do that to start with, unless it was because one
change passed each other in time while they sat in review. It could have
also just been a mistake?

Gabe

On Mon, Nov 9, 2020 at 6:37 PM Daniel Gerzhoy 
wrote:

> Hmm, I've been using magic instructions in SE mode for years now.  Jason
> can you maybe shed some light on this? Have I been getting lucky or is
> there something we are missing?
>
> I'm using TimingSimpleCPU or DerivO3CPU (this is the GPU model, so we're
> more limited).
>
> To be clear, the pseudo-instructions are being called, no problems. I can
> see them executing with the PseudoInst debug flag.
> It's just that the return values don't show up unless I explicitly set Rax
> two_byte_opcodes.isa which is how it used to work.
> (And It is working properly and consistently with Rax set explicitly)
>
> Where is the "store" in pseudo_inst_abi.hh supposed to be called from? We
> could maybe add a check for SE mode and explicitly call it at the end of
> pseudoInstWork() or something?
>
> Cheers,
>
> Dan
>
>
> On Mon, Nov 9, 2020 at 9:20 PM Gabe Black  wrote:
>
>> Using the m5 library in SE mode is somewhat uncharted waters. You'd need
>> the access to /dev/mem to be captured and to map memory in the simulation
>> and not on the host, or Very Bad Things might happen to your host computer.
>> If the functions are defined in the header but you can't use them, you
>> should make sure you're actually getting the right header and not some
>> other, older version. The code which implements the ABI for address based
>> m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets
>> the "local accessor" for the request, aka a callback which handles an
>> access which conceptually does not go out into the memory system and is
>> instead handled inside the CPU. The default, instruction based mechanism
>> will *not* work on a KVM based CPU (if that's what you're using), and so no
>> pseudo inst code of any kind will be invoked. If you're actually triggering
>> the address based mechanism but you're not using a virtual address which
>> maps to the correct physical address (the physical address is what's
>> special), then no pseudo inst code will be triggered then either. Basically
>> if you don't do the right dance to get gem5's attention, then it won't know
>> you're trying to do a pseudo instruction and will do something else
>> instead. Unfortunately exactly what gets through from whatever the CPU
>> model is to get gem5's attention varies (necessarily) based on how the CPU
>> is implemented, which is why there are all these different calling
>> mechanisms, and some attempt to organize them more systematically in the
>> utility.
>>
>> Gabe
>>
>> On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy 
>> wrote:
>>
>>> Hi Gabe,
>>>
>>> I can see where the register should be stored (line 59 in
>>> pseudo_inst_abi.hh) but I put a print there and it never gets called for
>>> the calls that I am making at least.
>>>
>>> When i try to use m5_exit_addr and other functions with that suffix I
>>> get a "error: 'm5_exit_addr' was not declared in this scope"
>>> Which makes sense because m5ops.h doesn't declare the functions, I can
>>> see they are built by macro though.
>>>
>>> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
>>> error message.
>>>
>>> Could you point me to, or could you quickly throw together an example
>>> 'hello-world' type program and build process for SE mode?
>>>
>>> Thanks,
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 Hi Gabe,

 I don't have the broken build in front of me, and it's possible it is
 because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
 error message I got when debugging this.  If c++14 works though, great.

 Thanks for the updated info -- I built the tutorial out of the old one,
 so 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hmm, I've been using magic instructions in SE mode for years now.  Jason
can you maybe shed some light on this? Have I been getting lucky or is
there something we are missing?

I'm using TimingSimpleCPU or DerivO3CPU (this is the GPU model, so we're
more limited).

To be clear, the pseudo-instructions are being called, no problems. I can
see them executing with the PseudoInst debug flag.
It's just that the return values don't show up unless I explicitly set Rax
two_byte_opcodes.isa which is how it used to work.
(And It is working properly and consistently with Rax set explicitly)

Where is the "store" in pseudo_inst_abi.hh supposed to be called from? We
could maybe add a check for SE mode and explicitly call it at the end of
pseudoInstWork() or something?

Cheers,

Dan


On Mon, Nov 9, 2020 at 9:20 PM Gabe Black  wrote:

> Using the m5 library in SE mode is somewhat uncharted waters. You'd need
> the access to /dev/mem to be captured and to map memory in the simulation
> and not on the host, or Very Bad Things might happen to your host computer.
> If the functions are defined in the header but you can't use them, you
> should make sure you're actually getting the right header and not some
> other, older version. The code which implements the ABI for address based
> m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets
> the "local accessor" for the request, aka a callback which handles an
> access which conceptually does not go out into the memory system and is
> instead handled inside the CPU. The default, instruction based mechanism
> will *not* work on a KVM based CPU (if that's what you're using), and so no
> pseudo inst code of any kind will be invoked. If you're actually triggering
> the address based mechanism but you're not using a virtual address which
> maps to the correct physical address (the physical address is what's
> special), then no pseudo inst code will be triggered then either. Basically
> if you don't do the right dance to get gem5's attention, then it won't know
> you're trying to do a pseudo instruction and will do something else
> instead. Unfortunately exactly what gets through from whatever the CPU
> model is to get gem5's attention varies (necessarily) based on how the CPU
> is implemented, which is why there are all these different calling
> mechanisms, and some attempt to organize them more systematically in the
> utility.
>
> Gabe
>
> On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy 
> wrote:
>
>> Hi Gabe,
>>
>> I can see where the register should be stored (line 59 in
>> pseudo_inst_abi.hh) but I put a print there and it never gets called for
>> the calls that I am making at least.
>>
>> When i try to use m5_exit_addr and other functions with that suffix I get
>> a "error: 'm5_exit_addr' was not declared in this scope"
>> Which makes sense because m5ops.h doesn't declare the functions, I can
>> see they are built by macro though.
>>
>> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
>> error message.
>>
>> Could you point me to, or could you quickly throw together an example
>> 'hello-world' type program and build process for SE mode?
>>
>> Thanks,
>>
>> Dan
>>
>>
>>
>>
>> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Gabe,
>>>
>>> I don't have the broken build in front of me, and it's possible it is
>>> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
>>> error message I got when debugging this.  If c++14 works though, great.
>>>
>>> Thanks for the updated info -- I built the tutorial out of the old one,
>>> so next time I'll make sure to update it accordingly.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 BTW, I do think I need to explicitly set the c++ version in the scons
 file, like in Matt's original email above. I'd probably set it to c++14
 though, to be consistent with gem5 proper. I think that will likely fix a
 build issue Bobby had with an older (7.x I think) version of gcc, where the
 default version is probably different from the compiler I'm using (10.x I
 think).

 Gabe

 On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:

> Hi folks. If you're using the magic address based version of the gem5
> ops, then you should call, for instance, m5_exit_addr and not just 
> m5_exit.
> The "normal" functions are now always the magic instructions which
> essentially only gem5 CPU models know how to execute. All call mechanisms
> are built into the library at once now so you can use the same binary on
> the KVM CPU, native gem5 CPUs, etc.
>
> You also should not change the scons files when you build. The old
> Makefile based setup required tinkering with things to get the build you
> wanted, but that is no longer necessary. If you need to, that's a bug and
> we should look into 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

Using the m5 library in SE mode is somewhat uncharted waters. You'd need
the access to /dev/mem to be captured and to map memory in the simulation
and not on the host, or Very Bad Things might happen to your host computer.
If the functions are defined in the header but you can't use them, you
should make sure you're actually getting the right header and not some
other, older version. The code which implements the ABI for address based
m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets
the "local accessor" for the request, aka a callback which handles an
access which conceptually does not go out into the memory system and is
instead handled inside the CPU. The default, instruction based mechanism
will *not* work on a KVM based CPU (if that's what you're using), and so no
pseudo inst code of any kind will be invoked. If you're actually triggering
the address based mechanism but you're not using a virtual address which
maps to the correct physical address (the physical address is what's
special), then no pseudo inst code will be triggered then either. Basically
if you don't do the right dance to get gem5's attention, then it won't know
you're trying to do a pseudo instruction and will do something else
instead. Unfortunately exactly what gets through from whatever the CPU
model is to get gem5's attention varies (necessarily) based on how the CPU
is implemented, which is why there are all these different calling
mechanisms, and some attempt to organize them more systematically in the
utility.

Gabe

On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy 
wrote:

> Hi Gabe,
>
> I can see where the register should be stored (line 59 in
> pseudo_inst_abi.hh) but I put a print there and it never gets called for
> the calls that I am making at least.
>
> When i try to use m5_exit_addr and other functions with that suffix I get
> a "error: 'm5_exit_addr' was not declared in this scope"
> Which makes sense because m5ops.h doesn't declare the functions, I can see
> they are built by macro though.
>
> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
> error message.
>
> Could you point me to, or could you quickly throw together an example
> 'hello-world' type program and build process for SE mode?
>
> Thanks,
>
> Dan
>
>
>
>
> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Gabe,
>>
>> I don't have the broken build in front of me, and it's possible it is
>> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
>> error message I got when debugging this.  If c++14 works though, great.
>>
>> Thanks for the updated info -- I built the tutorial out of the old one,
>> so next time I'll make sure to update it accordingly.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> BTW, I do think I need to explicitly set the c++ version in the scons
>>> file, like in Matt's original email above. I'd probably set it to c++14
>>> though, to be consistent with gem5 proper. I think that will likely fix a
>>> build issue Bobby had with an older (7.x I think) version of gcc, where the
>>> default version is probably different from the compiler I'm using (10.x I
>>> think).
>>>
>>> Gabe
>>>
>>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:
>>>
 Hi folks. If you're using the magic address based version of the gem5
 ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
 The "normal" functions are now always the magic instructions which
 essentially only gem5 CPU models know how to execute. All call mechanisms
 are built into the library at once now so you can use the same binary on
 the KVM CPU, native gem5 CPUs, etc.

 You also should not change the scons files when you build. The old
 Makefile based setup required tinkering with things to get the build you
 wanted, but that is no longer necessary. If you need to, that's a bug and
 we should look into it. The lines you're commenting out just set the
 default magic address, and that's only there for legacy reasons. You can
 set the address to use from the command line if you're using the m5
 utility, or by setting the m5op_addr variable if using the library. You
 still have to run map_m5_mem to make the magic physical address visible to
 userspace for the library to work, or otherwise set up a virtual to
 physical mapping if you were, for instance, running in the kernel which
 somebody was doing recently.

 If you try to use a call mechanism that isn't supported by your CPU
 model, then the behavior will be unpredictable. For x86 on the KVM CPU for
 example, the special gem5 instructions will do whatever they look like they
 should do on real hardware. That may be a nop, it may be to generate an
 undefined instruction exception, etc. If it's a nop, it will just leave
 whatever is in RAX 

[gem5-users] Re: How to create a multicore system with different frequency for each core?

[Bharadwaj, Srikant via gem5-users]

As Gabe said, you will have to set the clk_domain of each CPU while creating 
them in the config scripts.
You can create a new clock domain using the SrcClockDomain like this:
custom_clk_domain = SrcClockDomain(clock = frequency_value, voltage_domain = 
VoltageDomain(voltage = voltage_value)))

Once you create a clock domain, you can set the clk_domain for each CPU like 
this:
cpu = CPUClass(clk_domain=custom_clk_domain)
Here, CPU Class is whatever CPU you are using AtomicSimple, O3, etc.

Setting different frequency values for the custom_clk_domain will do the job.

Srikant

From: Gabe Black via gem5-users 
Sent: Monday, November 9, 2020 3:33 PM
To: gem5 users mailing list 
Cc: Đức Anh ; Gabe Black 
Subject: [gem5-users] Re: How to create a multicore system with different 
frequency for each core?

[CAUTION: External Email]
If you want the frequency of the CPUs to change independently from each other, 
I think you need to set up a ClockDomain object for each, instead of letting 
them implicitly inherit the one from the System object.

On Mon, Nov 9, 2020 at 2:26 AM Đức Anh via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hello all,

I am looking for a way to create a system with multi CPU and they have 
different frequencies. As far as I see there is a system.clk_domain that acts 
as a global frequency, and it seems like all CPUs will follow this clock 
frequency. The clock domain does receive a list of frequencies though, but it 
is for DVFS (Dynamic voltage and frequency scaling). Is there a way to create 
or mimic a system where CPUs have different frequencies?

Best regards,
Duc Anh
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hi Gabe,

I can see where the register should be stored (line 59 in
pseudo_inst_abi.hh) but I put a print there and it never gets called for
the calls that I am making at least.

When i try to use m5_exit_addr and other functions with that suffix I get a
"error: 'm5_exit_addr' was not declared in this scope"
Which makes sense because m5ops.h doesn't declare the functions, I can see
they are built by macro though.

I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
error message.

Could you point me to, or could you quickly throw together an example
'hello-world' type program and build process for SE mode?

Thanks,

Dan




On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Gabe,
>
> I don't have the broken build in front of me, and it's possible it is
> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
> error message I got when debugging this.  If c++14 works though, great.
>
> Thanks for the updated info -- I built the tutorial out of the old one, so
> next time I'll make sure to update it accordingly.
>
> Thanks,
> Matt
>
> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> BTW, I do think I need to explicitly set the c++ version in the scons
>> file, like in Matt's original email above. I'd probably set it to c++14
>> though, to be consistent with gem5 proper. I think that will likely fix a
>> build issue Bobby had with an older (7.x I think) version of gcc, where the
>> default version is probably different from the compiler I'm using (10.x I
>> think).
>>
>> Gabe
>>
>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:
>>
>>> Hi folks. If you're using the magic address based version of the gem5
>>> ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
>>> The "normal" functions are now always the magic instructions which
>>> essentially only gem5 CPU models know how to execute. All call mechanisms
>>> are built into the library at once now so you can use the same binary on
>>> the KVM CPU, native gem5 CPUs, etc.
>>>
>>> You also should not change the scons files when you build. The old
>>> Makefile based setup required tinkering with things to get the build you
>>> wanted, but that is no longer necessary. If you need to, that's a bug and
>>> we should look into it. The lines you're commenting out just set the
>>> default magic address, and that's only there for legacy reasons. You can
>>> set the address to use from the command line if you're using the m5
>>> utility, or by setting the m5op_addr variable if using the library. You
>>> still have to run map_m5_mem to make the magic physical address visible to
>>> userspace for the library to work, or otherwise set up a virtual to
>>> physical mapping if you were, for instance, running in the kernel which
>>> somebody was doing recently.
>>>
>>> If you try to use a call mechanism that isn't supported by your CPU
>>> model, then the behavior will be unpredictable. For x86 on the KVM CPU for
>>> example, the special gem5 instructions will do whatever they look like they
>>> should do on real hardware. That may be a nop, it may be to generate an
>>> undefined instruction exception, etc. If it's a nop, it will just leave
>>> whatever is in RAX in RAX.
>>>
>>> Also, argument values and return values are now handled by a layer which
>>> knows and applies the actual ABI rules for a given ISA and for the specific
>>> types of the arguments and return value. There should be no reason to
>>> change the code which is calling the pseudo instruction to explicitly set
>>> RAX, especially if you're using the address based calling mechanism which
>>> doesn't go through that path at all.
>>>
>>> Gabe
>>>
>>> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 Hi Dan,

 My comment was just a general comment on the m5ops -- I thought you
 were using the "old" format for building m5ops and that might have been the
 problem.  Sounds like it wasn't.

 I think pushing a fix to develop and tagging Gabe and Jason as
 reviewers is probably the right strategy.

 Thanks,
 Matt

 On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
 wrote:

> I found the issue and fixed it.
>
> The return value wasn't being put into the Rax register in
> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>
> 0x4: BasicOperate::gem5Op({{
> uint64_t ret;
> bool recognized =
> PseudoInst::pseudoInst(
> xc->tcBase(), IMMEDIATE, ret);
> if (!recognized)
> fault = std::make_shared();
> Rax = ret;
>
> //<< }}, IsNonSpeculative);
>
>   This code was simplified with the new abi stuff and the Rax = ret;
> must have 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Matt Sinclair via gem5-users]

Hi Gabe,

I don't have the broken build in front of me, and it's possible it is
because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
error message I got when debugging this.  If c++14 works though, great.

Thanks for the updated info -- I built the tutorial out of the old one, so
next time I'll make sure to update it accordingly.

Thanks,
Matt

On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
gem5-users@gem5.org> wrote:

> BTW, I do think I need to explicitly set the c++ version in the scons
> file, like in Matt's original email above. I'd probably set it to c++14
> though, to be consistent with gem5 proper. I think that will likely fix a
> build issue Bobby had with an older (7.x I think) version of gcc, where the
> default version is probably different from the compiler I'm using (10.x I
> think).
>
> Gabe
>
> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:
>
>> Hi folks. If you're using the magic address based version of the gem5
>> ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
>> The "normal" functions are now always the magic instructions which
>> essentially only gem5 CPU models know how to execute. All call mechanisms
>> are built into the library at once now so you can use the same binary on
>> the KVM CPU, native gem5 CPUs, etc.
>>
>> You also should not change the scons files when you build. The old
>> Makefile based setup required tinkering with things to get the build you
>> wanted, but that is no longer necessary. If you need to, that's a bug and
>> we should look into it. The lines you're commenting out just set the
>> default magic address, and that's only there for legacy reasons. You can
>> set the address to use from the command line if you're using the m5
>> utility, or by setting the m5op_addr variable if using the library. You
>> still have to run map_m5_mem to make the magic physical address visible to
>> userspace for the library to work, or otherwise set up a virtual to
>> physical mapping if you were, for instance, running in the kernel which
>> somebody was doing recently.
>>
>> If you try to use a call mechanism that isn't supported by your CPU
>> model, then the behavior will be unpredictable. For x86 on the KVM CPU for
>> example, the special gem5 instructions will do whatever they look like they
>> should do on real hardware. That may be a nop, it may be to generate an
>> undefined instruction exception, etc. If it's a nop, it will just leave
>> whatever is in RAX in RAX.
>>
>> Also, argument values and return values are now handled by a layer which
>> knows and applies the actual ABI rules for a given ISA and for the specific
>> types of the arguments and return value. There should be no reason to
>> change the code which is calling the pseudo instruction to explicitly set
>> RAX, especially if you're using the address based calling mechanism which
>> doesn't go through that path at all.
>>
>> Gabe
>>
>> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Dan,
>>>
>>> My comment was just a general comment on the m5ops -- I thought you were
>>> using the "old" format for building m5ops and that might have been the
>>> problem.  Sounds like it wasn't.
>>>
>>> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
>>> is probably the right strategy.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
>>> wrote:
>>>
 I found the issue and fixed it.

 The return value wasn't being put into the Rax register in
 src/arch/x86/isa/decoder/two_byte_opcodes.isa

 0x4: BasicOperate::gem5Op({{
 uint64_t ret;
 bool recognized =
 PseudoInst::pseudoInst(
 xc->tcBase(), IMMEDIATE, ret);
 if (!recognized)
 fault = std::make_shared();
 Rax = ret;

 //<<>>> }}, IsNonSpeculative);

   This code was simplified with the new abi stuff and the Rax = ret;
 must have been lost in the shuffle.

 I could push the fix to develop, or should I just make an issue on Jira?

 Best,

 Dan

 On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
 wrote:

> Let me further say that I know that the magic instructions are being
> called. I am just getting bogus return values.
>
> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy <
> daniel.gerz...@gmail.com> wrote:
>
>> Hi Matt,
>>
>> Thanks for this, it's very helpful. However after following the
>> instructions (I had to extrapolate a little because of the directory
>> structure changes you mentioned) I get the same result: Nill returns from
>> the magic instructions.
>> Actually It isn't nill, but a constant no matter what. If I compile
>> my program with -O0 its nill, if with -O2 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

BTW, I do think I need to explicitly set the c++ version in the scons file,
like in Matt's original email above. I'd probably set it to c++14 though,
to be consistent with gem5 proper. I think that will likely fix a build
issue Bobby had with an older (7.x I think) version of gcc, where the
default version is probably different from the compiler I'm using (10.x I
think).

Gabe

On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:

> Hi folks. If you're using the magic address based version of the gem5 ops,
> then you should call, for instance, m5_exit_addr and not just m5_exit. The
> "normal" functions are now always the magic instructions which essentially
> only gem5 CPU models know how to execute. All call mechanisms are built
> into the library at once now so you can use the same binary on the KVM CPU,
> native gem5 CPUs, etc.
>
> You also should not change the scons files when you build. The old
> Makefile based setup required tinkering with things to get the build you
> wanted, but that is no longer necessary. If you need to, that's a bug and
> we should look into it. The lines you're commenting out just set the
> default magic address, and that's only there for legacy reasons. You can
> set the address to use from the command line if you're using the m5
> utility, or by setting the m5op_addr variable if using the library. You
> still have to run map_m5_mem to make the magic physical address visible to
> userspace for the library to work, or otherwise set up a virtual to
> physical mapping if you were, for instance, running in the kernel which
> somebody was doing recently.
>
> If you try to use a call mechanism that isn't supported by your CPU model,
> then the behavior will be unpredictable. For x86 on the KVM CPU for
> example, the special gem5 instructions will do whatever they look like they
> should do on real hardware. That may be a nop, it may be to generate an
> undefined instruction exception, etc. If it's a nop, it will just leave
> whatever is in RAX in RAX.
>
> Also, argument values and return values are now handled by a layer which
> knows and applies the actual ABI rules for a given ISA and for the specific
> types of the arguments and return value. There should be no reason to
> change the code which is calling the pseudo instruction to explicitly set
> RAX, especially if you're using the address based calling mechanism which
> doesn't go through that path at all.
>
> Gabe
>
> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Dan,
>>
>> My comment was just a general comment on the m5ops -- I thought you were
>> using the "old" format for building m5ops and that might have been the
>> problem.  Sounds like it wasn't.
>>
>> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
>> is probably the right strategy.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
>> wrote:
>>
>>> I found the issue and fixed it.
>>>
>>> The return value wasn't being put into the Rax register in
>>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>>
>>> 0x4: BasicOperate::gem5Op({{
>>> uint64_t ret;
>>> bool recognized =
>>> PseudoInst::pseudoInst(
>>> xc->tcBase(), IMMEDIATE, ret);
>>> if (!recognized)
>>> fault = std::make_shared();
>>> Rax = ret;
>>>
>>> //<<>> }}, IsNonSpeculative);
>>>
>>>   This code was simplified with the new abi stuff and the Rax = ret;
>>> must have been lost in the shuffle.
>>>
>>> I could push the fix to develop, or should I just make an issue on Jira?
>>>
>>> Best,
>>>
>>> Dan
>>>
>>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
>>> wrote:
>>>
 Let me further say that I know that the magic instructions are being
 called. I am just getting bogus return values.

 On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
 wrote:

> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you
> provided, the supplemental instructions, and extrapolating based on the
> directory structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
>  env['ABI'] = 'x86'
>  

[gem5-users] Re: How to create a multicore system with different frequency for each core?

[Gabe Black via gem5-users]

If you want the frequency of the CPUs to change independently from each
other, I think you need to set up a ClockDomain object for each, instead of
letting them implicitly inherit the one from the System object.

On Mon, Nov 9, 2020 at 2:26 AM Đức Anh via gem5-users 
wrote:

> Hello all,
>
> I am looking for a way to create a system with multi CPU and they have
> different frequencies. As far as I see there is a system.clk_domain that
> acts as a global frequency, and it seems like all CPUs will follow this
> clock frequency. The clock domain does receive a list of frequencies
> though, but it is for DVFS (Dynamic voltage and frequency scaling). Is
> there a way to create or mimic a system where CPUs have different
> frequencies?
>
> Best regards,
> Duc Anh
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: --Script parameter cannot be used

[Gabe Black via gem5-users]

The --script option works by setting up a file for the m5 utility to read
in from the actual on disk init script found in the disk image. If the m5
utility isn't called, or is called incorrectly, or the script it extracts
isn't then run, the --script option won't work.

It's been a while, but I think the m5 utility command you want is "m5
readfile".

Gabe

On Sun, Nov 8, 2020 at 10:55 PM -17 via gem5-users 
wrote:

> Hi all:
> I try to use the “-- script ”parameter when running gem5 FS mode. I start
> gem5 as follows:
> /build/ARM/gem5.opt -d fs_results/rcstest configs/example/fs.py
> --cpu-type=AtomicSimpleCPU -n 1
> --disk-image=/home/fusiqing/gem5-20.1/2017sys/full_system_images/disks/gem5_ubuntu16.img
>
> --kernel=/home/fusiqing/gem5-20.1/2017sys/full_system_images/binaries/vmlinux
>
> --script=/home/gem5-20.1/configs/boot/halt.sh
> I started the simulation, but the script didn't run.The same goes for
> other files under /example/boot/.
> But in /config.ini I can see:
> readfile=/home/gem5-20.1/configs/boot/halt.sh
> May I ask what error occurred when I used the script?
> Thanks in advance.
>
>
> --
> /**/
> NUDTSiqing Fu
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to simulate multithread, multicore and multiprocessor system ?

[Ayaz Akram via gem5-users]

Hi Duc,

By passing  a list of CPUs to the system.cpu (as in the attached Python
script), you are creating a multicore CPU (CPU here refers to a core).
Secondly, if your CPU has SMT enabled, you should be able to pass multiple
processes to the workload option.

Btw, there is already a JIRA issue created for the problem you are running
into: https://gem5.atlassian.net/browse/GEM5-803

-Ayaz

On Mon, Nov 9, 2020 at 2:18 AM Đức Anh via gem5-users 
wrote:

> Hello all,
>
> I am trying to create a system having multiple CPUs by passing a list of
> CPU to the system.cpu. So far it works with TimingSimpleCPU, but for the
> DerivO3CPU it crashes. I include the crash log, the python config file, and
> the C workload file. I am using gem5 20.1, pulled from the stable
> branch, gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04), python 2.7.17. The
> command line I use is:
> ./build/X86/gem5.opt configs/tutorial/two_core.py
> The 2 binary files for 2 workloads are almost the same, I just change the
> text in printf, and the number of loops.
>
> I also wonder that by passing a list of CPU to the system.cpu, am I
> creating a system is 1 multicore CPU or a system with multiple separate
> CPU? And how to pass multiple workloads on 1 CPU? I saw it accept a list,
> but it throws an error if I pass a list with more than 1 workload.
>
> Best regards,
> Duc Anh
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

Hi folks. If you're using the magic address based version of the gem5 ops,
then you should call, for instance, m5_exit_addr and not just m5_exit. The
"normal" functions are now always the magic instructions which essentially
only gem5 CPU models know how to execute. All call mechanisms are built
into the library at once now so you can use the same binary on the KVM CPU,
native gem5 CPUs, etc.

You also should not change the scons files when you build. The old Makefile
based setup required tinkering with things to get the build you wanted, but
that is no longer necessary. If you need to, that's a bug and we should
look into it. The lines you're commenting out just set the default magic
address, and that's only there for legacy reasons. You can set the address
to use from the command line if you're using the m5 utility, or by setting
the m5op_addr variable if using the library. You still have to run
map_m5_mem to make the magic physical address visible to userspace for the
library to work, or otherwise set up a virtual to physical mapping if you
were, for instance, running in the kernel which somebody was doing recently.

If you try to use a call mechanism that isn't supported by your CPU model,
then the behavior will be unpredictable. For x86 on the KVM CPU for
example, the special gem5 instructions will do whatever they look like they
should do on real hardware. That may be a nop, it may be to generate an
undefined instruction exception, etc. If it's a nop, it will just leave
whatever is in RAX in RAX.

Also, argument values and return values are now handled by a layer which
knows and applies the actual ABI rules for a given ISA and for the specific
types of the arguments and return value. There should be no reason to
change the code which is calling the pseudo instruction to explicitly set
RAX, especially if you're using the address based calling mechanism which
doesn't go through that path at all.

Gabe

On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Dan,
>
> My comment was just a general comment on the m5ops -- I thought you were
> using the "old" format for building m5ops and that might have been the
> problem.  Sounds like it wasn't.
>
> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
> is probably the right strategy.
>
> Thanks,
> Matt
>
> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
> wrote:
>
>> I found the issue and fixed it.
>>
>> The return value wasn't being put into the Rax register in
>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>
>> 0x4: BasicOperate::gem5Op({{
>> uint64_t ret;
>> bool recognized =
>> PseudoInst::pseudoInst(
>> xc->tcBase(), IMMEDIATE, ret);
>> if (!recognized)
>> fault = std::make_shared();
>> Rax = ret;
>>
>> //<<> }}, IsNonSpeculative);
>>
>>   This code was simplified with the new abi stuff and the Rax = ret; must
>> have been lost in the shuffle.
>>
>> I could push the fix to develop, or should I just make an issue on Jira?
>>
>> Best,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
>> wrote:
>>
>>> Let me further say that I know that the magic instructions are being
>>> called. I am just getting bogus return values.
>>>
>>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
>>> wrote:
>>>
 Hi Matt,

 Thanks for this, it's very helpful. However after following the
 instructions (I had to extrapolate a little because of the directory
 structure changes you mentioned) I get the same result: Nill returns from
 the magic instructions.
 Actually It isn't nill, but a constant no matter what. If I compile my
 program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.

 To clarify, are these updated instructions specifically meant to fix
 this issue I am running into? Or just general instructions to build m5op.o

 Here are the specific changes I made according to the link you
 provided, the supplemental instructions, and extrapolating based on the
 directory structure change.

 1. In SConsopts I commented both:

 --- a/util/m5/src/abi/x86/SConsopts
 +++ b/util/m5/src/abi/x86/SConsopts
 @@ -27,8 +27,8 @@ Import('*')

  env['ABI'] = 'x86'
  get_abi_opt('CROSS_COMPILE', '')
 -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
 -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
 +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
 +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')

  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)

 2. In SConstruct I added:

 --- a/util/m5/SConstruct
 +++ b/util/m5/SConstruct
 @@ -44,7 +44,9 @@ def abspath(d):

  # Universal settings.
  main.Append(CXXFLAGS=[ 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Matt Sinclair via gem5-users]

Hi Dan,

My comment was just a general comment on the m5ops -- I thought you were
using the "old" format for building m5ops and that might have been the
problem.  Sounds like it wasn't.

I think pushing a fix to develop and tagging Gabe and Jason as reviewers is
probably the right strategy.

Thanks,
Matt

On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
wrote:

> I found the issue and fixed it.
>
> The return value wasn't being put into the Rax register in
> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>
> 0x4: BasicOperate::gem5Op({{
> uint64_t ret;
> bool recognized = PseudoInst::pseudoInst(
> xc->tcBase(), IMMEDIATE, ret);
> if (!recognized)
> fault = std::make_shared();
> Rax = ret;
>
> //<< }}, IsNonSpeculative);
>
>   This code was simplified with the new abi stuff and the Rax = ret; must
> have been lost in the shuffle.
>
> I could push the fix to develop, or should I just make an issue on Jira?
>
> Best,
>
> Dan
>
> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
> wrote:
>
>> Let me further say that I know that the magic instructions are being
>> called. I am just getting bogus return values.
>>
>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
>> wrote:
>>
>>> Hi Matt,
>>>
>>> Thanks for this, it's very helpful. However after following the
>>> instructions (I had to extrapolate a little because of the directory
>>> structure changes you mentioned) I get the same result: Nill returns from
>>> the magic instructions.
>>> Actually It isn't nill, but a constant no matter what. If I compile my
>>> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>>>
>>> To clarify, are these updated instructions specifically meant to fix
>>> this issue I am running into? Or just general instructions to build m5op.o
>>>
>>> Here are the specific changes I made according to the link you provided,
>>> the supplemental instructions, and extrapolating based on the directory
>>> structure change.
>>>
>>> 1. In SConsopts I commented both:
>>>
>>> --- a/util/m5/src/abi/x86/SConsopts
>>> +++ b/util/m5/src/abi/x86/SConsopts
>>> @@ -27,8 +27,8 @@ Import('*')
>>>
>>>  env['ABI'] = 'x86'
>>>  get_abi_opt('CROSS_COMPILE', '')
>>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>
>>>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>>
>>> 2. In SConstruct I added:
>>>
>>> --- a/util/m5/SConstruct
>>> +++ b/util/m5/SConstruct
>>> @@ -44,7 +44,9 @@ def abspath(d):
>>>
>>>  # Universal settings.
>>>  main.Append(CXXFLAGS=[ '-O2' ])
>>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>>  main.Append(CCFLAGS=[ '-O2' ])
>>>  main.Append(CPPPATH=[ common_include ])
>>>
>>> The compilation process compiles m5op.S with gcc though, so c++11
>>> doesn't have any effect on it. Not sure if that matters.
>>>
>>> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions
>>> but I am a little wary of m5_mmap
>>>
>>> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It
>>> looks like nothing? Do I need to link it?
>>>
>>> *Is there something inside the program I need to do before calling magic
>>> instructions that has to do with m5_mmap?*
>>>
>>> Thanks for your help,
>>>
>>> Dan
>>>
>>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
>>> wrote:
>>>
 Hi Dan,

 In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
 created.  I had created a homework assignment for my course about it:
 https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
 (see #2), but this is now already out of date as the location of some files
 changed.  The updated instructions are:

 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
 current lines 46 and 47:

 main.Append(CXXFLAGS=[ '-O2' ])
 *+main.Append(CXXFLAGS=[ '-std=c++11' ])*

 main.Append(CCFLAGS=[ '-O2' ])

 2.  Now run the same command you ran in step 2 of the above link:

 scons build/x86/out/m5

 3.  This will create the same two .o files in step 2 of the above link,
 in the same places (although the location of m5op.o may have changed
 to include/gem5 util/m5/build/x86/abi/x86/ according to some of the
 students in my course).
 Matt

 On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
 gem5-users@gem5.org> wrote:

> Hey all,
>
> I've recently updated to using the dev branch for my GCN3 simulations.
> I've noticed that I am now getting return values of 0 for every magic
> instruction (m5_rpns for instance).
>
> Is there a special way I need to be compiling/linking 

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

I found the issue and fixed it.

The return value wasn't being put into the Rax register in
src/arch/x86/isa/decoder/two_byte_opcodes.isa

0x4: BasicOperate::gem5Op({{
uint64_t ret;
bool recognized = PseudoInst::pseudoInst(
xc->tcBase(), IMMEDIATE, ret);
if (!recognized)
fault = std::make_shared();
Rax = ret;

//<<
wrote:

> Let me further say that I know that the magic instructions are being
> called. I am just getting bogus return values.
>
> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
> wrote:
>
>> Hi Matt,
>>
>> Thanks for this, it's very helpful. However after following the
>> instructions (I had to extrapolate a little because of the directory
>> structure changes you mentioned) I get the same result: Nill returns from
>> the magic instructions.
>> Actually It isn't nill, but a constant no matter what. If I compile my
>> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>>
>> To clarify, are these updated instructions specifically meant to fix
>> this issue I am running into? Or just general instructions to build m5op.o
>>
>> Here are the specific changes I made according to the link you provided,
>> the supplemental instructions, and extrapolating based on the directory
>> structure change.
>>
>> 1. In SConsopts I commented both:
>>
>> --- a/util/m5/src/abi/x86/SConsopts
>> +++ b/util/m5/src/abi/x86/SConsopts
>> @@ -27,8 +27,8 @@ Import('*')
>>
>>  env['ABI'] = 'x86'
>>  get_abi_opt('CROSS_COMPILE', '')
>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>
>>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>
>> 2. In SConstruct I added:
>>
>> --- a/util/m5/SConstruct
>> +++ b/util/m5/SConstruct
>> @@ -44,7 +44,9 @@ def abspath(d):
>>
>>  # Universal settings.
>>  main.Append(CXXFLAGS=[ '-O2' ])
>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>  main.Append(CCFLAGS=[ '-O2' ])
>>  main.Append(CPPPATH=[ common_include ])
>>
>> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
>> have any effect on it. Not sure if that matters.
>>
>> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
>> I am a little wary of m5_mmap
>>
>> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
>> like nothing? Do I need to link it?
>>
>> *Is there something inside the program I need to do before calling magic
>> instructions that has to do with m5_mmap?*
>>
>> Thanks for your help,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
>> wrote:
>>
>>> Hi Dan,
>>>
>>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>>> created.  I had created a homework assignment for my course about it:
>>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>>> (see #2), but this is now already out of date as the location of some files
>>> changed.  The updated instructions are:
>>>
>>> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>>> current lines 46 and 47:
>>>
>>> main.Append(CXXFLAGS=[ '-O2' ])
>>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>>
>>> main.Append(CCFLAGS=[ '-O2' ])
>>>
>>> 2.  Now run the same command you ran in step 2 of the above link:
>>>
>>> scons build/x86/out/m5
>>>
>>> 3.  This will create the same two .o files in step 2 of the above link,
>>> in the same places (although the location of m5op.o may have changed to
>>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>>> students in my course).
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 Hey all,

 I've recently updated to using the dev branch for my GCN3 simulations.
 I've noticed that I am now getting return values of 0 for every magic
 instruction (m5_rpns for instance).

 Is there a special way I need to be compiling/linking m5ops.S to get
 the return values to show up correctly? Or might this be a bug?

 Thanks,

 Dan
 ___
 gem5-users mailing list -- gem5-users@gem5.org
 To unsubscribe send an email to gem5-users-le...@gem5.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Let me further say that I know that the magic instructions are being
called. I am just getting bogus return values.

On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
wrote:

> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you provided,
> the supplemental instructions, and extrapolating based on the directory
> structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
>  env['ABI'] = 'x86'
>  get_abi_opt('CROSS_COMPILE', '')
> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>
>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>
> 2. In SConstruct I added:
>
> --- a/util/m5/SConstruct
> +++ b/util/m5/SConstruct
> @@ -44,7 +44,9 @@ def abspath(d):
>
>  # Universal settings.
>  main.Append(CXXFLAGS=[ '-O2' ])
> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>  main.Append(CCFLAGS=[ '-O2' ])
>  main.Append(CPPPATH=[ common_include ])
>
> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
> have any effect on it. Not sure if that matters.
>
> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
> I am a little wary of m5_mmap
>
> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
> like nothing? Do I need to link it?
>
> *Is there something inside the program I need to do before calling magic
> instructions that has to do with m5_mmap?*
>
> Thanks for your help,
>
> Dan
>
> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
> wrote:
>
>> Hi Dan,
>>
>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>> created.  I had created a homework assignment for my course about it:
>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>> (see #2), but this is now already out of date as the location of some files
>> changed.  The updated instructions are:
>>
>> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>> current lines 46 and 47:
>>
>> main.Append(CXXFLAGS=[ '-O2' ])
>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>
>> main.Append(CCFLAGS=[ '-O2' ])
>>
>> 2.  Now run the same command you ran in step 2 of the above link:
>>
>> scons build/x86/out/m5
>>
>> 3.  This will create the same two .o files in step 2 of the above link,
>> in the same places (although the location of m5op.o may have changed to
>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>> students in my course).
>> Matt
>>
>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hey all,
>>>
>>> I've recently updated to using the dev branch for my GCN3 simulations.
>>> I've noticed that I am now getting return values of 0 for every magic
>>> instruction (m5_rpns for instance).
>>>
>>> Is there a special way I need to be compiling/linking m5ops.S to get the
>>> return values to show up correctly? Or might this be a bug?
>>>
>>> Thanks,
>>>
>>> Dan
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hi Matt,

Thanks for this, it's very helpful. However after following the
instructions (I had to extrapolate a little because of the directory
structure changes you mentioned) I get the same result: Nill returns from
the magic instructions.
Actually It isn't nill, but a constant no matter what. If I compile my
program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.

To clarify, are these updated instructions specifically meant to fix
this issue I am running into? Or just general instructions to build m5op.o

Here are the specific changes I made according to the link you provided,
the supplemental instructions, and extrapolating based on the directory
structure change.

1. In SConsopts I commented both:

--- a/util/m5/src/abi/x86/SConsopts
+++ b/util/m5/src/abi/x86/SConsopts
@@ -27,8 +27,8 @@ Import('*')

 env['ABI'] = 'x86'
 get_abi_opt('CROSS_COMPILE', '')
-env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
-env.Append(CCFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CCFLAGS='-DM5OP_ADDR=0x')

 env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
 env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)

2. In SConstruct I added:

--- a/util/m5/SConstruct
+++ b/util/m5/SConstruct
@@ -44,7 +44,9 @@ def abspath(d):

 # Universal settings.
 main.Append(CXXFLAGS=[ '-O2' ])
+main.Append(CXXFLAGS=[ '-std=c++11' ])
 main.Append(CCFLAGS=[ '-O2' ])
 main.Append(CPPPATH=[ common_include ])

The compilation process compiles m5op.S with gcc though, so c++11 doesn't
have any effect on it. Not sure if that matters.

3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but I
am a little wary of m5_mmap

What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
like nothing? Do I need to link it?

*Is there something inside the program I need to do before calling magic
instructions that has to do with m5_mmap?*

Thanks for your help,

Dan

On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
wrote:

> Hi Dan,
>
> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
> created.  I had created a homework assignment for my course about it:
> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
> (see #2), but this is now already out of date as the location of some files
> changed.  The updated instructions are:
>
> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
> current lines 46 and 47:
>
> main.Append(CXXFLAGS=[ '-O2' ])
> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>
> main.Append(CCFLAGS=[ '-O2' ])
>
> 2.  Now run the same command you ran in step 2 of the above link:
>
> scons build/x86/out/m5
>
> 3.  This will create the same two .o files in step 2 of the above link, in
> the same places (although the location of m5op.o may have changed to
> include/gem5 util/m5/build/x86/abi/x86/ according to some of the students
> in my course).
> Matt
>
> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hey all,
>>
>> I've recently updated to using the dev branch for my GCN3 simulations.
>> I've noticed that I am now getting return values of 0 for every magic
>> instruction (m5_rpns for instance).
>>
>> Is there a special way I need to be compiling/linking m5ops.S to get the
>> return values to show up correctly? Or might this be a bug?
>>
>> Thanks,
>>
>> Dan
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Matt Sinclair via gem5-users]

Hi Dan,

In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
created.  I had created a homework assignment for my course about it:
https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
(see #2), but this is now already out of date as the location of some files
changed.  The updated instructions are:

1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
current lines 46 and 47:

main.Append(CXXFLAGS=[ '-O2' ])
*+main.Append(CXXFLAGS=[ '-std=c++11' ])*

main.Append(CCFLAGS=[ '-O2' ])

2.  Now run the same command you ran in step 2 of the above link:

scons build/x86/out/m5

3.  This will create the same two .o files in step 2 of the above link, in
the same places (although the location of m5op.o may have changed to
include/gem5 util/m5/build/x86/abi/x86/ according to some of the students
in my course).
Matt

On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
gem5-users@gem5.org> wrote:

> Hey all,
>
> I've recently updated to using the dev branch for my GCN3 simulations.
> I've noticed that I am now getting return values of 0 for every magic
> instruction (m5_rpns for instance).
>
> Is there a special way I need to be compiling/linking m5ops.S to get the
> return values to show up correctly? Or might this be a bug?
>
> Thanks,
>
> Dan
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hey all,

I've recently updated to using the dev branch for my GCN3 simulations. I've
noticed that I am now getting return values of 0 for every magic
instruction (m5_rpns for instance).

Is there a special way I need to be compiling/linking m5ops.S to get the
return values to show up correctly? Or might this be a bug?

Thanks,

Dan
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Some Problems About m5.fork()

[Tracy Mac via gem5-users]

Hi ALL！
I try to use m5.fork() function to fork child process of gem5，but I can't
use it well.
I call it in the simulation.py(configs/common) , but it has no effect.
I don't know how to ues it ,before m5.simulate() function or after
m5.simulate() function.
I hope you could give me some suggestions.


[image: image.png]
My command line :sudo ./build/ARM/gem5.opt -d /home/tracy/Desktop/Result
configs/example/fs.py --cpu-type=ArmV8KvmCPU
--kernel=/home/tracy/Desktop/fs_image/vmlinux_tracy.euler
--disk-image=/home/tracy/Desktop/fs_image/tracy.img
Host OS: Ubuntu 18.04
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] How to create a multicore system with different frequency for each core?

[Đức Anh via gem5-users]

Hello all,

I am looking for a way to create a system with multi CPU and they have
different frequencies. As far as I see there is a system.clk_domain that
acts as a global frequency, and it seems like all CPUs will follow this
clock frequency. The clock domain does receive a list of frequencies
though, but it is for DVFS (Dynamic voltage and frequency scaling). Is
there a way to create or mimic a system where CPUs have different
frequencies?

Best regards,
Duc Anh
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] How to simulate multithread, multicore and multiprocessor system ?

[Đức Anh via gem5-users]

Hello all,

I am trying to create a system having multiple CPUs by passing a list of
CPU to the system.cpu. So far it works with TimingSimpleCPU, but for the
DerivO3CPU it crashes. I include the crash log, the python config file, and
the C workload file. I am using gem5 20.1, pulled from the stable
branch, gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04), python 2.7.17. The
command line I use is:
./build/X86/gem5.opt configs/tutorial/two_core.py
The 2 binary files for 2 workloads are almost the same, I just change the
text in printf, and the number of loops.

I also wonder that by passing a list of CPU to the system.cpu, am I
creating a system is 1 multicore CPU or a system with multiple separate
CPU? And how to pass multiple workloads on 1 CPU? I saw it accept a list,
but it throws an error if I pass a list with more than 1 workload.

Best regards,
Duc Anh
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version 20.1.0.0
gem5 compiled Nov  5 2020 18:11:27
gem5 started Nov  9 2020 09:57:07
gem5 executing on Dauto98-ROG-Strix-G531GD, pid 10493
command line: ./build/X86/gem5.opt configs/tutorial/two_core.py

warn: l2bus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: l2bus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: interrupts.int_master is deprecated. `int_master` is now called 
`int_requestor`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: interrupts.int_slave is deprecated. `int_slave` is now called 
`int_responder`
warn: l2bus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: l2bus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: interrupts.int_master is deprecated. `int_master` is now called 
`int_requestor`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: interrupts.int_slave is deprecated. `int_slave` is now called 
`int_responder`
warn: l2bus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
Global frequency set at 1 ticks per second
warn: No dot file generated. Please install pydot to generate the dot file and 
pdf.
warn: DRAM device capacity (8192 Mbytes) does not match the address range 
assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7000
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation
info: Entering event queue @ 0.  Starting simulation...
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
Looping goodbye, 0 time
Looping hello, 0 time
Looping hello, 1 time
Looping goodbye, 1 time
Looping hello, 2 time
Looping goodbye, 2 time
Looping hello, 3 time
Looping goodbye, 3 time
Looping hello, 4 time
Looping goodbye, 4 time
Looping hello, 5 time
Looping goodbye, 5 time
Looping hello, 6 time
Looping goodbye, 6 time
Looping hello, 7 time
Looping goodbye, 7 time
Looping goodbye, 8 time
Looping goodbye, 9 time
hello world
Goodbye world
gem5.opt: build/X86/cpu/o3/cpu.cc:823: void 
FullO3CPU::removeThread(ThreadID) [with Impl = O3CPUImpl; ThreadID = 
short int]: Assertion `commit.rob->isEmpty(tid)' failed.
Program aborted at tick 322773000
--- BEGIN LIBC BACKTRACE ---
./build/X86/gem5.opt(_Z15print_backtracev+0x2c)[0x55a6c77d158c]
./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x55a6c77e40aa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7f31e43db8a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f31e29b7f47]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f31e29b98b1]
/lib/x86_64-linux-gnu/libc.so.6(+0x3042a)[0x7f31e29a942a]
/lib/x86_64-linux-gnu/libc.so.6(+0x304a2)[0x7f31e29a94a2]
./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE12removeThreadEs+0x194)[0x55a6c79ef664]
./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE11haltContextEs+0x64)[0x55a6c79ef994]
./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE11exitThreadsEv+0x8d)[0x55a6c79f05ad]
./build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xa5)[0x55a6c77d9a65]

[gem5-users] can not bootup with "--dual" option

[Liyichao via gem5-users]

Hi All:
 I use “--dual” to bootup with 2 system, but can not bootup them, when 
I delete “--dual”, it can be bootup.

 My cmd is “./build/ARM/gem5.opt  configs/example/fs.py  
--cpu-type=ArmV8KvmCPU --kernel=vmlinux -n 1 --machine-type=VExpress_GEM5_V1 
--disk-image=expanded-aarch64-ubuntu-trusty-headless.img --cpu-clock=2.6GHz  
--mem-type=DDR4_2933_16x4_new --mem-size=8GB --dual”

 I use gdb to step, find that the gem5 still not get a event and always 
in doSimLoop()’s loop:


 186 assert(!eventq->empty());
(gdb)
187 assert(curTick() <= eventq->nextTick() &&
(gdb)

190 if (async_event && testAndClearAsyncEvent()) {
(gdb)
216 Event *exit_event = eventq->serviceOne();
(gdb)
217 if (exit_event != NULL) {
(gdb)
186 assert(!eventq->empty());
(gdb)
187 assert(curTick() <= eventq->nextTick() &&
(gdb)
190 if (async_event && testAndClearAsyncEvent()) {
(gdb)
216 Event *exit_event = eventq->serviceOne();
(gdb)
217 if (exit_event != NULL) {
(gdb)
186 assert(!eventq->empty());
(gdb)
187 assert(curTick() <= eventq->nextTick() &&
(gdb)
190 if (async_event && testAndClearAsyncEvent()) {
(gdb)
216 Event *exit_event = eventq->serviceOne();
(gdb)
217 if (exit_event != NULL) {
(gdb)
186 assert(!eventq->empty());
(gdb)


李翼超（Charlie）

华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
部门：计算系统与组件开发部 [云与计算BG]
手　　机：15858232899
电子邮件：liyic...@huawei.com
地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] failed to bootup with dist-gem5.sh on ARM

[Liyichao via gem5-users]

Hi All:
 I use the GEM5 v20.0.0.1 with dist-gem5.sh, my cmd is

“bash $DIST_M5/util/dist/gem5-dist.sh -n 2 -r $DIST_M5/rundir -c 
$DIST_M5/ckptdir -s $DIST_M5/configs/dist/sw.py -f 
$DIST_M5/configs/example/fs.py --fs-args --kernel=$M5_PATH/binaries/vmlinux 
--machine-type=VExpress_GEM5_V1  
--disk-image=$M5_PATH/disks/expanded-aarch64-ubuntu-trusty-headless.img 
--cpu-clock=2GHz --mem-type=DDR4_2933_16x4_new --mem-ranks=4 --mem-size=16GB 
--sys-clock=1600MHz --num-cpus=2 --cpu-type=ArmV8KvmCPU --cf-args 
--ethernet-linkdelay=10us --ethernet-linkspeed=10Gbps -x 
$DIST_M5/build/ARM/gem5.opt --m5-args --debug-flags=DistEthernet”



 But it will fail to bootup with the error log below, any one has some 
experience on it?





root@ubuntu-kunpeng920-1:/home/l00515693/gem5_repo/gem5/rundir# vim log.0
  1 warn: CheckedInt already exists in allParams. This may be caused by the 
Python 2.7 compatibility layer.
  2 warn: Enum already exists in allParams. This may be caused by the Python 
2.7 compatibility layer.
  3 warn: ScopedEnum already exists in allParams. This may be caused by the 
Python 2.7 compatibility layer.
  4 /usr/local/lib/python2.7/dist-packages/pydot-1.4.1-py2.7.egg/pydot.py:18: 
UserWarning: Couldn't import dot_parser, loading of dot files will not be 
possible.
  5 gem5 Simulator System.  http://gem5.org
  6 gem5 is copyrighted software; use the --copyright option for details.
  7
  8 gem5 version 20.0.0.3
  9 gem5 compiled Nov  9 2020 09:24:56
10 gem5 started Nov  9 2020 16:32:32
11 gem5 executing on ubuntu-kunpeng920-1, pid 14971
12 command line: /home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt -d 
/home/l00515693/gem5_repo/gem5/rundir/m5out.0 --debug-flags=DistEthernet 
/home/l00515693/gem5_repo/gem5/configs/example/fs.py 
--kernel=/home/l00515693/fs-image_fx/binaries/vmlinux 
--machine-type=VExpress_GEM5_V1 
--disk-image=/home/l00515693/fs-image_fx/disks/expanded-aarch64-ubunt
u-trusty-headless.img --cpu-clock=2GHz --mem-type=DDR4_2933_16x4_new 
--mem-ranks=4 --mem-size=16GB --sys-clock=1600MHz --num-cpus=2 
--cpu-type=ArmV8KvmCPU --ethernet-linkdelay=10us 
--ethernet-linkspeed=10Gbps 
--checkpoint-dir=/home/l00515693/gem5_repo/gem5/ckptdir/m5out.0 --dist 
--dist-rank=0 --dist-size=2 --dist-server-name=127.0.0.1 --dist-serv
er-port=2200
13
14 info: Standard input is not a terminal, disabling listeners.
15 Global frequency set at 1 ticks per second
16   0: etherlink: DistEtherLink::DistEtherLink() link delay:1000 
ticksPerByte:800
17   0: global: DistIface() ctor rank:0
18 warn: DRAM device capacity (65536 Mbytes) does not match the address range 
assigned (16384 Mbytes)
19 info: kernel located at: /home/l00515693/fs-image_fx/binaries/vmlinux
20 warn: Highest ARM exception-level set to AArch32 but the workload is for 
AArch64. Assuming you wanted these to match.
21 warn: Sockets disabled, not accepting vnc client connections
22 warn: Sockets disabled, not accepting terminal connections
23   0: etherlink: DistEtherLink::init() called
24   0: global: Connecting to 127.0.0.1:2200
25   0: global: Connected, waiting for ack (distIfaceId:0
26 info: Link okay  (iface:0 -> switch iface:0)
27 info: Next dist synchronisation tick is changed to 52000.
28 info: Dist synchronisation interval is changed to 1000.
29 warn: Sockets disabled, not accepting gdb connections
30 warn: CoherentXBar testsys.membus has no snooping ports attached!
31 info: Using bootloader at address 0x10
32 info: Using kernel entry physical address at 0x8008
33 info: Loading DTB file: 
/home/l00515693/gem5_repo/gem5/rundir/m5out.0/testsys.dtb at address 0x8800
34  REAL SIMULATION 
35   0: etherlink: DistEtherLink::startup() called
36   0: global: DistIface::startup() started
37 gem5 has encountered a segmentation fault!
38
39 --- BEGIN LIBC BACKTRACE ---
40 
/home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(_Z15print_backtracev+0x40)[0xb1837810]
41 /home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(+0x12a41c4)[0xb18481c4]
42 linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa5465688]
43 
/home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(_ZN9DistIface9SyncEvent5startEv+0xc8)[0xb1a1dd08]
44 
/home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(_ZN9DistIface7startupEv+0x1b8)[0xb1a1e590]
45 
/home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(_ZN13DistEtherLink7startupEv+0x2f8)[0xb1a21628]
46 /home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(+0xf637a0)[0xb15077a0]
47 /home/l00515693/gem5_repo/gem5/build/ARM/gem5.opt(+0xd04734)[0xb12a8734]
48 
/usr/lib/aarch64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7278)[0xa5194bd0]
49 --- END LIBC BACKTRACE ---


李翼超（Charlie）

华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
部门：计算系统与组件开发部 [云与计算BG]
手　　机：15858232899
电子邮件：liyic...@huawei.com
地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]