[gem5-dev] Re: [gem5-users] Assistance Required - Assertion Failure in RegFile

[Giacomo Travaglini via gem5-dev]

Hi,

I believe this has been fixed by the following patch [1] which is currently 
merged on the develop branch and will be part of v23.0.
Let me know if it fixes your problem

Kind Regards

Giacomo

[1]: https://gem5-review.googlesource.com/c/public/gem5/+/70697

From: Alexandra-Nicoleta DAVID via gem5-users 
Sent: 14 June 2023 11:41
To: gem5-users ; gem5-dev ; 429442672 
<429442...@qq.com>
Cc: Alexandra-Nicoleta DAVID 
Subject: [gem5-users] Assistance Required - Assertion Failure in RegFile


Dear gem5 Community,

I am currently using the gem5 simulator version 22.1.0.0, compiled on June 14, 
2023, for my research work and I have encountered an issue that I need help 
with.

During the simulation, the program aborts with an assertion failure in the 
register file. The error message is:

cCopy code

gem5.opt: build/ARM/cpu/regfile.hh:75: const Reg& gem5::RegFile::reg(size_t) 
const [with Reg = long unsigned int; size_t = long unsigned int]: Assertion 
`sizeof(Reg) == _regBytes && idx < _size' failed. Program aborted at tick 
94517000

The command that I used to run the simulation is:

bashCopy code

./build/ARM/gem5.opt --debug-flags=MinorExecuteOp --debug-file=fadd1.txt 
configs/example/arm/starter_se.py --cpu="hpi" --num-cores=1 
"/home/david1136/ARM/se-benchmarks/FloatMM"

I have tried to diagnose the problem myself, but I haven't been able to 
identify the root cause. I believe this issue might be related to an incorrect 
register access, although I am not entirely certain. I have checked my 
configuration and my setup, and everything appears to be correct.

Could you provide me with some guidance on how to troubleshoot this problem, or 
indicate whether this is a known issue that could be resolved with a patch or 
an update to the gem5 version I am using?

Any help you can provide would be greatly appreciated.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: State of Arm SVE2 in gem5

[Giacomo Travaglini via gem5-dev]

Hi Jason,

So far only a subset of SVE2 instructions have been pushed/merged to develop 
(some by me, some by Prajwal, here CCed)

Kind Regards

Giacomo

From: Jason Lowe-Power 
Date: Friday, 2 June 2023 at 15:47
To: gem5 Developer List 
Cc: Giacomo Travaglini 
Subject: State of Arm SVE2 in gem5
Hi Giacomo,

I've noticed that you've been pushing a number of updates to the Arm ISA, some 
of which are implementing Arm SVE2 instructions (I believe). Could you let us 
know what the current status is of these instructions? Have all of them been 
integrated into gem5 or just a subset?

Thanks!
Jason
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Giacomo Travaglini via gem5-dev]

Congrats to Jason and to everyone who’s making this possible!

About the naming, I wonder if we could provide a different python module per 
ruby protocol.
That would allow us to avoid prefixing in favour of something like:

$from m5.objects.mi_example import L1Cache_Controller

or

$from m5.objects.msi import L1Cache_Controller

Kind Regards

Giacomo


From: Jason Lowe-Power via gem5-dev 
Date: Thursday, 31 March 2022 at 18:43
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Request for comments/reviews: Multiple Ruby protocols in a 
single binary
Hi all,

For as long as gem5 has been gem5, you have had to build a different gem5 
binary if you want to use a different Ruby protocol. Making it possible to 
build multiple protocols has been on the roadmap for a long time (at least as 
long as I've been involved with the project).

I'm excited to say that we've been able to do this (finally), and we have a set 
of changesets on gerrit for review/comments feedback.

There are a couple of todo items before it's merged, and a couple of 
user-facing changes that we could not find a way to make fully backwards 
compatible. More on this below.

Let me know what you think, and let me know if there are any questions! I'm 
excited to see this get in for gem5-22.0.

Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

Non-backwards compatible changes:
Previously each SLICC protocol used the same names for the same machine time. 
E.g., MI_example has an `L1Cache_Controller` and MSI has an 
`L1Cache_Controller`. These names were automatically generated from the 
MachineType (L1Cache) + "_Controller". Now, since we want to be able to compile 
these two protocols at the same time, we need to make sure there are no 
(python) name clashes. So, these have been renamed to have the protocol name 
prepended onto the machine name (e.g., `MI_example_L1Cache_Controller`).

For most people using Ruby, we can provide backwards compatibility. If you 
simply instantiate the `L1Cache_Controller` in python, we can provide a new 
factory function that does the "right" thing. However, if you inherit from 
`L1Cache_Controller` to specialize the controller, this won't work.

The user-facing change is if you have any local ruby protocol configuration 
files which use inheritance with the controllers, you will have to update the 
controller classes to use the name of the protocol prepended on the controller 
name.

We have updated all of the configurations that are in the gem5 repo. You will 
see warnings if you use the old backwards-compatible names (including with 
Ruby.py).

The only other user-facing change (I think, reviewers, please point out if I'm 
wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check the 
protocol that was built, you will now need to use `getRubyProtocol` (also 
available in `m5.defines`). However, we are currently supporting backwards 
compatibility here, but there will be no warning when we drop backwards 
compatibility (I expect this to be in a couple of releases).

To do items
- Correctly integrate this with scons (and the new kconfig). See 
https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP that needs 
to be updated.
- Update the website. Assuming there are no major flaws in our implementation, 
we will update the website soon (before the changes are committed). The main 
updates are the two user-facing changes described above, but I expect some 
updates to how Ruby/SLICC works as well.
- Add another commit that checks if the protocol is in the list of built 
protocols instead of a single protocol. I'm holding off on this one until item 
#1 is complete. This will also include a new command-line parameter to set the 
"main" protocol for backwards compatibility.

Cheers,
Jason

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #166

[Giacomo Travaglini via gem5-dev]

Hi Bobby,

No sure, maybe something weird on the XML side? It is weird though; the plot 
plugin has been running for some days and this is the first time we are getting 
this kind of error.
Let’s see if disabling it fixes the issue

Giacomo


From: Bobby Bruce 
Date: Monday, 21 March 2022 at 19:05
To: gem5 Developer List , Giacomo Travaglini 

Subject: Re: [gem5-dev] Build failed in Jenkins: nightly #166
It seems like the tests were failing due to the Plots plugin running into an 
error: https://jenkins.gem5.org/job/nightly/166/console. I have disabled this 
and suspect the Nightly tests should pass now.

@Giacomo: Any idea what's going on here? Though I've turned this off, i've 
taken note of the values you had for the plots plugin:

```
Plot group: All Regressions
Plot title: CPU execution time
Plot description: CPU execution time
Plot description: CPU execution time
Number of builds to include: 6
Plot style: Line
Data series file -> Load data from xml file using xpath -> XPath Expression: 
//testsuite[@name='realview-simple-atomic-ARM-x86_64-opt']
```

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616


web: https://www.bobbybruce.net



On Sat, Mar 19, 2022 at 5:54 PM jenkins-no-reply--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
See 

Changes:

[Bobby R. Bruce] tests: Add 'kvm' tag to tests

[Bobby R. Bruce] tests,ext: Fix so ex/include regex are applied after defaults

[Bobby R. Bruce] tests: Add KVM Tests to the nightly run

[gabe.black] arch-vega: Replace deprecated Stats namespace recently 
reintroduced.

[matthew.poremba] arch-vega: Mark global instructions executed as global

[mattdsinclair] configs, gpu-compute: change default GPU reg allocator to 
dynamic


--
[...truncated 3.73 MB...]
 [SHCC] RISCV/ext/softfloat/f64_le_quiet.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_lt.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_lt_quiet.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_mulAdd.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_mul.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_rem.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_roundToInt.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_sqrt.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_sub.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_f128.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_f16.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_f32.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_i32.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_i32_r_minMag.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_i64.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_i64_r_minMag.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_ui32.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_ui32_r_minMag.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_ui64.c -> .os
 [SHCC] RISCV/ext/softfloat/f64_to_ui64_r_minMag.c -> .os
 [SHCC] RISCV/ext/softfloat/i32_to_f128.c -> .os
 [SHCC] RISCV/ext/softfloat/i32_to_f16.c -> .os
 [SHCC] RISCV/ext/softfloat/i32_to_f32.c -> .os
 [SHCC] RISCV/ext/softfloat/i32_to_f64.c -> .os
 [SHCC] RISCV/ext/softfloat/i64_to_f128.c -> .os
 [SHCC] RISCV/ext/softfloat/i64_to_f16.c -> .os
 [SHCC] RISCV/ext/softfloat/i64_to_f32.c -> .os
 [SHCC] RISCV/ext/softfloat/i64_to_f64.c -> .os
 [SHCC] RISCV/ext/softfloat/s_add128.c -> .os
 [SHCC] RISCV/ext/softfloat/s_add256M.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addCarryM.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addComplCarryM.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addMagsF128.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addMagsF16.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addMagsF32.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addMagsF64.c -> .os
 [SHCC] RISCV/ext/softfloat/s_addM.c -> .os
 [SHCC] RISCV/ext/softfloat/s_approxRecip_1Ks.c -> .os
 [SHCC] RISCV/ext/softfloat/s_approxRecip32_1.c -> .os
 [SHCC] RISCV/ext/softfloat/s_approxRecipSqrt_1Ks.c -> .os
 [SHCC] RISCV/ext/softfloat/s_approxRecipSqrt32_1.c -> .os
 [SHCC] RISCV/ext/softfloat/s_commonNaNToF128UI.c -> .os
 [SHCC] RISCV/ext/softfloat/s_commonNaNToF16UI.c -> .os
 [SHCC] RISCV/ext/softfloat/s_commonNaNToF32UI.c -> .os
 [SHCC] RISCV/ext/softfloat/s_commonNaNToF64UI.c -> .os
 [SHCC] RISCV/ext/softfloat/s_compare128M.c -> .os
 [SHCC] RISCV/ext/softfloat/s_compare96M.c -> .os
 [SHCC] RISCV/ext/softfloat/s_countLeadingZeros16.c -> .os
 [SHCC] RISCV/ext/softfloat/s_countLeadingZeros32.c -> .os
 [SHCC] RISCV/ext/softfloat/s_countLeadingZeros64.c -> .os
 [SHCC] RISCV/ext/softfloat/s_countLeadingZeros8.c -> .os
 [SHCC] RISCV/ext/softfloat/s_eq128.c -> .os
 [SHCC] RISCV/ext/softfloat/s_f128UIToCommonNaN.c -> .os
 [SHCC] RISCV/ext/softfloat/s_f16UIToCommonNaN.c -> .os
 [SHCC] RISCV/ext/softfloat/s_f32UIToCommonNaN.c -> .os
 [SHCC] RISCV/ext/softfloat/s_f64UIToCommonNaN.c -> .os
 [SHCC] 

[gem5-dev] Re: All tests failing: Please don't commit anything!

[Giacomo Travaglini via gem5-dev]

Hi Jason,

https://gem5-review.googlesource.com/c/public/gem5/+/57349 might fix the 
compiler-check failure (gcc-version-7)

Kind Regards

Giacomo

From: Jason Lowe-Power via gem5-dev 
Date: Saturday, 5 March 2022 at 17:27
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] All tests failing: Please don't commit anything!
Hi gem5 developers!

You may or may not have noticed that as of this morning (3/5) all of the tests 
on our Jenkins server are failing. This includes the nightly tests, weekly 
tests, and the compiler tests.

I'd like to ask everyone to refrain from committing anything else to develop 
until these tests are passing again. It's incredibly difficult to track down 
the offending commit when the target is moving and new changes may introduce 
new bugs.

If you have some time to help track down these issues, we would also greatly 
appreciate the help! You can find all of the logs from the failing tests on the 
jenkins server: https://jenkins.gem5.org/. All of the build artifacts are 
available for download.

If you find any leads, please let us know! Given that today is a Saturday, it 
will be Monday at the earliest that we will be able to dive in ourselves.

Thanks,
Jason
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: resource downloader failure

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

A possible workaround could be to use the --bin-path option in testlib

Kind Regards

Giacomo

From: Gabe Black via gem5-dev 
Date: Tuesday, 1 March 2022 at 04:10
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] resource downloader failure
Hi folks. I've been trying to run tests locally, and I've been running into 
occasional flakiness due to a problem with the resource downloader. This 
reminds me somewhat of flakiness I was seeing in kokoro as well, so they are 
probably related. The error output is this:

$ cat 
./testing-results/SuiteUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/TestUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/simerr
warn: .kvm_vm already has parent not resetting parent.
Note: kvm_vm is not a parameter of X86Board
warn: (Previously declared as .processor.kvm_vm
HTTPError: HTTP Error 429: Too Many Requests

At:
  /usr/lib/python3.10/urllib/request.py(643): http_error_default
  /usr/lib/python3.10/urllib/request.py(496): _call_chain
  /usr/lib/python3.10/urllib/request.py(563): error
  /usr/lib/python3.10/urllib/request.py(634): http_response
  /usr/lib/python3.10/urllib/request.py(525): open
  /usr/lib/python3.10/urllib/request.py(216): urlopen
  build/GCN3_X86/python/gem5/resources/downloader.py(77): _get_resources_json
  build/GCN3_X86/python/gem5/resources/downloader.py(207): 
get_resources_json_obj
  build/GCN3_X86/python/gem5/resources/resource.py(162): __init__
  /home/gblack/gem5/work/tests/gem5/configs/boot_kvm_fork_run.py(205): 
  build/GCN3_X86/python/m5/main.py(434): main


Is there a limit that needs to be bumped up? Some way to consolidate requests 
so we're not hitting the existing limit?

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Kokoro failures

[Giacomo Travaglini via gem5-dev]

Thanks Bobby,

Here are some examples:
https://gem5-review.googlesource.com/c/public/gem5/+/56426
https://gem5-review.googlesource.com/c/public/gem5/+/55964/6
https://gem5-review.googlesource.com/c/public/gem5/+/56303/1

(If you check the verification history of the last patch you can see it first 
failed due to timeout. This has become very common in the past days; failing 
the first run, rebasing to re-trigger kokoro and hoping next time It won’t 
timeout)

Kind Regards

Giacomo

From: Bobby Bruce 
Date: Thursday, 3 February 2022 at 19:52
To: Giacomo Travaglini 
Cc: gem5-dev@gem5.org 
Subject: Re: Kokoro failures
Are there examples of this timeout happening recently? I can't see any over the 
past week.

There's a separate issue affecting one of Gabe's patches that I'm looking into 
(here: https://gem5-review.googlesource.com/c/public/gem5/+/56303) but these 
appear to be due to dynamic libraries not linking correctly.

The only change in testing in the last month has been using clang-11 instead of 
clang-9 to do the clang compilation check. It's possible clang-11 takes longer 
than clang-9 did? In December I increase the timeout to 7 hours to give us more 
time to run tests as we were experiencing some timeouts, I think due to the 
inclusion of some more tests.

We could move some tests to the Nightly run fairly easily.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616


web: https://www.bobbybruce.net



On Thu, Feb 3, 2022 at 7:00 AM Giacomo Travaglini 
mailto:giacomo.travagl...@arm.com>> wrote:
Hi all,

I am seeing a lot of failures on kokoro due to timeouts.
Have we recently added some extra tests to the quick/pre-submit regressions?

Kind Regards

Giacomo
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Kokoro failures

[Giacomo Travaglini via gem5-dev]

Hi all,

I am seeing a lot of failures on kokoro due to timeouts.
Have we recently added some extra tests to the quick/pre-submit regressions?

Kind Regards

Giacomo
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Incorrect disassembly/register width in Aarch64 ?

[Giacomo Travaglini via gem5-dev]

Hi Arthur, this is a known issue in disassembling and arises when multiple 
register operands have different width. For example your load is likely using 
the 64-bit SP as base register and loading the value into 32-bit w1.

Gem5 is not capturing this per-operand-width and it is reporting a single 
intWidth of 64. A proper fix would involve having a per-operand intWidth 
variable (or something similar)

Kind Regards

Giacomo

From: Arthur Perais via gem5-dev 
Date: Tuesday, 30 November 2021 at 17:06
To: gem5-dev@gem5.org 
Cc: Arthur Perais 
Subject: [gem5-dev] Incorrect disassembly/register width in Aarch64 ?
Hi all,

I am using a fairly old gem5 version
(566c113de1eb08ccbfba6e4b074f96c9977a0e16 from Nov 2020), but I noticed
that the disassembly (and the register width) of some Aarch64
instructions seems to be incorrectly reported by gem5.

Notably, instruction :

ldr  w1, [sp, #168] (0xb940abe1 according to objdump)

Is reported in gem5 as

ldr  x1, [sp, #168] (0xf94057e1 according to objdump)

And the getIntWidth() method that can be called on the staticInst
reports 64 (when it reports 32 for instructions that write into a "word"
register).

I have not found a patch addressing this but maybe this has been fixed
already, or maybe this is known to happen under some specific
configuration of an Aarch64 system.

Best,

Arthur Perais
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: reduce the number of checkpoints in the ARM checkpoint test?

[Giacomo Travaglini via gem5-dev]

> -Original Message-
> From: Gabe Black 
> Sent: 12 October 2021 10:28
> To: Giacomo Travaglini 
> Cc: gem5 Developer List 
> Subject: Re: [gem5-dev] reduce the number of checkpoints in the ARM
> checkpoint test?
>
> Hi Giacomo. it's definitely minutes, probably between 5 and 10 per
> checkpoint.

I see

>
> Another thing I noticed is that often, the test infrastructure will schedule 
> the
> typically two final and longer running tests (I think both ARM boot tests) at
> the same time, but sometimes I'll wait and wait for the checkpoint one to run,
> and then it will start the other ARM test serially after it, even though I 
> passed
> in -t 6 (run 6 tests in parallel). It's just a guess, but is the framework 
> setting up
> 6 static schedules of tests and then feeding them to 6 threads to run? Or is 
> it
> dynamically scheduling them based on when different threads finish their
> current task? If it's the first, I think the second would be a great
> improvement as well, since that will save the occasional unnecessary
> serialization of long running tests.

As far as I can see we are using the multiprocessing.Pool object [1] which 
means a worker process
Will be used as soon as it becomes available. There shouldn't be dependencies 
between linux boot tests, except
For the regex matching tests which complete in almost zero time

>
> Gabe
>

Kind Regards

Giacomo

[1]: https://github.com/gem5/gem5/blob/stable/ext/testlib/runner.py#L177
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: reduce the number of checkpoints in the ARM checkpoint test?

[Giacomo Travaglini via gem5-dev]

Hi Gabe, are we talking about seconds or minutes (per run)?
In the latter case I agree we could reduce the max_number to 3.

If it is just saving us few seconds then it is probably not worth it IMHO

Kind Regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 12 October 2021 09:18
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] reduce the number of checkpoints in the ARM
> checkpoint test?
>
> I notice that the long pole in running the quick regressions seems to be the
> tests/gem5/configs/realview64-simple-atomic-checkpoint.py test which
> does some sort of ARM linux boot (I assume) and checkpoints 5 times as it
> comes up. Would it make sense to reduce that down to 3 or even 2? I think
> that would get largely the same test coverage but hopefully take
> substantially less time to run.
>
> Alternatively we could increase the interval and decrease the max number of
> checkpoints to get more separate (and more different?) state for
> checkpoints.
>
> Longer term, we should look at why taking (and restoring?) checkpoints is so
> slow and try to fix that, but nearer term, when I have to run lots of these 
> in a
> row, it would be really nice to trim them down by a good number of minutes
> a time.
>
> Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing ARM dual CPU tests?

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

>From an Arm perspective, could you make sure you are using the latest 
>bootloader?
I remember there was a change some time ago which required the bootloader to be 
rebuilt

You could either download latest tarball from 
https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries

Or rebuild the bootloader yourself

Kind Regards

Giacomo


> -Original Message-
> From: Jason Lowe-Power via gem5-dev 
> Sent: 22 September 2021 17:12
> To: gem5 Developer List 
> Cc: Gabe Black ; Jason Lowe-Power
> 
> Subject: [gem5-dev] Re: failing ARM dual CPU tests?
>
> Hey Gabe,
>
>
> To solve this and the x86 test issue you've been having, I think there are a
> couple of possibilities:
>
> 1. Can you use the docker images that kokoro uses? This will guarantee that
> you are using the *exact* same "host" setup when running gem5. I think this
> is the only way to have a consistent set of tests without something like
> Bazel's reproducible build and test.
> 2. We're open to modifying and improving the tests. If the tests don't work
> for you, they probably don't work for others as well. Improving the
> documentation so it's more clear how to use the tests or improving the
> testing infrastructure or modifying the tests so that they work more easily 
> for
> more people would be a *very* welcome contribution.
>
> Cheers,
> Jason
>
> On Tue, Sep 21, 2021 at 6:22 PM Gabe Black via gem5-dev  d...@gem5.org  > wrote:
>
>
>   Hi folks. When I run the test script main.py locally on an otherwise
> passing tree, I get 8 test failures. 6 of those are from x86 dynamic linking 
> tests
> which use a host library which uses a system call gem5 doesn't implement.
> That is annoying, but I understand that problem.
>
>   The other 2 are from ARM dual CPU tests (like realview64-simple-
> timing-dual-ARM-x86_64-opt-MatchFileRegex) which fail because the
> second CPU doesn't come up, and the check doesn't see the message it
> expects.
>
>   This is very surprising to me, since I don't think these tests would
> have any host dependence, and I'm *pretty* sure that the files they use
> would come from the resources thing and should be up to date, etc. The
> system in the test seems to otherwise boot up, it's just that the second CPU
> never comes online and linux prints an error message about it instead of the
> normal one.
>
>   Does anybody know of something else I can try to update, etc, which
> might fix these tests? Could there be stale system files it's using floating
> around somewhere?
>
>   I would really like to get that sorted out, since that could affect
> whether I can successfully test my locked memory helper function change,
> since the earlier version of that had caused problems with O3 multi-CPU tests
> for ARM, sort of right in line with this false positive on these tests.
>
>   Thanks!
>   Gabe
>   ___
>   gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
>   To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
>   %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: overview/documentation/tests for vector register related stuff?

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 09 August 2021 11:02
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: overview/documentation/tests for vector register
> related stuff?
>
> I've done a bit of digging so far, and I think I've figured out a bit about 
> the
> rename mode.
>
> 1. This is only used by ARM to handle the difference in how registers are
> renamed in aarch64 vs otherwise.
> 2. This is handled in O3 by detecting a squash in the CPU and then checking
> the aarch64 bit of the PCState.
> 3. If this changes, then O3 potentially shuffles things around to make 
> register
> chunks contiguous, and starts renaming things differently.
> 4. The only way to switch in or out of aarch64 is through a fault.

Yes, just to be more precise, it is happening by issuing a fault or by 
returning from a fault (this is just to make it clear
the switch can happen with a non faulting instruction like an ERET)

>
> This leads me to a few conclusions.
>
> 1. Having the aarch64 bit in the PCState structure is probably not necessary
> and may actually be harmful because it makes that structure larger and
> slower to move around. This value does *not* change quickly or frequently,
> and only changes as part of an already heavy mode switch. It does not need
> to be predicted/predictable like a next PC, like something like thumb mode
> might.

You can figure out the execution mode (AArch64/AArch32) in a different way by 
inspecting
The PSTATE. So I can see the redundancy. However, inspecting the PSTATE/CPSR 
from the TC is probably not
going to be faster. We need to know the aarch64 in the decoder, so I guess we 
could cache it in there.

In any case IMO I don't think removing it from the PCState is gonna affect in 
any measurable way simulation time.

> 2. The O3 CPU is checking renaming mode *way* more often than it really
> needs to. Almost every single squash is *not* a switch to/from 64 bit mode,
> but *every* switch involves that check, even in ISAs that don't even *have*
> rename modes.
> 3. The rename semantics switch can be handled right in the fault object when
> it implements the faulting context switch. It can detect that a switch is
> necessary and enact it without all the extra checks.

Totally agree on point 2. About point 3, yes you could handle it in the fault 
object and in the ERET instruction.
That would mean leaking uarch code in the arch directory. In other words, 
having some *O3 specific* code in
The arch directory. This is not ideal IMHO as it is bounding the arch code to a 
single cpu model

> 4. ARM can implement SVE, etc, using two different register files, one which
> is indexed by element for 32 bit mode, and one which is indexed by vector
> for 64 bit mode. The mode switch can copy values between the register files,
> and we can remove what I suspect is a lot of machinery from O3 by just
> letting it manage two different register files simply, instead of managing one
> with two different personalities. This also makes the register files much more
> homogenous and easier to generalize. A "real" CPU may not want to waste
> transistors, buses, etc, for two separate register files, but in the end it
> doesn't matter if the behavior is the same. This is all just in how O3 does 
> its
> bookkeeping, and a redundant register file is nearly free for gem5.
>

I would love to see a cleaner implementation! But I am not entirely sure your 
solution is much different from what we are having now:
Sure there is only one storage [1] but all remaining data structures are 
duplicated (check veRegIds and vecElemIds as an example, or the vecElem/vecReg 
freeLists [2]).
In fact, we are already copying values from one register file to the other when 
switching from Rename::Full to Rename::Elem [3].
I honestly believe having two different regfiles is the source of all our 
problems as it is forcing us to switch/copy values when a
Change in rename happens. What the implementation should have been like, is one 
single set of vector data structures with 2 different views.
No synchronization needed; AArch32 use the Enum view and AArch64 use the Full 
view.

> Please let me know if this is correct, and I'll start chopping away. Some way 
> to
> test my changes would be very helpful, since otherwise I'll just be hoping for
> the best :-P.

I would recommend you to cross-compile a FP application for AArch32 and 
execute it on a AArch64 Linux kernel (with syscalls to make sure
we change rename mode and we don't rely on the intervention of the scheduler). 
You could even cross-compile the same source for AArch64 and
execute it as a separate process, and OFC to multiplex them on the same CPU.

>
> Gabe

Kind Regards

Giacomo

[1]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L86
[2]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/free_list.hh#L142
[3]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/rename_map.cc#L211
IMPORTANT NOTICE: 

[gem5-dev] Re: "epic" Jira issue to track multi-ISA gem5

[Giacomo Travaglini via gem5-dev]

This is great, thanks Gabe!

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 25 July 2021 12:45
> To: gem5 Developer List ; Earl Ou
> 
> Cc: Gabe Black 
> Subject: [gem5-dev] "epic" Jira issue to track multi-ISA gem5
>
> To help lay out a roadmap and scope for my ongoing effort to make gem5
> support more than one ISA at a time, I created an "epic" issue here:
>
> https://gem5.atlassian.net/browse/GEM5-1048
>
>
> The sub-tasks are linked off of that one, and I put a bit of explanation under
> each one. I tried to be fairly thorough, but of course I could have forgotten
> something, or there may even be aspects that I/we aren't aware of yet.
>
> Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: DPRINTF_UNCONDITIONAL deprecation

[Giacomo Travaglini via gem5-dev]

Thanks Gabe,

The performance benefit is difficult to measure as the macro is not currently 
used; it could provide negligible or no improvement at all depending on the 
compiler and on where it could be used.
So the question is not whether it makes gem5 faster now, it is more about 
giving our users the chance to write *potentially* faster code.

As you were saying the debug::Flag check could be removed by a later change.
I'd argue though that a user should be able to catch the unexpected prints. In 
some cases, those prints would be even useful, signalling some debug only logic
has slipped within the non-tracing code. If we take human error into 
consideration I am more worried about the dangers of silently executing debug 
only
code even when no debug flag is specified.

To provide a concrete example from the before mentioned patch [1], it means 
executing the printQueue method without printing anything.
This won't happen if we use a DPRINTF_UNCONDITIONAL

Please let me know your thoughts,

Kind Regards

Giacomo

[1]: 
https://gem5-review.googlesource.com/c/public/gem5/+/47199/7/src/mem/cache/prefetch/queued.cc


> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 15 July 2021 23:30
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: DPRINTF_UNCONDITIONAL deprecation
>
> Meant to reply to the list.
>
> On Thu, Jul 15, 2021 at 3:29 PM Gabe Black   > wrote:
>
>
>   Hi Giacomo. The DPRINTF_UNCONDITIONAL macro was used in one
> place, and that I converted that place to a normal DPRINTF. Please see here
> for explanation for that change, and justification for this type of change in
> general:
>
>   commit 07074f40e5a7e6000262a5d37f0be836f6ac92a9
>   Author: Gabe Black   >
>   Date:   Thu Apr 29 20:09:32 2021 -0700
>
>   There are several problems with DPRINTF_UNCONDITIONAL. First,
> while macros don't take any run time overhead because they just turn into
> c++, and of course you could have just typed that c++ to begin with, they do
> have overhead because they make the code more complex and fragile, and
> obfuscate what's actually going on. This isn't cost incurred (directly) by the
> computer, but by the people who work on the code. This may eventually
> translate into cost to the computer, because when code is harder to work
> with, it's less likely to be completely correct or optimized.
>
>   Second, the compiler is much better at figuring out and keeping track
> of what code is reachable each time you build. Code paths change, new
> callers are added, etc, and what may have been already guarded by a debug
> variable may not any more. Also, the compiler can already merge together or
> drop checks it knows are unnecessary, so I think we may frequently be
> dropping something the compiler is already going to drop for us. I think
> DPRINTF_UNCONDITIONAL may be a bit of premature optimization without
> measurement to say that it's really necessary or even useful.
>
>   I acknowledge that the lack of performance benefit is also an
> assumption on my part though, and please let me know if you can measure a
> difference in the scenarios you're thinking of. I still think the complexity 
> and
> fragility argument apply, but if the difference is substantial it might be 
> still be
> worth it.
>
>   Gabe
>
>
>
>   On Thu, Jul 15, 2021 at 6:08 AM Giacomo Travaglini
> mailto:giacomo.travagl...@arm.com> >
> wrote:
>
>
>   Hi Gabe,
>
>   The DPRINTF_UNCONDITIONAL macro has been deprecated
> in develop [1] and  the deprecation is going to be official in v21.1.
>   As far as I understood, the reason why it has been
> deprecated is because it was not used in gem5.
>
>   I am proposing to remove the deprecation. IMO that macro is
> useful when the Debug flag has already been checked outside of the
>   Debug print. We recently merged a patch [2] that would have
> benefitted from the use of DPRINTF_UNCONDITIONAL. I am quite confident
>   I can find some other parts of gem5 where the
> DPRINTF_UNCONDITIONAL would have been a better printing choice.
>   I believe speed should still be a prime concern even if we are
> tracing, to make the debugging process faster and smoother for our users,
> especially
>   As it comes with no cost (the definition of a macro)
>
>   Let me know what you think about this, and if you don't have
> any objection I will push a revert of the patch you posted, and I will convert
>   some DPRINT into a DPRINTF_UNCONDITIONAL
>
>   Kind Regards
>
>   Giacomo
>
>   [1]: https://gem5-
> review.googlesource.com/c/public/gem5/+/44987
>   [2]: https://gem5-
> review.googlesource.com/c/public/gem5/+/47199/7/src/mem/cache/prefet
> ch/queued.cc#134
>   IMPORTANT NOTICE: The contents of this email and any
> 

[gem5-dev] DPRINTF_UNCONDITIONAL deprecation

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

The DPRINTF_UNCONDITIONAL macro has been deprecated in develop [1] and  the 
deprecation is going to be official in v21.1.
As far as I understood, the reason why it has been deprecated is because it was 
not used in gem5.

I am proposing to remove the deprecation. IMO that macro is useful when the 
Debug flag has already been checked outside of the
Debug print. We recently merged a patch [2] that would have benefitted from the 
use of DPRINTF_UNCONDITIONAL. I am quite confident
I can find some other parts of gem5 where the DPRINTF_UNCONDITIONAL would have 
been a better printing choice.
I believe speed should still be a prime concern even if we are tracing, to make 
the debugging process faster and smoother for our users, especially
As it comes with no cost (the definition of a macro)

Let me know what you think about this, and if you don't have any objection I 
will push a revert of the patch you posted, and I will convert
some DPRINT into a DPRINTF_UNCONDITIONAL

Kind Regards

Giacomo

[1]: https://gem5-review.googlesource.com/c/public/gem5/+/44987
[2]: 
https://gem5-review.googlesource.com/c/public/gem5/+/47199/7/src/mem/cache/prefetch/queued.cc#134
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 namespace

[Giacomo Travaglini via gem5-dev]

Hi all,

I agree with Daniel's analysis and solution, as enforcing snake_case for 
namespaces would probably make everyone happy.
We could in theory adopt namespace aliases for backward compatibility, to 
transition smoothly from one "convention" (PascalCase for namespaces is not 
mentioned in our coding style) to the other, but I think it will complicate 
things even further.

Kind Regards

Giacomo

> -Original Message-
> From: Jason Lowe-Power via gem5-dev 
> Sent: 03 May 2021 21:27
> To: gem5 Developer List 
> Cc: Jason Lowe-Power 
> Subject: [gem5-dev] Re: gem5 namespace
>
> Hey Daniel,
>
> Sorry, I didn't mean to add to the confusion :). I may have gotten my case
> names confused! Also, I really appreciate the thoughtfulness and effort
> you're putting into this conversation! I believe I agree with your email 
> below.
>
>
> I think that most people don't care that much (which is why we haven't heard
> from many). From my experience, our users only care when they get merge
> conflicts :D. That said, I'm not sure if "straightforward" is a way most of 
> our
> users ever feel about merge conflicts. IMO, stability and ease of update
> should be high priority. If we are going to be changing names, etc. in a way
> that means external users of gem5 will have compiler errors, we should
> probably provide backwards compatibility and warnings. Most of our users
> are not software engineers and do not have as much experience with git,
> compilers, etc. as we do.
>
>
> Cheers,
> Jason
>
>
> On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev  d...@gem5.org  > wrote:
>
>
>   I'm confused, Jason. I thought you were in favor of adopting snake
> case as a "general convention" (i.e., "the google way"), so by adopting snake
> case we would be adopting the "general convention", not forging our own
> path. However, if by "general convention" you mean "the convention vastly
> adopted by gem5", I don't have the exact numbers, but I'd guess it is 70%
> pascal, 30% snake case - i.e., IMHO, not a "general convention", just a
> preference. Adding "gem5" or "Gem5" would only extend this mess, not add
> an exception.
>
>   Regarding changing the name of the variable, indeed, it is not a
> necessary step.
>
>   Again, as stated before, I don't care which solution is taken. The
> important thing is to come to a decision that appeases most community
> members; however, it is hard to reach a consensus when we seem to have
> strong opinions on both sides, yet we only have 5 votes. That is why I have
> suggested officially adopting snake case namespaces: it would solve the
> "gem5 VS Gem5" problem, it is feasible to do it without having exceptions (at
> least as of now), Giacomo expressed preference towards lowercase
> namespaces, Jason suggested affinity with the google approach (snake case)
> and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns.
> The (huge) downside to this solution is that it would affect users, but 1) 
> we'd
> already be affecting users anyway with the new namespace, and 2) solving
> the merge conflicts would be straightforward if the patches were created
> with that in mind.
>
>
>   Regards,
>   Daniel
>
>   Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-
> Power mailto:ja...@lowepower.com> >
> escreveu:
>
>
>   Just a few quick replies below. Overall, I think we're being too
> focused on "standards" and not on enough on ease of use. It's not a problem
> if there are exceptions to guidance, if there's good reasons for the
> exceptions.
>
>
>   On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev
> mailto:gem5-dev@gem5.org> > wrote:
>
>
>   As mentioned by Gabe in the Jira issue, some of the
> namespaces using snake declared in the codebase case are defined as parts
> of a standard, and thus cannot be modified. Realistically, this means that if
> we wanted to follow a namespace naming convention, it'd be snake case:
> despite having way more occurrences of pascal case namespaces, they are all
> "ours"; this means that, although inconvenient, it would be doable to
> standardize all of them.
>
>
>
>   If we just say "all namespaces should be PascalCase. gem5, the name
> of this project, is an exception" would be OK with me.
>
>
>
>   Would you be willing to adopt to enforce a snake case
> namespace naming convention? From the previous replies to this thread, it
> seems that this solution would appease most - if not all - participants.
>
>
>   I really don't think this is too important. I would definitely prefer to
> follow the *general* conventions rather than forging our own path.
>
>
>
>
>   For this change to take place, we need to (not necessarily
> sorted):
>   1) Rename the python variables named "gem5" in
> src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember
> finding where they are used);
>
>
>   Why does this 

[gem5-dev] Re: error from new test_convert.py?

[Giacomo Travaglini via gem5-dev]

Yes,

This is why I usually run using tests/gem5 as root directory

./tests/main.py [...] \
tests/gem5 <- root directory

Testlib is basically trying to load every python file it finds on its walk.
We should definitely add python unit tests to our presubmit runs IMHO. The 
simplest way is via unittest Test Discovery [1]

Kind Regards

Giacomo

[1]: https://docs.python.org/3/library/unittest.html#unittest-test-discovery

> -Original Message-
> From: Bobby Bruce via gem5-dev 
> Sent: 19 April 2021 13:43
> To: gem5 Developer List 
> Cc: Gabe Black ; Bobby Bruce
> 
> Subject: [gem5-dev] Re: error from new test_convert.py?
>
> The exception being thrown is "No module named 'm5'".  m5 is not in the
> path, but could easily be added.
>
> From looking at https://gem5-
> review.googlesource.com/c/public/gem5/+/39377, this was never intended
> to be run via `main.py`, though "test_convert.py" has the "test" prefix so our
> TestLib framework tries to run it anyway.
>
> My questions are: when were these tests meant to be run? Should they be
> incorporated into the TestLib (i.e. those tests run via `main.py`) to be run 
> as a
> Presubmit, Nightly, or Weekly test? This would be easy to do (I think I could
> incorporate this relatively quickly).
>
> Kind regards,
> Bobby
>
> --
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
> web: https://www.bobbybruce.net
>
>
>
> On Sun, Apr 18, 2021 at 9:35 PM Gabe Black via gem5-dev  d...@gem5.org  > wrote:
>
>
> Hi gem5 devs, specifically Andreas. I was just running the regressions
> on a change I'm working on, and I noticed this message:
>
> Exception thrown while loading
> "/home/gblack/gem5/work/tests/pyunit/util/test_convert.py"
> Ignoring all tests in this file.
>
> FYI, it looks like these tests are not runnng...
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 namespace

[Giacomo Travaglini via gem5-dev]

My vote goes to 1 and A as well

My sole argument is consistency; in general I'd rather start a namespace with a 
lowercase. So that when we have something
like a scope resolution we know we are dealing with a namespace and not a 
class. But that's off-topic.

Namespace names are anyway not covered by our coding style, so it's probably 
worth adding an entry.

https://www.gem5.org/documentation/general_docs/development/coding_style/

From a quick grep I can see most of our namespaces follow the PascalCase type, 
though there are some namespaces using snake_case convention.

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 15 April 2021 09:03
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: gem5 namespace
>
> My vote is for 1 and A.
>
> We have style rules for a reason, and that is because not following them
> causes technical problems like name collisions, and makes it less obvious
> when reading code what things are and what they're doing. It's a bit
> hypocritical to say that we should follow style rules and completely ignore
> the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
> rule should win when dealing with the namespace.
>
> This is further inconsistent with the Gem5Internal namespace, the Gem5
> class in SCons, the Gem5Op instruction format used for ARM, and the
> Gem5Imm constant used for ARM semihosting. It would also cause a collision
> with any variable called gem5, a completely legal and reasonable name to use,
> *especially* in code outside of gem5 which might be using it to refer to
> something related to gem5 which it is interacting with.
>
> There are no other instances where we let superficial aesthetic conventions
> like this overrule technical considerations. We don't add _tm to the end of
> trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
> since that's not a valid class name, and a hundred other examples of where
> prose takes a back seat because this is not prose, this is a conceptual 
> machine
> people happen to be able to read.
>
> Our website is the place for branding and identity and marketing, our code is
> not.
>
> Gabe
>
> On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev  d...@gem5.org  > wrote:
>
>
> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing we need to do is to standardize and document when
> and where you need to use the gem5 namespace. For instance, do we need
> to update *all* headers to be in the gem5 namespace? If not, when is an
> object in the gem5 namespace and when it is not? What about `using
> namespace gem5`? Can/must all .cc files include this?
>
> Since this is a relatively big change to the coding standards which
> could cause significant frustration to our users, we should be sure to
> document and standardize *before* we make any code changes.
>
> Cheers,
> Jason
>
>
> On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev
> mailto:gem5-dev@gem5.org> > wrote:
>
>
> Hello, devs,
>
>
>
> We currently have a recurring issue, which is the lack of a
> gem5 namespace.
> This generates collision with other libraries and user code.
>
>
>
> A Jira ticket has been created to point out the issue last year:
>
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G
> EM5-730
>
>
> And this topic has been brought up a few times:
>
>
> https://www.mail-archive.com/gem5-
> d...@gem5.org/msg37770.html
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/40878
>
> https://www.mail-archive.com/gem5-
> d...@gem5.org/msg36453.html
>
>
> Finally, there were already patches that were consequences
> of lack of a gem5
> namespace:
>
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/32175
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/40878
>
>
> A similar issue exists for macros, and an existing proposal to
> solve it already
> exists, which is to add a "GEM5_" prefix. It follows the coding
> style, which
> dictates that "preprocessor symbols (constants and macros)
> should be all
> caps with underscores":
>
>
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G
> EM5-912
>
>
> It does not seem to be controversial to add this namespace;
> however, there is
> still one blocker to greenlight its creation: what will be its
> name. There are
> no explicit rules regarding namespace naming; however, they
> are typically
> declared starting with an uppercase letter followed by
> lowercase letters. So,
> theoretically, gem5's namespace should be "Gem5". This,
> however, conflicts
> with gem5's identity: "“gem5” should always have a
> lowercase “g”"
> (see http://www.gem5.org/getting_started/).
>
>
>
> We should decide as a community what is the best approach
> to take, so I'll
> list the options and will request you to cast your votes. If you
> would like
> to add remarks to the discussion, feel free to 

[gem5-dev] Re: More unreproducible kokoro failures... testlib bug?

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

Apologies for the late reply; I was on vacation.
That is not a "problem" in testlib. It happens when regressions are aborted by 
external forces (e.g. a timeout in Jenkins/kokoro); then the time field
of metadata doesn't get populated.

We should probably fix this by initializing time to zero, letting other logic 
to signal the failure

Kind Regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 29 March 2021 05:40
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] More unreproducible kokoro failures... testlib bug?
>
> Hi folks. I have another change which is failing kokoro unreproducibly, this
> time it seems because of a failure in the test library. I've looked at the 
> code in
> question and have some weak theories, but nothing which really helps
> identify the problem or a fix. This is especially hard since the failure 
> doesn't
> reproduce locally.
>
> https://source.cloud.google.com/results/invocations/7a3203b0-f429-48f8-
> b49e-0abf9413cc3c/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log
>
>
> Traceback (most recent call last):
>   File "./main.py", line 25, in 
> sys.exit(testlib())
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/main.py", line
> 331, in main
> result = globals()['do_'+configuration.config.command]()
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/main.py", line
> 303, in do_run
> return run_schedule(test_schedule, log_handler)
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/main.py", line
> 277, in run_schedule
> log_handler.finish_testing()
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/main.py", line
> 68, in finish_testing
> self.result_handler.close()
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/handlers.py",
> line 164, in close
> self._save()
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/handlers.py",
> line 156, in _save
> result.JUnitSavedResults.save(
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/result.py", line
> 330, in save
> results = JUnitTestSuites(results)
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/result.py", line
> 238, in __init__
> self.elements.append(JUnitTestSuite(suite))
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/result.py", line
> 264, in __init__
> self.elements.append(JUnitTestCase(test))
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/result.py", line
> 277, in __init__
> XMLAttribute('time', str(test_result.time["user_time"])),
>   File "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/result.py", line
> 77, in time
> return self._metadata.time
> AttributeError: 'TestCaseMetadata' object has no attribute 'time'

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5：stopping fetching and kernel panic

[Giacomo Travaglini via gem5-dev]

I see,

The VExpress_EMM(64) is an old platform and we are slowly removing its support.
It might be the problem is the prebuilt kernel not fully supporting the PCI IDE 
controller, but this is just speculation.

May I suggest you to use a more up to date platform (VExpress_GEM5_V1 or 
VExpress_GEM5_Foundation) ?
(Unless you are really willing to use VExpress_EMM(64))

This comes with using updated guest binaries as well.

You will be able to find prebuilt kernel and disk images at the following page:

http://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries

Let me know if this solves your problem,

Kind Regards

Giacomo

> -Original Message-
> From: Csq via gem5-dev 
> Sent: 26 March 2021 02:53
> To: gem5-dev@gem5.org
> Cc: 3152506...@qq.com
> Subject: [gem5-dev] Re: gem5：stopping fetching and kernel panic
>
> It is a great honor to receive your reply, and I have added some new
> information below.
>
> 
>   m5out/system.workload.dmesg
> 
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd070]
> [0.00] Linux version 4.19.36-vhulk1905.1.0.h276.eulerosv2r8.aarch64
> (root@SZV1000357782) (gcc version 7.3.0 (SDK V200R003C00B515)) #5 SMP
> PREEMPT Wed Jul 29 20:51:14 CST 2020 [0.00] Memory limited to 512MB
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
> [0.00] parse cmdline param err, kbox reserve memory max size =
> 0x800, cur size = 0x0 [0.00] cma: Reserved 16 MiB at
> 0x9f00 [0.00] memory reserve information:
> [0.00]   reserved type: 7
> [0.00]   enable   : no
> [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a
> node at [mem 0x-0x9fff]
> [0.00] NUMA: NODE_DATA [mem 0x9eff0dc0-0x9eff257f] [0.00]
> Zone ranges:
> [0.00]   DMA32[mem 0x8000-0x9fff]
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node [0.00] Early memory node
> ranges
> [0.00]   node   0: [mem 0x8000-0x9fff]
> [0.00] Initmem setup node 0 [mem 0x8000-
> 0x9fff]
> [0.00] On node 0 totalpages: 131072
> [0.00]   DMA32 zone: 2048 pages used for memmap
> [0.00]   DMA32 zone: 0 pages reserved
> [0.00]   DMA32 zone: 131072 pages, LIFO batch:31
> [0.00] random: get_random_bytes called from start_kernel+0xac/0x44c
> with crng_init=0 [0.00] percpu: Embedded 23 pages/cpu
> @(ptrval) s54232 r8192 d31784 u94208 [0.00] pcpu-alloc:
> s54232 r8192 d31784 u94208 alloc=23*4096 [0.00] pcpu-alloc: [0] 0 [0] 1
> [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: enabling
> workaround for ARM erratum 832075 [0.00] CPU features: enabling
> workaround for Mismatched cache type [0.00] CPU features: enabling
> workaround for EL2 vector hardening [0.00] CPU features: detected:
> Kernel page table isolation (KPTI) [0.00] Built 1 zonelists, mobility
> grouping on.  Total pages: 129024 [0.00] Policy zone: DMA32 [0.00]
> Kernel command line: earlyprintk=pl011,0x1c09 console=ttyAMA0
> lpj=19988480 norandmaps rw loglevel=8 mem=512MB root=/dev/sda1
> [0.00] Memory: 479980K/524288K available (7420K kernel code, 550K
> rwdata, 2328K rodata, 576K init, 252K bss, 27924K reserved, 16384K cma-
> reserved) [0.00] E820: [mem 0x8000-0x9fff]
> usable [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2,
> Nodes=1 [0.00] rcu: Preemptible hierarchical RCU implementation.
> [0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2.
> [0.00] Tasks RCU enabled.
> [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [0.77]
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
> [0.000880] arch_timer: cp15 timer(s) running at 25.16MHz (virt).
> [0.000953] clocksource: arch_sys_counter: mask: 0xff max_cycles:
> 0x5cdd39714, max_idle_ns: 440795202620 ns [0.001019] sched_clock: 56 bits
> at 25MHz, resolution 39ns, wraps every 4398046511084ns [0.001756] Console:
> colour dummy device 80x25 [0.002213] Calibrating delay loop (skipped)
> preset value.. 9994.24 BogoMIPS (lpj=19988480) [0.002326] pid_max: default:
> 32768 minimum: 301 [0.003965] Dentry cache hash table entries: 65536 (order:
> 7, 524288 bytes) [0.004687] Inode-cache hash table entries: 32768 (order: 6,
> 262144 bytes) [0.004931] Mount-cache hash table entries: 1024 (order: 1,
> 8192 bytes) [0.005032] Mountpoint-cache hash table entries: 1024 (order: 1,
> 8192 bytes) [0.242428] ASID allocator initialised with 128 entries [0.322625]
> rcu: Hierarchical SRCU implementation.
> [0.403712] EFI services will not be available.
> [0.483435] smp: Bringing up secondary CPUs ...
> [10.894791] CPU1: failed to come online
> 

[gem5-dev] Re: Build failed in Jenkins: Weekly #14

[Giacomo Travaglini via gem5-dev]

Thanks Jason, this will be fixed by:

https://gem5-review.googlesource.com/c/public/gem5/+/43746

Kind Regards

Giacomo

> -Original Message-
> From: Jason Lowe-Power 
> Sent: 26 March 2021 15:51
> To: gem5 Developer List 
> Cc: Giacomo Travaglini 
> Subject: Re: [gem5-dev] Build failed in Jenkins: Weekly #14
>
> I think https://gem5-review.googlesource.com/c/public/gem5/+/43287
> change caused the breakage. Should be a simple fix to the GPU scripts.
>
> Cheers,
> Jason
>
>
> On Fri, Mar 26, 2021 at 3:17 AM jenkins-no-reply--- via gem5-dev  d...@gem5.org  > wrote:
>
>
> See
> 
>
> Changes:
>
> [Bobby R. Bruce] scons: Fixing build errors with scons 4.0.1 and 4.1.0
>
> [Bobby R. Bruce] misc: Updated the RELEASE-NOTES and version
> number
>
> [petery.hin] arch-riscv: Fixing RISC-V remote GDB MIP and MIE
> accesses.
>
> [Bobby R. Bruce] base-stats,python: Add missing "group" in
> `_prepare_stats`
>
> [gabe.black] systemc: Stop using std::gets in systemc.h.
>
> [gabe.black] scons,tlm: Update the gem5-within-systemc SConstruct
> to use c++14.
>
> [gabe.black] systemc,util: Update sc_master_port.cc now that
> params() returns a ref.
>
> [gabe.black] systemc,util: Fix a bad port of a change from gem5
> proper to here.
>
> [gabe.black] scons,util: Make the tlm SConstruct put SConsign in the
> build dir.
>
> [gabe.black] sim,systemc: Use slightly non-standard constructors for
> custom create()
>
> [gabe.black] cpu: Delete unnecessary create() methods.
>
> [gabe.black] scons,python: Always generate default create()
> methods.
>
> [Andrea.Mondelli] arch-riscv: Fixed CPU switching and PLIC issue with
> MinorCPU
>
> [Giacomo Travaglini] configs: Remove icache from HTMSequencer
>
> [Giacomo Travaglini] dev-arm: Fix SMMUv3BaseCache Stats
>
> [Giacomo Travaglini] dev-arm: Fix WalkCache stats
>
> [Giacomo Travaglini] dev-arm: Remove unused SMMUv3 WalkCache
> variables
>
> [Giacomo Travaglini] configs: Use integer division in
> MESI_Three_Level_HTM.py
>
> [tiago.muck] scons,mem-ruby: export need_partial_func_reads in
> SConstruct
>
> [tiago.muck] configs,mem-ruby: CHI-based Ruby protocol
>
> [odanrc] base-stats: Fix Watt Unit
>
> [Bobby R. Bruce] python: Fix incorrect prefixes is m5.utils.convert
>
> [Bobby R. Bruce] arch-arm: Fix atomics permission checks in TLB
>
> [Bobby R. Bruce] configs: Use integer division in
> MESI_Three_Level_HTM.py
>
> [Bobby R. Bruce] misc: Updated the RELEASE-NOTES and version
> number
>
> [Giacomo Travaglini] configs, mem: MemInterface generating its own
> controller
>
> [odanrc] misc: Fix coding style for class-opening braces
>
> [odanrc] util: Add verifier for opening braces of classes
>
> [odanrc] misc: Fix coding style for struct's opening braces
>
> [Giacomo Travaglini] configs: Remove simpleSystem factory function
>
> [odanrc] util: Add verifier for opening braces of structs
>
> [gabe.black] mem: Fix style in addr_mapper.hh.
>
> [gabe.black] arch,cpu: Collapse away TheISA::advancePC.
>
> [gabe.black] arch,cpu: Move TheISA::copyRegs to
> TheISA::ISA::copyRegsFrom.
>
> [gabe.black] arch,cpu,kern,sim: Eliminate the utility.hh switching
> header.
>
> [odanrc] misc: Fix coding style for enum's opening braces
>
> [odanrc] util: Add verifier for opening braces of enums
>
> [odanrc] misc: Fix coding style for union's opening braces
>
> [odanrc] base-stats: Add unit test for Stats::Units
>
> [odanrc] base-stats: Make Rate's compilation smarter
>
> [odanrc] util: Add verifier for opening braces of unions
>
> [daecheol.you] mem-garnet: Added packet distribution stats
>
> [gabe.black] arch-arm: Consolidate register related files into a
> directory.
>
> [gabe.black] arch: Eliminate the GuestByteOrder constant.
>
> [Giacomo Travaglini] configs: Add a BaseSimpleSystem
>
> [Giacomo Travaglini] configs, tests: Ruby.create_system cpus option
>
> [Giacomo Travaglini] configs: RubySimpleSystem and simple
> ruby_fs.py script
>
> [mattdsinclair] dev-hsa: Fix size of HSA Queue
>
> [yazakram] arch-riscv,util: fix the default cross compiler for riscv
>
> [mattdsinclair] gpu-compute: Support dynamic scratch allocations
>
> [mattdsinclair] gpu-compute: Remove unused functions
>
> [odanrc] dev-hsa: Fix includes
>
>
> --
> [...truncated 943.76 KB...]
>  [SHCC] softfloat/f64_mulAdd.c -> .os
>  [SHCC] softfloat/f64_mul.c -> .os
>  [SHCC] softfloat/f64_rem.c -> .os
>  [SHCC] softfloat/f64_roundToInt.c -> .os
>  [SHCC] softfloat/f64_sqrt.c -> .os
>  [SHCC] softfloat/f64_sub.c -> .os
>  [SHCC] softfloat/f64_to_f128.c -> .os
>  [SHCC] softfloat/f64_to_f16.c -> .os
>  [SHCC] softfloat/f64_to_f32.c -> .os
>  [SHCC] softfloat/f64_to_i32.c -> .os
>  [SHCC] softfloat/f64_to_i32_r_minMag.c -> .os
>  [SHCC] softfloat/f64_to_i64.c -> .os
>  [SHCC] softfloat/f64_to_i64_r_minMag.c -> .os
>  [SHCC] softfloat/f64_to_ui32.c -> .os
>  [

[gem5-dev] Re: gem5：stopping fetching and kernel panic

[Giacomo Travaglini via gem5-dev]

Hi,

The stdout is not enough I am afraid to understand what went wrong.
Could you provide the content of the m5out/system.workload.dmesg file ?

Kind Regards

Giacomo

> -Original Message-
> From: Csq via gem5-dev 
> Sent: 25 March 2021 03:40
> To: gem5-dev@gem5.org
> Cc: 3152506...@qq.com
> Subject: [gem5-dev] gem5：stopping fetching and kernel panic
>
> 
>   The contents of the dts file are as follows：
> 
> /dts-v1/;
>
> /memreserve/ 0x8000 0x0001;
>
> /include/ CONF_PLATFORM
>
> /* Assign a unique ID for pre-defined configurations. The selected
>  * configuration is picked up from CONF_CPUS */ // 2 big and 2 little cpus
> #define _2_2 1 // 2 big and 4 little cpus #define _2_4 2
>
> #define CPU(n,id) \
> CPU ## n: cpu@ ## id { \
> device_type = "cpu"; \
> compatible = "gem5,armv8", "arm,armv8"; \
> reg = < ## id >; \
> enable-method = "spin-table"; \
> cpu-release-addr = <0 0x8000fff8>; \
> };
>
>
> / {
> model = "V2P-AARCH64";
> compatible = "arm,vexpress,v2p-aarch64", "arm,vexpress";
>
> memory@8000 {
> device_type = "memory";
> reg = <0 0x8000 0x4 0x>;
> };
>
>
>
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> #if CONF_CPUS == _2_2
> CPU(0,0x0)
> CPU(1,0x1)
> CPU(2,0x102)
> CPU(3,0x103)
> cpu-map {
> cluster0 {
> core0 { cpu = <>; };
> core1 { cpu = <>; };
> };
> cluster1 {
> core0 { cpu = <>; };
> core1 { cpu = <>; };
> };
> };
> #elif CONF_CPUS == _2_4
> CPU(0,0x0)
> CPU(1,0x1)
> CPU(2,0x102)
> CPU(3,0x103)
> CPU(4,0x104)
> CPU(5,0x105)
> cpu-map {
> cluster0 {
> core0 { cpu = <>; };
> core1 { cpu = <>; };
> };
> cluster1 {
> core0 { cpu = <>; };
> core1 { cpu = <>; };
> core2 { cpu = <>; };
> core3 { cpu = <>; };
> };
> };
> #else
> #error Missing configuration section
> #endif
> };
>
> virt-encoder {
> compatible = "drm,virtual-encoder";
> port {
> dp0_virt_input: endpoint@0 {
> remote-endpoint = <_output>;
> };
> };
>
> display-timings {
> native-mode = <>;
>
> timing0: timing_1080p60 {
> /* 1920x1080-60 */
> clock-frequency = <14850>;
> hactive = <1920>;
> vactive = <1080>;
> hfront-porch = <148>;
> hback-porch = <88>;
> hsync-len = <44>;
> vfront-porch = <36>;
> vback-porch = <4>;
> vsync-len = <5>;
> };
> };
> };
> };
>
>  {
> status = "ok";
>
> port {
> dp0_output: endpoint@0 {
> remote-endpoint = <_virt_input>;
> };
> };
> };
>
> 
>The problem is as follows：
> 
> warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
> info: Entering event queue @ 0. Starting simulation. . .
> warn: SCReg: Access to unknown device dcc0:site0 :pos0: fn7 :dev0
> warn :instruction' csdb unimplemented
> warn: GIC APRn write ignored because not imp Lemented: 0xd0
> warn: GIC APRn write ignored because not implemented: 0xd4
> warn: GIC APRn write ignored because not imp Lemented: 0xd8
> warn: GIC APRn write ignored because not imp Lemented: 0xdc
> warn: Address 0xf f8008091cc0 is outside of physical memory, stopping
> fetch
> warn: Address 0xff8008091cc0 is outside of phys ical memory, stopping
> fetch
> warn: Address 0xff8008091cc0 is outside of physical memory, stopping
> fetch
> warn: Address 0xff8008091cc0 is outside of physical memory, stopping
> fetch
> warn: Address oxf f8008091cc0 is outside of physical memory, stopping
> fetch
> warn: Tried to read RealView I/0 at offset 0x60 that doesn't exist
> warn: Tried to read RealView I/0 at offset 0x48 that doesn't exist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't exist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 ( data 0) that doesn't exist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't exist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't ex ist
> warn: Tried to write RVIO at offset 0xa8 (data 0) that doesn't exist
> warn: Tried to read RealView I/0 at offset 0x8 that doesn't exist
> warn: Tried to read RealView I/0 at offset 0x48 that doesn't exist
> info: Dumping kernel dmesg buffer to sys tem. workload. dmesg. . .
> warn: Kernel panic in s imulated kernel
>
> 
>  I look forward to hearing your answers
> 
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email
> to gem5-dev-
> le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of 

[gem5-dev] Re: de-templating the O3 CPU

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

That's probably because making a release has caught everyone's attention.
I am definitely gonna have a look at it in about a week time, I promise 

Kind Regards

Giacomo


> -Original Message-
> From: Gabe Black 
> Sent: 22 March 2021 03:20
> To: Jason Lowe-Power 
> Cc: gem5 Developer List ; Giacomo Travaglini
> 
> Subject: Re: [gem5-dev] Re: de-templating the O3 CPU
>
> People seemed pretty enthusiastic for this series of CLs, but I haven't been
> able to get reviews for it...
>
> https://gem5-review.googlesource.com/c/public/gem5/+/42094
>
>
> On Wed, Mar 3, 2021 at 9:15 AM Gabe Black  <mailto:gabe.bl...@gmail.com> > wrote:
>
>
> Series of 28 CLs, ends here:
>
>
>
> https://gem5-review.googlesource.com/c/public/gem5/+/42120
>
>
> On Mon, Mar 1, 2021 at 8:50 AM Jason Lowe-Power
> mailto:ja...@lowepower.com> > wrote:
>
>
> Hey Gabe,
>
> I love this idea! It would be nice if you could document the
> code as you go, too. It could serve as a good learning tool in the future.
>
> Cheers,
> Jason
>
>
> On Mon, Mar 1, 2021 at 7:56 AM Giacomo Travaglini via gem5-
> dev mailto:gem5-dev@gem5.org> > wrote:
>
>
> +2, +1, Merged
>
> 
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev  d...@gem5.org <mailto:gem5-dev@gem5.org> >
> > Sent: 27 February 2021 10:13
> > To: gem5 Developer List  <mailto:gem5-dev@gem5.org> >
> > Cc: Gabe Black  <mailto:gabe.bl...@gmail.com> >
> > Subject: [gem5-dev] de-templating the O3 CPU
> >
> > Hi folks. The O3 CPU uses templates pretty heavily,
> I think nominally to make it
> > possible to switch in different parts of the CPU to
> change how, for example, a
> > pipeline stage is implemented.
> >
> > Realistically, the different parts of the CPU are
> probably too interdependent
> > for that to actually work, and all the templates and
> indirection make the code a
> > lot more complicated than it really needs to be.
> >
> > Also, there is a pseudo-generic dynamic instruction
> base class in
> > cpu/base_dyn_inst.hh which could, again
> theoretically, be used as a base class
> > for other CPUs to reuse. Unfortunately that too is
> probably too tied to its only
> > consumer, the O3 CPU, to be realistically reusable.
> >
> > I would like to merge the base dynamic instruction
> class into the O3 version,
> > and then de-templatize the whole O3 CPU. I think
> that will make the code a lot
> > easier to work on, and I think our ability to maintain
> and update O3 is
> > something we need to improve in at least the
> medium term.
> >
> > Any thoughts? Objections? Votes of support?
> >
> > Gabe
> IMPORTANT NOTICE: The contents of this email and
> any attachments are confidential and may also be privileged. If you are not
> the intended recipient, please notify the sender immediately and do not
> disclose the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> <mailto:gem5-dev@gem5.org>
> To unsubscribe send an email to gem5-dev-
> le...@gem5.org <mailto:gem5-dev-le...@gem5.org>
>
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #242

[Giacomo Travaglini via gem5-dev]

This is fixed by:

https://gem5-review.googlesource.com/c/public/gem5/+/42623

> -Original Message-
> From: jenkins-no-reply=gem5@mg.gem5.org  reply=gem5@mg.gem5.org> On Behalf Of jenkins-no-reply--- via gem5-dev
> Sent: 09 March 2021 08:31
> To: gem5-dev@gem5.org
> Cc: jenkins-no-re...@gem5.org
> Subject: [gem5-dev] Build failed in Jenkins: Nightly #242
>
> See 
>
> Changes:
>
> [Giacomo Travaglini] base: Add log2i to calculate log2 for integers
>
> [gabe.black] mem: Fix some transitive includes.
>
> [gabe.black] base: Add a szext function for true sign extension.
>
> [gabe.black] base: Remove "inline" from bitfield.hh.
>
>
> --
> [...truncated 378.41 KB...]
>
>   YOU HAVE 1 DISABLED TEST
>
> build/NULL/base/temperature.test.fast --
> gtest_output=xml:build/NULL/unittests.fast/base/temperature.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 6 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 6 tests from TemperatureTest
> [ RUN  ] TemperatureTest.Constructor
> [   OK ] TemperatureTest.Constructor (0 ms)
> [ RUN  ] TemperatureTest.Conversion
> [   OK ] TemperatureTest.Conversion (0 ms)
> [ RUN  ] TemperatureTest.Comparison
> [   OK ] TemperatureTest.Comparison (0 ms)
> [ RUN  ] TemperatureTest.BinaryOperators
> [   OK ] TemperatureTest.BinaryOperators (0 ms)
> [ RUN  ] TemperatureTest.AssignmentOperators
> [   OK ] TemperatureTest.AssignmentOperators (0 ms)
> [ RUN  ] TemperatureTest.OutStream
> build/NULL/base/trie.test.fast --
> gtest_output=xml:build/NULL/unittests.fast/base/trie.test.xml
> [   OK ] TemperatureTest.OutStream (0 ms)
> [--] 6 tests from TemperatureTest (1 ms total)
>
> [--] Global test environment tear-down [==] 6 tests from 1 
> test
> suite ran. (1 ms total) [  PASSED  ] 6 tests.
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 7 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 7 tests from TrieTestData
> [ RUN  ] TrieTestData.Empty
> [   OK ] TrieTestData.Empty (0 ms)
> [ RUN  ] TrieTestData.SingleEntry
> [   OK ] TrieTestData.SingleEntry (0 ms)
> [ RUN  ] TrieTestData.TwoOverlappingEntries
> [   OK ] TrieTestData.TwoOverlappingEntries (0 ms)
> [ RUN  ] TrieTestData.TwoOverlappingEntriesReversed
> [   OK ] TrieTestData.TwoOverlappingEntriesReversed (0 ms)
> [ RUN  ] TrieTestData.TwoIndependentEntries
> [   OK ] TrieTestData.TwoIndependentEntries (0 ms)
> [ RUN  ] TrieTestData.TwoEntries
> [   OK ] TrieTestData.TwoEntries (0 ms)
> [ RUN  ] TrieTestData.RemovingEntries
> [   OK ] TrieTestData.RemovingEntries (0 ms)
> [--] 7 tests from TrieTestData (1 ms total)
>
> [--] Global test environment tear-down [==] 7 tests from 1 
> test
> suite ran. (1 ms total) [  PASSED  ] 7 tests.
> build/NULL/base/types.test.fast --
> gtest_output=xml:build/NULL/unittests.fast/base/types.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 19 tests from 3 test suites.
> [--] Global test environment set-up.
> [--] 10 tests from CyclesTest
> [ RUN  ] CyclesTest.NoCycles
> [   OK ] CyclesTest.NoCycles (1 ms)
> [ RUN  ] CyclesTest.PrefixIncrement
> [   OK ] CyclesTest.PrefixIncrement (0 ms)
> [ RUN  ] CyclesTest.PrefixDecrement
> [   OK ] CyclesTest.PrefixDecrement (0 ms)
> [ RUN  ] CyclesTest.InPlaceAddition
> [   OK ] CyclesTest.InPlaceAddition (0 ms)
> [ RUN  ] CyclesTest.GreaterThanLessThan
> [   OK ] CyclesTest.GreaterThanLessThan (0 ms)
> [ RUN  ] CyclesTest.AddCycles
> [   OK ] CyclesTest.AddCycles (0 ms)
> [ RUN  ] CyclesTest.SubtractCycles
> [   OK ] CyclesTest.SubtractCycles (0 ms)
> [ RUN  ] CyclesTest.ShiftRight
> [   OK ] CyclesTest.ShiftRight (0 ms)
> [ RUN  ] CyclesTest.ShiftLeft
> [   OK ] CyclesTest.ShiftLeft (0 ms)
> [ RUN  ] CyclesTest.OutStream
> [   OK ] CyclesTest.OutStream (0 ms)
> [--] 10 tests from CyclesTest (1 ms total)
>
> [--] 5 tests from MicroPCTest
> [ RUN  ] MicroPCTest.CheckMicroPCRomBit
> [   OK ] MicroPCTest.CheckMicroPCRomBit (0 ms)
> [ RUN  ] MicroPCTest.RomMicroPCTest
> [   OK ] MicroPCTest.RomMicroPCTest (0 ms)
> [ RUN  ] MicroPCTest.NormalMicroPCTest
> [   OK ] MicroPCTest.NormalMicroPCTest (0 ms)
> [ RUN  ] MicroPCTest.IsRomMicroPCTest
> [   OK ] MicroPCTest.IsRomMicroPCTest (0 ms)
> [ RUN  ] MicroPCTest.IsNotRomMicroPCTest
> [   OK ] MicroPCTest.IsNotRomMicroPCTest (0 ms)
> [--] 5 tests from MicroPCTest (0 ms total)
>
> [--] 4 tests from TypesTest
> [ RUN  ] TypesTest.FloatToBits32
> [   OK ] 

[gem5-dev] RFC: Support for multiple non consecutive ranges in the AbstractMemory class

[Giacomo Travaglini via gem5-dev]

Hi devs,

In the past days I have been thinking about providing support for multiple non 
consecutive ranges to the memory object (AbstractMemory).
I already have a working implementation; I just need to come up with a good 
python interface for it.

I have opened a JIRA ticket [1] with my proposal; feel free to add some 
comments to it or propose better alternatives

Kind Regards

Giacomo

[1]: https://gem5.atlassian.net/browse/GEM5-926
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: RFC: run python Black on gem5 python code

[Giacomo Travaglini via gem5-dev]

> -Original Message-
> From: Jason Lowe-Power 
> Sent: 04 March 2021 15:27
> To: gem5 Developer List 
> Cc: Gabe Black ; Giacomo Travaglini
> 
> Subject: Re: [gem5-dev] Re: RFC: run python Black on gem5 python code
>
> Hi all,
>
>
> Some responses inline below. The other thing I'll mention is that I believe we
> can integrate it in a way where it's completely invisible to most developers.
> You can edit a file with whatever style you want, then after you run black it 
> will
> be in the PEP8 style. From my experience, the only things that need to be
> manually changed are quoted strings that are more than 80 characters.
>

I would be very careful about hiding this to the developers at the point of 
automatically changing their code
without having them noticing it.

I understand you want developers to commit without the hassle of explicitly 
dealing with style errors.
On the other hand though we are already doing this for C++ so I don't see a 
reason why we shouldn't do the same
for the python world.

Other options could be to run the linter as a pre-push hook, or to run the 
linter as part of our presubmit Jenkins script.

> On Thu, Mar 4, 2021 at 6:49 AM Giacomo Travaglini via gem5-dev  d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
>
>
> Hi Jason,
>
> This is great news. When you say it is not configurable, do you mean it
> is not possible to suppress warning/errors or do you
> mean it is not possible to come up with custom rules?
>
>
>
> There is a way to suppress changes by modifying the file with a comment `#
> fmt: off`. You can also exclude files with a dotfile (like .gitignore).
>
>
>
> As I presume it's the first case, I am wondering if a different linter
> might provide such capabilities:
>
> https://books.agiliq.com/projects/essential-python-
> tools/en/latest/linters.html
>
> Is there a reason to prefer black over other linters?
>
>
>
> It's owned by the python software foundation, which makes it seem "official".
> Though the real reason is that it's the first one I looked at and the only 
> one I
> investigated.

I actually thought pycodestyle was the "official" linter (I am not sure if the 
"official" word makes completely sense though)

I was asking this because for example in pycodestyle (and prob other linters as 
well) there are error codes 
https://pycodestyle.pycqa.org/en/latest/intro.html#error-codes you could use 
include or exclude lists of errors (to ignore specific types of warnings).

Kind regards

Giacomo

>
>
>
> Kind regards
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev  <mailto:gem5-dev@gem5.org> >
> > Sent: 04 March 2021 03:59
> > To: gem5 Developer List mailto:gem5-
> d...@gem5.org> >
> > Cc: Gabe Black  <mailto:gabe.bl...@gmail.com> >
> > Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code
> >
> > I'm a little worried about the no exceptions part of that, since we
> might have
> > some weird restrictions that we have to do weird things to work
> around, but I
> > can't really think of an example of that off hand. I'd want to look at it
> to see
> > how much wiggle room there is in the style, since I think ironclad
> rules which
> > make no accommodation for occasional common sense are maybe
> more
> > trouble than they're worth. I'm not opposed to having at least some
> stated
> > standard for python though, and the "official" one seems like a
> pretty
> > reasonable choice. I guess it's fine with me, up until it causes me
> some sort of
> > problem :-)
>
>
>
> I actually think it's a feature not a bug. With an "uncompromising Python code
> formatter" there can be no arguments in code review about the style.
>
>
> >
> > Maybe the right thing to do would be to give it a shot but not make
> it
> > compulsory until we have a feeling for how much trouble it is.
> >
> >
> > Gabe
> >
> > On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev  > d...@gem5.org <mailto:d...@gem5.org>  <mailto:gem5-
> d...@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> >
> >
> > Sounds like a good idea to me.
> > ---
> >
> > Dr. Bobby R. Bruce
> > Room 2235,
> > Kemper Hall, UC Davis
> > Davis,
> > CA, 95616
> >
> >
> > web: https://www.bobbybruce.net
> >
> >
> >
> > On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev
> > mailto:gem5-dev@gem5.org>
> <mailto:gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> >
> >

[gem5-dev] Re: vector register indexing modes and renaming?

[Giacomo Travaglini via gem5-dev]

> -Original Message-
> From: Gabe Black 
> Sent: 04 March 2021 04:04
> To: Giacomo Travaglini 
> Cc: gem5 Developer List 
> Subject: Re: [gem5-dev] vector register indexing modes and renaming?
>
>
>
> On Mon, Mar 1, 2021 at 6:48 AM Giacomo Travaglini
> mailto:giacomo.travagl...@arm.com> >
> wrote:
>
>
>
> > -Original Message-
> > From: Gabe Black   >
> > Sent: 27 February 2021 05:47
> > To: Giacomo Travaglini   >
> > Cc: gem5 Developer List mailto:gem5-
> d...@gem5.org> >
> > Subject: Re: [gem5-dev] vector register indexing modes and
> renaming?
> >
> > Another question/clarification:
> >
> > Does any data actually get shared between the two rename modes? I
> think you
> > said there is not, but now I can't find that.
>
> Data *do* get shared, even if in gem5 we have separate physical
> registers.
> In fact, when rename mode changes [1], (meta)data is copied from one
> register file to the other.
> For example, say we have an AArch64 kernel running at EL1 and my
> AArch32 (basically armv7) floating point application running at EL0.
>
> My application will be using vector elements; however, every time
> there is an exception to AArch64, cpu will switch
> Rename mode and data will be copied / mapping will be adjusted. Any
> FP & SIMD operation at this point will use vector registers.
> When the kernel finishes its stuff, and goes back to AArch32, vector
> elements will be repopulated.
>
>
>
>
> Ok, I thought that was what you said, and I couldn't think of another reason 
> to
> go through all the trouble of copying things around.
>
>
>
>
> > Would it work just as well to have
> > two register files which operate entirely independently?
>
> As I mentioned before, they operate independently, but they sync up
> when we pass from one mode
> To the other. Another way to look at it is that they are mutually
> exclusive.
>
>
>
>
> Would it make sense to trigger the syncing between them explicitly from ARM
> code, rather than forcing the O3 to notice and do the copying? Then the
> copying, etc, wouldn't have to be generic, since it would be triggered by an
> ARM architectural mechanism.
>
>

I understand what you are saying, but just to be clear: I believe the copying 
per se is already ISA agnostic.
The O3 copying is really copying elements into vectors and viceversa; the O3 
model doesn't really
have any notion of the Arm architecture (but I do agree the *need* for copying 
is Arm oriented)

If your concern was more about the triggering mechanism, you can probably start 
everything from the Arm side, but I don't really know what’s the cleanest 
solution there. A quick and dirty implementation would extend the ExecContext 
interface as execution mode changes are often (but not always) triggered by 
instructions.
(SVC = syscall and ERET).
That is far from being a better solution; as you would add o3 specific logic to 
other cpus as well (probably empty stubs). You would also end up with o3 code 
in arch.

>
>
> > From what I can tell
> > the "V" registers of Neon in aarch64 overlap with the SVE registers,
> and the "Q"
> > registers of armv7 Neon overlap with the "S", "D", "Q" registers of
> the same,
> > but I think "V" and "Q" are independent? Maybe reused but not
> guaranteed to
> > alias?
> >
>
> I would say the rule of thumb for understanding AArch64-AArch32
> mapping (and it's the underlying cause of using different renaming modes) is 
> to
> bear in mind that AArch64, differently from AArch32, uses an unpacked
> approach for FP & SIMD registers.
> Prior to Armv8, smaller FP registers were packed into bigger registers
> [2]. Having for example 32 double precision registers (D0-D31) meant having a
> maximum of 16 quad word registers (Q0-Q15).
> This setup has been abandoned in Armv8 [3]. As an example, S1, or D1
> are not packed anymore in Q0. Those are in fact the 32/64 LSBits of Q1.
> This means the newly added (V16-V31) are not accessible in AArch32.
>
> So to answer your question regarding V and Q. Until Q/V15, they alias
> perfectly; V16-V31 are simply not
> Defined/accessible in AArch32 so they are not aliased.
>
> All AArch32 SIMD data is accessible from AArch64. It just won't stick to
> the same naming. AArch32 D1 and AArch64 D1 hold different data.
> If I really wanted to access AArch32 D1 from AArch64 I would have to
> read the 64 MSB of V0. This is a software and not an hardware problem (I just
> posted this example to stress the difference between aliasing and 
> reachability)
>
>
>
>
> Gotcha, makes sense.
>
>
>
> Richard kindly pointed me to the following SVE tutorial:
>
> https://gitlab.com/arm-hpc/training/arm-sve-tools
>
> But I believe it is worth noting we are actually interested on testing
> armv7 (AArch32) SIMD as well, so that won't probably be enough.
> I will dig more, and I will keep you posted
>
>
>
> Ok great, I'll take a look. Having *something* to test with will be a big leg 
> up,
> even if it isn't 

[gem5-dev] Re: RFC: run python Black on gem5 python code

[Giacomo Travaglini via gem5-dev]

Hi Jason,

This is great news. When you say it is not configurable, do you mean it is not 
possible to suppress warning/errors or do you
mean it is not possible to come up with custom rules?

As I presume it's the first case, I am wondering if a different linter might 
provide such capabilities:

https://books.agiliq.com/projects/essential-python-tools/en/latest/linters.html

Is there a reason to prefer black over other linters?

Kind regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 04 March 2021 03:59
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code
>
> I'm a little worried about the no exceptions part of that, since we might have
> some weird restrictions that we have to do weird things to work around, but I
> can't really think of an example of that off hand. I'd want to look at it to 
> see
> how much wiggle room there is in the style, since I think ironclad rules which
> make no accommodation for occasional common sense are maybe more
> trouble than they're worth. I'm not opposed to having at least some stated
> standard for python though, and the "official" one seems like a pretty
> reasonable choice. I guess it's fine with me, up until it causes me some sort 
> of
> problem :-)
>
> Maybe the right thing to do would be to give it a shot but not make it
> compulsory until we have a feeling for how much trouble it is.
>
>
> Gabe
>
> On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev  d...@gem5.org  > wrote:
>
>
> Sounds like a good idea to me.
> ---
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
> web: https://www.bobbybruce.net
>
>
>
> On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev
> mailto:gem5-dev@gem5.org> > wrote:
>
>
> +1
>
>
> Em quarta-feira, 3 de março de 2021 14:35:57 BRT, Jason
> Lowe-Power via gem5-dev mailto:gem5-
> d...@gem5.org> > escreveu:
>
>
> Hi all,
>
> Right now, we don't have an official style guide for python.
> Our style guide
> (http://www.gem5.org/documentation/general_docs/development/coding_st
> yle/) is very C++ focused.
>
> I would like to propose adopting a relatively strict PEP 8 style
> guide: https://www.python.org/dev/peps/pep-0008. This is the "official" style
> guide for python (as much as there is anything official). I say "relatively 
> strict"
> to mean that we will limit our exceptions *as much as possible*.
>
> To implement this, Andreas S. recently pointed me to the
> "Black" package (https://pypi.org/project/black/) which automatically fixes
> code style. I just tried it out with gem5art (patch coming soon) and found 
> that
> it works really well. The only downside is that it's not configurable at all.
> Adding special cases would be almost impossible.
>
> Concrete and specific proposal:
> - Adopt PEP 8 as our official style guide
> - Use black to reformat all python code in src/
> - Use black to reformat code in configs/
> - Use black to reformat other python code
>
> - Use black as part of our commit hook to make sure all future
> python is formatted to PEP 8
>
> Let me know what you think!
>
> Cheers,
> Jason
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: de-templating the O3 CPU

[Giacomo Travaglini via gem5-dev]

+2, +1, Merged



Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 27 February 2021 10:13
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] de-templating the O3 CPU
>
> Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to make 
> it
> possible to switch in different parts of the CPU to change how, for example, a
> pipeline stage is implemented.
>
> Realistically, the different parts of the CPU are probably too interdependent
> for that to actually work, and all the templates and indirection make the 
> code a
> lot more complicated than it really needs to be.
>
> Also, there is a pseudo-generic dynamic instruction base class in
> cpu/base_dyn_inst.hh which could, again theoretically, be used as a base class
> for other CPUs to reuse. Unfortunately that too is probably too tied to its 
> only
> consumer, the O3 CPU, to be realistically reusable.
>
> I would like to merge the base dynamic instruction class into the O3 version,
> and then de-templatize the whole O3 CPU. I think that will make the code a lot
> easier to work on, and I think our ability to maintain and update O3 is
> something we need to improve in at least the medium term.
>
> Any thoughts? Objections? Votes of support?
>
> Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: vector register indexing modes and renaming?

[Giacomo Travaglini via gem5-dev]

> -Original Message-
> From: Gabe Black 
> Sent: 27 February 2021 05:47
> To: Giacomo Travaglini 
> Cc: gem5 Developer List 
> Subject: Re: [gem5-dev] vector register indexing modes and renaming?
>
> Another question/clarification:
>
> Does any data actually get shared between the two rename modes? I think you
> said there is not, but now I can't find that.

Data *do* get shared, even if in gem5 we have separate physical registers.
In fact, when rename mode changes [1], (meta)data is copied from one register 
file to the other.
For example, say we have an AArch64 kernel running at EL1 and my AArch32 
(basically armv7) floating point application running at EL0.

My application will be using vector elements; however, every time there is an 
exception to AArch64, cpu will switch
Rename mode and data will be copied / mapping will be adjusted. Any FP & SIMD 
operation at this point will use vector registers.
When the kernel finishes its stuff, and goes back to AArch32, vector elements 
will be repopulated.

> Would it work just as well to have
> two register files which operate entirely independently?

As I mentioned before, they operate independently, but they sync up when we 
pass from one mode
To the other. Another way to look at it is that they are mutually exclusive.

> From what I can tell
> the "V" registers of Neon in aarch64 overlap with the SVE registers, and the 
> "Q"
> registers of armv7 Neon overlap with the "S", "D", "Q" registers of the same,
> but I think "V" and "Q" are independent? Maybe reused but not guaranteed to
> alias?
>

I would say the rule of thumb for understanding AArch64-AArch32 mapping (and 
it's the underlying cause of using different renaming modes) is to bear in mind 
that AArch64, differently from AArch32, uses an unpacked approach for FP & SIMD 
registers.
Prior to Armv8, smaller FP registers were packed into bigger registers [2]. 
Having for example 32 double precision registers (D0-D31) meant having a 
maximum of 16 quad word registers (Q0-Q15).
This setup has been abandoned in Armv8 [3]. As an example, S1, or D1 are not 
packed anymore in Q0. Those are in fact the 32/64 LSBits of Q1.
This means the newly added (V16-V31) are not accessible in AArch32.

So to answer your question regarding V and Q. Until Q/V15, they alias 
perfectly; V16-V31 are simply not
Defined/accessible in AArch32 so they are not aliased.

All AArch32 SIMD data is accessible from AArch64. It just won't stick to the 
same naming. AArch32 D1 and AArch64 D1 hold different data.
If I really wanted to access AArch32 D1 from AArch64 I would have to read the 
64 MSB of V0. This is a software and not an hardware problem (I just posted 
this example to stress the difference between aliasing and reachability)

> BTW, test cases would be very helpful if possible. I've made good progress
> cleaning away debris and am getting to the point where I'll want to make
> changes which I'm a lot less comfortable making blind.
>
> Gabe
>
> On Thu, Feb 25, 2021 at 10:40 PM Gabe Black   > wrote:
>
>
> I will ask within Arm if there's something we can
> provide to you.
> In the meantime I gave a quick look at NEON enabled
> libraries [1]; the Ne10 library provides a set of functions optimized for NEON
> and a set
> of examples making use of it [2] (e.g FIR filter, GEMM
> etc etc).
>
> You could probably cross-compile those examples and
> use them in SE mode (recommending to use the O3 model)
>
>
>
>
> Ok, thanks, I'll take a look. This might even be something we
> want in the testing infrastructure? I might look into that when I have a 
> chance.
>
>
> I took a look at this, and unfortunately I don't think I can use it. The
> example only builds for armv7 and not aarch64, and when I tried to build it 
> for
> armv7 I get a bunch of compiler errors. Do you have any other suggestions?

Richard kindly pointed me to the following SVE tutorial:

https://gitlab.com/arm-hpc/training/arm-sve-tools

But I believe it is worth noting we are actually interested on testing armv7 
(AArch32) SIMD as well, so that won't probably be enough.
I will dig more, and I will keep you posted

>
> Gabe

Kind Regards

Giacomo

[1]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/rename_map.cc#L173
[2]: 
https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/NEON-and-floating-point-registers/NEON-in-AArch32-execution-state-
[3]: 
https://developer.arm.com/documentation/den0024/a/ARMv8-Registers/NEON-and-floating-point-registers/Floating-point-register-organization-in-AArch64


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To 

[gem5-dev] Re: vector register indexing modes and renaming?

[Giacomo Travaglini via gem5-dev]

> -Original Message-
> From: Gabe Black 
> Sent: 24 February 2021 15:24
> To: Giacomo Travaglini 
> Cc: gem5 Developer List 
> Subject: Re: [gem5-dev] vector register indexing modes and renaming?
>
> So, I started really diving into the interfaces in ThreadContext and 
> ExecContext
> and their various implementations. What I wanted to do was to define a much
> narrower set of maybe 3 virtual functions that actually implements the core of
> what's needed, and not 15-20 different independent virtual methods that all
> need to be reimplemented every time. *That* was quite the rabbit hole, and
> after a number of hours I decided I needed to regroup and come at it from
> another angle. It definitely looks to me like somebody came in with the idea 
> to
> represent these registers using a data, model, view architecture (or something
> like that) which would make sense in other contexts with other types of data,
> but here I don't think is really the right way to go about this.
>
> Right now, I have two questions for you.
>
> 1. Are there tests which exercise this stuff? If I start chopping things up, I
> would be a lot more comfortable if I can tell if/when I break something.

I will ask within Arm if there's something we can provide to you.
In the meantime I gave a quick look at NEON enabled libraries [1]; the Ne10 
library provides a set of functions optimized for NEON  and a set
of examples making use of it [2] (e.g FIR filter, GEMM etc etc).

You could probably cross-compile those examples and use them in SE mode 
(recommending to use the O3 model)

> 2. What's the difference between a lane and an element? Those terms seem
> like they should be synonyms and are treated as almost the same thing, but
> there is clearly a difference between them. What is it, and why does it exist?
>
> Gabe
>

I have the hunch the vector lane logic it's not really used.
My understanding is that Lane/Elem differ in the O3 model only.
The key point is that VecRegister and VecElems are represented by a different 
set of physical registers; you cannot access a vector element if the renaming 
is set to Full[3]; the physical vector register file will be made of valid 
entries, while the vector element register file will be empty. The vector lane 
getters/setters are probably a way to do a functional read of the element 
anyway [4].
In a way we could think of VecReg/VecElem as being the interface to the vector 
file for a guest instruction, while the VecLane to be the interface for the 
host (even though it could be used by an instruction as well)

This is my interpretation of the VecLane

Kind Regards

Giacomo

[1]: https://developer.arm.com/architectures/instruction-sets/simd-isas/neon
[2]: https://github.com/projectNe10/Ne10/tree/master/samples
[3]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/rename_map.hh#L282
[4]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L229

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: vector register indexing modes and renaming?

[Giacomo Travaglini via gem5-dev]

Hi Gabe

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 23 February 2021 08:54
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] vector register indexing modes and renaming?
>
> Hey ARM folks. Could someone please explain to me what the deal is with the
> vector registers and renaming modes? What is fundamentally going on there?
> My best guess is that the granularity that the registers are being renamed at
> changes between the modes, or in other words you index by and rename by
> entire registers in one mode, and in the other mode you index by and rename
> by just the "elements" within the registers?

Yes that is correct, let me know if you need further info on this

>
> Are the "elements" or "lanes" or whatever in the registers fixed in size? How
> are these registers organized structurally? I've tried reading the code for 
> the
> structures behind them before, but I get lost in the difference between vector
> registers, vector register containers, elements, lanes, predicates, etc etc. 
> I need
> a big picture of what all these parts are and how they interrelate.
>
> Also, it's not a *great* sign if in order to understand this supposedly 
> generic
> mechanism I need to have knowledge of how vector registers are implemented
> in such-and-such extension which is part of ARM. That's not particularly
> generic... Although hopefully it could be reworked to be!
>
> Gabe

While I believe there is room for improvement for the current vector data type 
in gem5,
that is not an Arm only implementation. All the names you mentioned are standard
terminology in computer architecture / SIMD implementations.
(except for "containers", which is simply a made up name in gem5 to describe 
the vector storage).

For example, predicates are a way to do element-wise masking (predicating) in 
vector operations. Those are
called opmask registers in x86 AVX-512 [1] and predicate registers in the RISCV 
vector proposal [2]
(I don't know what's the status of it though) and in Arm SVE

Kind Regards

Giacomo

[1]: https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
[2]: https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 21.0 Release blockers

[Giacomo Travaglini via gem5-dev]

Hi Bobby,

It would be nice if we could get this in as well:

https://gem5-review.googlesource.com/c/public/gem5/+/39898/2

Kind Regards

Giacomo

> -Original Message-
> From: Bobby Bruce via gem5-dev 
> Sent: 17 February 2021 08:12
> To: gem5 Developer List 
> Cc: Bobby Bruce 
> Subject: [gem5-dev] gem5 21.0 Release blockers
>
> Dear all,
>
> We hope to soon create the staging branch for the gem5 21.0 release soon,
> with the goal of releasing in early March. However, we will not do so until 
> the
> following items are fully reviewed, and incorporated into the gem5 develop
> branch.
>
>
> * Changes to the Ruby memory system: https://gem5-
> review.googlesource.com/c/public/gem5/+/31416
>
> * Updates necessary for RISC-V full-system simulation: https://gem5-
> review.googlesource.com/c/public/gem5/+/41033
>
> * The Python Stats/ JSON output: https://gem5-
> review.googlesource.com/c/public/gem5/+/41514
>
> As these are currently blocking our release, we will be focusing on them over
> the next few days.
>
>
> If anyone has a good case for their patchsets (currently under review or to be
> submitted ASAP) to be incorporated into gem5 21.0, then please get in touch
> so we can be made aware and push for their inclusion.
>
>
> Kind regards,
> Bobby
>
> --
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
> web: https://www.bobbybruce.net

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: test library error

[Giacomo Travaglini via gem5-dev]

In my experience the mentioned problem:

> AttributeError: 'TestCaseMetadata' object has no attribute 'time'

It's a simple reflection of a regression not being able to complete its 
execution (note, this is different than failing), and it is not strictly 
related to testlib.
If the regression is timing out, testlib is not able to produce the execution 
time and it is therefore raising an exception when the metadata needs to be
serialized to the xml file.

I think we should consider adding a default zero value to the time property so 
that people don't get mislead by the python backtrace

Kind Regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 10 February 2021 21:59
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: test library error
>
> I don't think so, I just wanted to point it out since it would otherwise 
> probably
> never get seen. I do occasionally see weird errors like this, but not all that
> often. I haven't paid close enough attention to them to notice if they follow 
> a
> pattern.
>
> Gabe
>
> On Wed, Feb 10, 2021 at 11:30 AM Bobby Bruce via gem5-dev  d...@gem5.org  > wrote:
>
>
> Hey Gabe,
>
> This is weird, though I cannot replicate it. I'd also guess it's weird
> timeout. Have you seen it elsewhere?
>
> Kind regards,
> Bobby
>
> --
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
> web: https://www.bobbybruce.net
>
>
>
> On Mon, Feb 8, 2021 at 9:31 PM Gabe Black via gem5-dev  d...@gem5.org  > wrote:
>
>
> Hi folks. In the kokoro log for this run, I see the below error. I
> suspect it timed out? In any case, it looks like there's a bug in the testing 
> library
> somebody might want to look into.
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/40795/3
>
>
> https://source.cloud.google.com/results/invocations/558d1dfb-a6bd-
> 46f9-baac-6f53d3ac0fd3
>
>
>
>  Results: 597 Passed, 6 Failed, 1 Errored in 1.3e+04
> seconds == Traceback (most recent call last): File "./main.py", line 
> 25,
> in  sys.exit(testlib()) File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/main.py", line 331, in main result =
> globals()['do_'+configuration.config.command]() File "/tmpfs/src/git/jenkins-
> gem5-prod/tests/../ext/testlib/main.py", line 303, in do_run return
> run_schedule(test_schedule, log_handler) File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/main.py", line 277, in run_schedule
> log_handler.finish_testing() File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/main.py", line 68, in finish_testing
> self.result_handler.close() File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/handlers.py", line 164, in close self._save() File
> "/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/handlers.py", line 156,
> in _save result.JUnitSavedResults.save( File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/result.py", line 330, in save results =
> JUnitTestSuites(results) File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/result.py", line 238, in __init__
> self.elements.append(JUnitTestSuite(suite)) File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/result.py", line 264, in __init__
> self.elements.append(JUnitTestCase(test)) File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/result.py", line 277, in __init__ 
> XMLAttribute('time',
> str(test_result.time["user_time"])), File "/tmpfs/src/git/jenkins-gem5-
> prod/tests/../ext/testlib/result.py", line 77, in time return 
> self._metadata.time
> AttributeError: 'TestCaseMetadata' object has no attribute 'time'
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org  d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: version of pybind11 without everything in the headers

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

I believe you are referring to the following ticket:

https://gem5.atlassian.net/browse/GEM5-277

Ciro is currently on vacation and he will be back next week so he will be able 
to update
you on his progresses. IIRC pybind folks are reviewing his contribution but I 
cannot provide
you a timeline (Ciro might)

Kind Regards

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 04 February 2021 09:45
> To: gem5 Developer List ; Ciro Santilli
> 
> Cc: Gabe Black 
> Subject: [gem5-dev] version of pybind11 without everything in the headers
>
> Hey folks and particularly Ciro, I know a while ago there was an attempt to 
> put
> the common contents of pybind11 into a lib. Did that go anywhere? That
> would reduce build time which would be valuable, but from this change it's
> apparent that all those common symbols are *really* blowing up the build
> directory.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/40621/1
>
>
> Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Some evidence build times have substantially increased on Jenkins

[Giacomo Travaglini via gem5-dev]

P.S. A lot of other builds would have failed using today's timeout.
Check for example build #176 and #177 of the Nightly (end of December)

This makes a lot of sense as these days overlap with the Compiler-Checks run.
In fact, almost every time we run Compiler-Checks the Nightly takes more than a 
day to complete

Kind Regards

Giacomo


> -Original Message-
> From: Giacomo Travaglini via gem5-dev 
> Sent: 27 January 2021 22:23
> To: gem5 Developer List 
> Cc: Giacomo Travaglini 
> Subject: [gem5-dev] Re: Some evidence build times have substantially
> increased on Jenkins
>
> Hi Bobby,
>
> While I agree there might be something wrong with it, It can be partly
> explained with the sheer amount of patches which is being reviewed and
> merged in these days. This is affecting compilation time in the following 
> ways:
>
> a) Overloading Jenkins with the gem5-develop job -> this is not valid anymore
> as it has been removed
> b) By changing big portions of code, increasing recompilation time (there are
> more translation units to be recompiled)
>
> If I have a look at the Jenkins history for example, most of the Nightlies at 
> the
> beginning of the month had almost no patches
>
> Nighly #180 for example took 13 hours but as you can see had no patches
>
> https://jenkins.gem5.org/job/Nightly/180/
>
> The first run that was testing more than two patches is #183
>
> https://jenkins.gem5.org/job/Nightly/184/
>
> And in fact it took 1 day and two hours to complete. This would have failed
> with the current setup of timing out in 23 hours.
> If you compare #patches with execution time you see a strong correlation
> between these two
>
> Same applies with the compiler check. Now situation is to get a bit better, 
> but
> IMHO in the last few days the combination of a) + b) has been lethal.
>
> There might be something else though
>
> Kind Regards
>
> Giacomo
>
> > -Original Message-
> > From: Bobby Bruce via gem5-dev 
> > Sent: 27 January 2021 21:00
> > To: gem5 Developer List 
> > Cc: Bobby Bruce 
> > Subject: [gem5-dev] Some evidence build times have substantially
> > increased on Jenkins
> >
> > Dear all,
> >
> > As you may have noticed from the mailing list, our nightly builds are
> > failing due to timeouts, as are the compiler checkers. Though this is
> > just a preliminary look at the problem, I've noticed that the gem5
> > build times on our Jenkins have increased substantially. Looking at
> > our last passing compiler checks, gem5 compiled in roughly 1.5 hours:
> > http://jenkins.gem5.org/job/Compiler-
> > Checks/40/. Looking at our first failing compiler checks, this has
> > jumped to roughly 3.5 hours: http://jenkins.gem5.org/job/Compiler-
> Checks/41/.
> >
> > This is just an FYI and a reachout to see if anyone has any ideas why
> > this might be. I'm currently looking to see if I can replicate these
> > poor compile times outside of Jenkins. I have noticed that our Gerrit
> > Kokoro appears to have continued running just fine (no timeouts), so
> > this may be some issue specific to our Jenkins setup.
> >
> >
> > Kind regards,
> > Bobby
> >
> > --
> >
> > Dr. Bobby R. Bruce
> > Room 2235,
> > Kemper Hall, UC Davis
> > Davis,
> > CA, 95616
> >
> >
> > web: https://www.bobbybruce.net
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to
> gem5-dev-
> le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Some evidence build times have substantially increased on Jenkins

[Giacomo Travaglini via gem5-dev]

Hi Bobby,

While I agree there might be something wrong with it, It can be partly 
explained with the sheer amount of patches which
is being reviewed and merged in these days. This is affecting compilation time 
in the following ways:

a) Overloading Jenkins with the gem5-develop job -> this is not valid anymore 
as it has been removed
b) By changing big portions of code, increasing recompilation time (there are 
more translation units to be recompiled)

If I have a look at the Jenkins history for example, most of the Nightlies at 
the beginning of the month had almost no patches

Nighly #180 for example took 13 hours but as you can see had no patches

https://jenkins.gem5.org/job/Nightly/180/

The first run that was testing more than two patches is #183

https://jenkins.gem5.org/job/Nightly/184/

And in fact it took 1 day and two hours to complete. This would have failed 
with the current setup of timing out in 23 hours.
If you compare #patches with execution time you see a strong correlation 
between these two

Same applies with the compiler check. Now situation is to get a bit better, but 
IMHO in the last few days the combination of a) + b) has been lethal.

There might be something else though

Kind Regards

Giacomo

> -Original Message-
> From: Bobby Bruce via gem5-dev 
> Sent: 27 January 2021 21:00
> To: gem5 Developer List 
> Cc: Bobby Bruce 
> Subject: [gem5-dev] Some evidence build times have substantially increased on
> Jenkins
>
> Dear all,
>
> As you may have noticed from the mailing list, our nightly builds are failing 
> due
> to timeouts, as are the compiler checkers. Though this is just a preliminary 
> look
> at the problem, I've noticed that the gem5 build times on our Jenkins have
> increased substantially. Looking at our last passing compiler checks, gem5
> compiled in roughly 1.5 hours: http://jenkins.gem5.org/job/Compiler-
> Checks/40/. Looking at our first failing compiler checks, this has jumped to
> roughly 3.5 hours: http://jenkins.gem5.org/job/Compiler-Checks/41/.
>
> This is just an FYI and a reachout to see if anyone has any ideas why this 
> might
> be. I'm currently looking to see if I can replicate these poor compile times
> outside of Jenkins. I have noticed that our Gerrit Kokoro appears to have
> continued running just fine (no timeouts), so this may be some issue specific 
> to
> our Jenkins setup.
>
>
> Kind regards,
> Bobby
>
> --
>
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
> web: https://www.bobbybruce.net

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Nightly stuck

[Giacomo Travaglini via gem5-dev]

Hi all,

This has been fixed and it's going to be merged today.

This made me realize we might want to introduce a timeout for our regressions. 
A global, Jenkins level one is easy to add and doesn't require any code 
modifications.

However a per-test timeout is probably the best approach. In this way we can:

a) Understand which regression is deadlocking from the output log
b) Killing the failing test earlier thus saving computational costs:

e.g: I will kill the test after 6 minutes if it is supposed to complete in a 
minute, rather than having a global abort set up after 24 hours.

How to do this is up do debate. This falls within the typical wall-clock time 
vs cpu time issue; setting up a timeout for wall-clock time is straightforward 
with python subprocess, but cpu time is what we would really care about...
Though if we make sure our timing out margin is relatively high (loosening the 
safety net) we can probably get around the intrinsic difference between the two 
metrics and just use wall-clock time.

Does anybody have any thoughts on this?

Giacomo

> -Original Message-
> From: Giacomo Travaglini
> Sent: 18 January 2021 10:22
> To: gem5 Developer List 
> Subject: Nightly stuck
>
> Hi devs,
>
> It seems like the following Nightly run #191 is stuck:
>
> https://jenkins.gem5.org/job/Nightly/191/
>
> I am running those tests locally to understand if it is a tool problem or 
> broken
> long regressions are currently broken Will keep you posted
>
> Kind Regards
>
> Giacomo
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Nightly stuck

[Giacomo Travaglini via gem5-dev]

Hi devs,

It seems like the following Nightly run #191 is stuck:

https://jenkins.gem5.org/job/Nightly/191/

I am running those tests locally to understand if it is a tool problem or 
broken long regressions are currently broken
Will keep you posted

Kind Regards

Giacomo
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: IWYU tool and include checking from scons

[Giacomo Travaglini via gem5-dev]

We could add it to scons as an extra flag which is defaulting to False, and 
properly set in our regression scripts
(I am also in favour of adding IWYU)

Kind Regards

Giacomo

> -Original Message-
> From: Nikos Nikoleris via gem5-dev 
> Sent: 13 January 2021 15:57
> To: gem5-dev@gem5.org
> Cc: Nikos Nikoleris 
> Subject: [gem5-dev] Re: IWYU tool and include checking from scons
>
> I am also in favor of a tool like iwyu and I have used it in the past.
> However, iirc iwyu suggestions were not perfect. For example, it suggested to
> remove of "debug/xxx.hh" flags and in many cases required manual
> intervention. So before dealing with the scons mechanics we might have to
> deal with these cases.
>
> I am also a little worried about adding more dependencies for every user. We
> often compile/run gem5 in clusters where lib/tool versions might not be the
> latest. It would be great if this was part of our regressions and before
> committing we would check if something is missing.
>
> Nikos
>
> On 13/01/2021 15:39, Daniel Carvalho via gem5-dev wrote:
> > I am in favor of running a tool like IWYU to fix the codebase
> > (although I have never used it), but I am not sure if adding this to
> > the build system is a good idea: our current contribution frequency
> > (~1k
> > commits/year?) likely does not generate enough extra/missing includes
> > to require the overhead added to every build. There is also the issue
> > of adding another dependency VS making it optional and creating an
> > inconvenience for others: users that do not use the tool will generate
> > compilation warnings/errors for users that do.
> >
> > IMO, unless the overhead is unnoticeable, it would be enough to run
> > IWYU once a semester/year to try to find and fix any the period's mistakes.
> > If doing this periodic approach, we should probably add an util script
> > that installs IWYU, builds/fixes the includes, and uninstalls IWYU, in
> > order to automate the process.
> >
> > Best,
> > Daniel
> > Em terça-feira, 12 de janeiro de 2021 22:41:58 BRT, Gabe Black via
> > gem5-dev  escreveu:
> >
> >
> > Hi folks. Daniel has submitted a big change which fixes up a bunch of
> > missing includes in files which were coincidentally getting the
> > definitions they needed indirectly from some other file. Way down the
> > line in c++20 I think the "modules" mechanism would be a great tool
> > avoiding these sorts of problems from the get go, but in the meantime
> > it would be helpful if we had a way to scan for these sorts of issues,
> > instead of finding them when they cause problems. These sorts of
> > overly broad, leaky includes also likely slow down builds by making
> > the compiler process more text than it really needs to, and also
> > introduces more dependencies at the scons level than are necessary.
> >
> > I'm not really familiar with it, but after a little bit of Googling I
> > found a tool called iwyu (include what you use) which looks at
> > includes and finds places where includes are missing (transitive
> > includes), and also includes which are not being used. It looks like
> > the way this tool is intended to be used is to substitute it for the
> > compiler, and then run it through, for instance, make.
> >
> > Rather than use it that way, I'm thinking we might be able to set up
> > additional scons rules which would build iwyu error reports based on
> > Source declarations in scons, alongside the normal build outputs.
> > There may be false positives in there somewhere, particularly from
> > code we don't control, and so we'd likely want to add in ways to flag
> exceptions.
> >
> > If this sort of scons integration works out, it would be nice to make
> > a pass of this tool part of the presubmit checks, assuming it doesn't
> > add tons of time to the build.
> >
> > What do folks think? I don't necessarily have a lot of time to work on
> > this myself, although I might give it a shot if I find some time. It
> > could also be something for someone wanting to cut their teeth on
> > scons to help with, and I could help give pointers and help with the
> > high level design if someone wanted to try it. If you do want to give
> > it a try, at the very least keep me in the loop so we don't have to
> > redo things in a major way when it comes time to check something in.
> >
> > Gabe
> > ___
> > gem5-dev mailing list -- gem5-dev@gem5.org 
> > To unsubscribe send an email to gem5-dev-le...@gem5.org
> > 
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> >
> > ___
> > gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an
> > email to gem5-dev-le...@gem5.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> >
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> 

[gem5-dev] Re: CPU/thread context capabilitiy/feature bits

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

Let me first say that I like what you are trying to do.

Are you thinking about changing the querying interface only, or are you 
thinking about restructuring the back-end as well? Like where ISA specific 
parameters are actually stored? For example in Arm we have system level 
properties stored in the ArmSystem and cached in the ISA class.

(So if you just want to change the “front-end”, it would be

tc->checkFeature->isa->feature or
tc->checkFeature->isa->system->feature)

I’ve always felt the need of sorting out the ArmSystem mess, which is providing 
capabilities for *FS oly*
So we usually configure system level parameters for FS and we hardcode some of 
those in SE mode (ArmSystem is not instantiated in SE).

I believe a reasonable approach would be to define a global System Level 
parameters object which will be used for both SE and FS, replacing what we are 
doing with the ArmSystem.

Not trying to push any work on you, simply sharing my view in case there was an 
overlap with your plan

Kind Regards

Giacomo

From: Gabe Black via gem5-dev 
Sent: 15 December 2020 05:53
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] CPU/thread context capabilitiy/feature bits

Hi folks. There have been a number of situations I've run into where different 
CPU models support different features. Some of these are generic:

"Hardware" breakpoints - not supported in KVM
GDB support in general?
Different gem5 op mechanisms - instruction based, address based
SMT
checkpointing

And some are architecture specific:
ARM
Semihosting based gem5 ops
GIC version
x86 -
Syscall/sysret vs. sysenter/sysexit in compatibility mode
major vendor differences like SVM vs VMX
Level of support for SIMD instruction set

When running a KVM CPU, these things can even depend on what the host is, ie 
what support the host CPU has which can be exposed to the simulation.


Rather than try to just pick something that will break in the least painful 
way, or try to check for particular models to try to infer what's supported, or 
to have to manually configure things to avoid missing features, it would be 
really helpful, I think, for the models to be able to just declare what they 
support.

I haven't thought about this super deeply yet, but my thought so far is to have 
a new ThreadContext function, something like FeatureVal 
checkFeature(FeatureNum) where FeatureVal is an int64_t, and FeatureNum is a 
uint64_t or possibly an enum. If a feature isn't recognized, the return value 
should be something inert like 0 or -1, and if it is then the meaning of the 
value depends on the definition of the feature. The FeatureNum value would have 
two (or more?) classes, one which would be generic (MSB is 0?) and one which 
would be ISA specific (MSB is 1?). The CPU would directly answer generic 
requests because it would know the answer, and would dispatch non-generic 
requests to the ISA object.

Alternatively they could be called Capabilities instead of Features?

Thoughts?

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Kernel ``init'' in Ubuntu 18.04 for ARM

[Giacomo Travaglini via gem5-dev]

Hi Samuel,

Thanks for reporting this.
There is an init file, it is in the root directory: /init.gem5.
You can manually select that by using the --kernel-init option in 
fs_bigLITTLE.py

I will amend the distributed disk image providing a symlink to /init.gem5 in 
/sbin/init for consistency
With our previous disk images

Kind Regards

Giacomo

> -Original Message-
> From: Samuel Thomas via gem5-dev 
> Sent: 11 December 2020 15:42
> To: gem5-dev@gem5.org
> Cc: Samuel Thomas 
> Subject: [gem5-dev] Kernel ``init'' in Ubuntu 18.04 for ARM
>
> Hi all,
>
> I'm building and running gem5 using the guest binary Ubuntu 18.04 image for
> ARM64 linked from the gem5 guest binaries page
> (https://www.gem5.org/documentation/general_docs/fullsystem/guest_binari
> es). However, when running the system in full system for ARM bigLITTLE
>
> ```
> gem5-workspace/gem5/build/ARM/base-gem5.opt gem5-
> workspace/gem5/configs/example/arm/fs_bigLITTLE.py --kernel gem5-
> workspace/gem5/dist/binaries/vmlinux.arm64 --cpu-type atomic --dtb gem5-
> workspace/gem5/system/arm/dt/armv8_gem5_v1_big_little_2_2.dtb --disk
> gem5-workspace/gem5/dist/disks/ubuntu-18.04-arm64-docker.img --
> bootscript gem5-workspace/gem5/bootscripts/test.rcS
> ```
>
> I get the following error
>
> ```
> [3.915428] Kernel panic - not syncing: Requested init /sbin/init failed 
> (error -
> 2).
> [3.915434] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0+ #1
> [3.915439] Hardware name: V2P-AARCH64 (DT)
> [3.915442] Call trace:
> [3.915447]  dump_backtrace+0x0/0x1c0
> [3.915453]  show_stack+0x14/0x20
> [3.915458]  dump_stack+0x8c/0xac
> [3.915462]  panic+0x130/0x288
> [3.915467]  kernel_init+0xa8/0x108
> [3.915472]  ret_from_fork+0x10/0x18
> [3.915477] Kernel Offset: disabled
> [3.915481] CPU features: 0x21c06492
> [3.915485] Memory Limit: 2048 MB
> [3.915492] ---[ end Kernel panic - not syncing: Requested init /sbin/init 
> failed
> (error -2). ]---
> ```
>
> And a kernel panic in the host terminal process.
>
> I mounted the Ubuntu 18.04 disk image into a temporary directory to examine
> the contents of the /sbin/ directory to confirm that there wasn't an init file
> there (which there was not).
>
> My next step was to look at the /sbin/ directory of an Ubuntu 18.04 virtual
> machine to see if perhaps there was a different kernel init file being used
> under this version of Ubuntu (I also have the "aarch64-ubuntu-trusty-
> headless.img" downloaded from gem5 guest binaries, and there is a file
> /sbin/init in that image) so that I could just change where gem5 looks for 
> this
> binary, but - based on the VM - it seems as though this file structure hasn't
> changed.
>
> Is this an issue with gem5's released version of Ubuntu 18.04 for ARM? And if
> so, is there either (a) an alternative image file for Ubuntu 18.04 for ARM 
> with
> the appropriate kernel initialization files or (b) a place where those files 
> exist
> where I can install them onto the current Ubuntu 18.04 image?
>
> Thank you for your help!
>
> Sam
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to
> gem5-dev-
> le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: seL4 on gem5

[Giacomo Travaglini via gem5-dev]

Hi,

In general terms I agree; We are relying on the 
https://github.com/gem5/gem5/blob/develop/configs/example/arm/baremetal.py 
platform for its capability of loading several binaries as extras without 
needing to know what those binaries actually are (ish). We use it in different 
scenarios (for example when using TFA or Xen).

About your specific problem, I don’t know seL4, but as far as I can see from 
the docs https://docs.sel4.systems/Hardware/ we don’t support any of those ARM 
platforms (our platforms are variations of the Versatile Express family).

With Linux you are pretty flexible thanks to FDTs; I am honestly not aware on 
the configurability of seL4, if it is employing such a flexible scheme or if it 
is quite strict, which leaves you to the task of either porting seL4 to gem5 or 
to define a seL4 supported platform in gem5

Please let us know if you succeed in any of those tasks or if you find a 
workaround to the problem

Kind Regards

Giacomo

From: Gabe Black via gem5-dev 
Sent: 12 November 2020 11:02
To: gem5 Developer List 
Cc: bodu...@utexas.edu; Gabe Black 
Subject: [gem5-dev] Re: seL4 on gem5

Some ISAs have the ability to boot a "bare metal" system, which I think 
basically means anything that the ELF loader can handle. I'm pretty sure ARM 
supports this, and has an example config using it in the configs directory. I 
think we're getting pretty close to being able to set up a new type of full 
system workload at the same level of support as Linux or FreeBSD, although we 
haven't tried adding a totally new OS using those interfaces yet so they might 
not have all the degrees of freedom you might need. I'm also not sure what 
level that support is at in the current release branch, although that was 
checked in a while ago and so should be there at least mostly. You can take a 
look at the Workload code in the src/sim directory and how it's applied to 
Linux, etc, if you want to set up something similar for your other OS. If not, 
or if that doesn't work for some reason, then bare metal is probably your next 
best bet.

Gabe

On Wed, Nov 11, 2020 at 2:17 PM bodunhu--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Is there any way to boot seL4 inside gem5 (simulating aarch64 on a host of 
X86_64)? I've searched for a lot of documentations but didn't find anything 
remotely close to booting non-Linux OSes in gem5. I'm not sure if this is 
something that requires instrumenting gem5 itself or it should work out of the 
box? Any tips will be helpful.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to 
gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: SimObject params() method

[Giacomo Travaglini via gem5-dev]

Let me add to the plate a simple proposal though still a bit verbose and 
probably not that different from a manual cast

Defining a template method in SimObject:

template 
Obj params()
{
return static_cast(_params);
Or more secure:
param =  dynamic_cast(_params);
assert(param);
return param;
}

And delegate the type specification on the client side:

For example in my shiny new

Class MyObject : public SimObject {}

I would use

auto p = params();

You still have to type your param type so that doesn’t make it the best but I 
believe it’s the simplest one

Giacomo

From: Jason Lowe-Power via gem5-dev 
Sent: 22 October 2020 16:26
To: gem5 Developer List 
Cc: Gabe Black ; Jason Lowe-Power 
Subject: [gem5-dev] Re: SimObject params() method

Hey Gabe,

Thanks for bringing this up. I have also been bothered by the lack of 
consistency with how params are used. I can't think of an example of when you 
need to store the params object. I would be all for getting rid of the params() 
function and updating the documentation to say that it's best practice to *not* 
save the params struct after the constructor. If some object had a good reason 
to go against this best practice, that would be OK, and we wouldn't need to 
enforce any specific design or pattern on these exceptions. I would prefer to 
remove the params() function than add more template magic.

On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Hi folks. I'm looking at the SimObject header, and I see a few things in there 
which are marked as part of the API and maybe shouldn't be. Specifically I'm 
talking about the Params typedef, and the params() method. There is also the 
_params member variable which I can see being a part of the API since it can be 
used by other classes to make their own params() function (more on that below), 
but the Params typedef is more or less an implementation detail, and the 
params() method is essentially worthless because it returns a SimObjectParams 
which doesn't have anything except the object's name in it, and you can already 
get that with the name() method.

I agree. I think the typedef is useless and shouldn't be in the API. It's 
unfortunate that the API proposals didn't get more reviews. I think it's 
probably OK to just drop that from the API, but the params() function itself is 
going to need to be deprecated.


Params pattern

This gets to the whole Params params() pattern which is sporadically 
implemented in some SimObjects in gem5. This pattern is that a given SimObject 
subclass will define a Params typedef which corresponds to its Params struct 
type, and then also define a params() method which returns the _params from 
SimObject cast up to that type.

The Params typedef itself primarily makes the definition of the constructor a 
little more legible, since the FullFooTypeForTheArmISAParams can be really 
verbose.

I think verbose is fine. I would vote to abolish all params typedefs.


Storing the params struct itself could theoretically serve the purpose of 
having a bunch of parameters and not having to create a member variable for 
each one, spend a bunch of text copying values over in the constructor, etc. I 
think most of the time this is unnecessary, but if an object has tons of values 
in it for some reason this could make sense.

I don't think there are any examples of this in the codebase. I think in all 
cases the params data is copied into member variables. If there are cases where 
data isn't copied, I doubt it was with a strong reason in mind. The one 
exception to this might be Ruby, but it's an exception for all the wrong 
reasons ;).


The params() method then makes the _params member available with the 
appropriate type, so that all the FooParams members are accessible. It also 
makes the params struct accessible outside the object which is used in a place 
or two to read parameters without there needing to be a member in the object, 
and probably some sort of accessor to read it.

There are two main problems with this system. First, when used, it adds a small 
but not trivial amount of boilerplate to any given class. Second, it's very 
sporadically implemented. I think in a lot of places it's there just because 
people aren't sure what it's for or if they need it, so they just put one there 
regardless. I think I've done that in the past.

Alternative

The existence of the Params type and the params() method could be partially 
eliminated by defining a templated params() method which took a SimObject 
reference and/or pointer as its first parameter. It could then figure out what 
Params struct went with that SimObject type using typedef/template magic set up 
by the Params building code, and then perform the appropriate cast.

This has three downsides, two minor and one more serious. The minor one is that 
when a class uses this method internally, it would have to do something like 
params(this) instead of just params(). 

[gem5-dev] Re: Build failed in Jenkins: Nightly #91

[Giacomo Travaglini via gem5-dev]

Yes you are right; of course when I use

alias scons=python `which scons`

I am assuming I already have a python3 installed somewhere in my machine as 
“python”
Your variation is probably better as doesn’t require you to use a virtualenv in 
a python2/python3 capable machine

Giacomo

From: Jason Lowe-Power 
Sent: 13 October 2020 16:46
To: gem5 Developer List 
Cc: Poremba, Matthew ; Giacomo Travaglini 

Subject: Re: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi all,

Yeah, this is 100% a scons problem. I'm not sure what we can do about it. To be 
more straightforward here are the possible solutions:

1. install python-is-python3
2. pip install scons
3. Edit /usr/bin/scons to use python3
4. Add `alias scons3="/usr/bin/env python3 $(which scons)"` to ~/.bashrc
5. probably others

For us, I think we should put a check at the very beginning of the scons 
execution to check to make sure it's running under python3. If it's not, we 
should print the above workarounds.

BTW, I don't think "alias scons=python `which scons`" will work in general. I 
think it should be "alias scons=python3 `which scons`" since python may be a 
symlink to python2.

Let me know if you have a better idea.

Cheers,
Jason

On Tue, Oct 13, 2020 at 8:41 AM Giacomo Travaglini via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Forgot to mention: I am choosing the latter

Giacomo

From: Giacomo Travaglini
Sent: 13 October 2020 16:40
To: gem5 Developer List mailto:gem5-dev@gem5.org>>; Poremba, 
Matthew mailto:matthew.pore...@amd.com>>
Cc: Jieming Yin mailto:bjm...@gmail.com>>
Subject: RE: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi all,

I had the same issue. The problem in my case was in scons, which was selecting 
python2 when building gem5 disregarding my python3 virtualenv

$less `which scons`
#! /usr/bin/python

And /usr/bin/python was linked to python2.7.

So the available solutions are:


  *   Installing a newer scons version with

#!/usr/bin/env python


  *   changing the symbolic link,
  *   modify the shebang of the preinstalled one,
  *   CL selection of the scons interpreter:
alias scons=python `which scons`

Kind Regards

Giacomo

From: Jieming Yin via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: 09 October 2020 02:43
To: Poremba, Matthew mailto:matthew.pore...@amd.com>>
Cc: gem5 Developer List mailto:gem5-dev@gem5.org>>; Jieming 
Yin mailto:bjm...@gmail.com>>
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi Matt,

My workaround is to do it in a python2 manner:

class SEWorkload(Workload):
type = 'SEWorkload'
__metaclass__ = SEWorkloadMeta

I have the same syntax error because I am running the gem5-gcn docker, and I 
have both python2 and python3 installed. But I don't really know how to fix it, 
it seems python2 is used sometimes.

Jieming

On Thu, Oct 8, 2020 at 7:43 PM Bobby Bruce via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Hey Matt,

Before the nightly tests were run on Jenkins server which was an Ubuntu 18.04 
machine with Python2.

The nightly tests will now run using our Ubuntu 20.04 docker image: 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies<http://gcr.io/gem5-test/ubuntu-20.04_all-dependencies>
 (Dockerfile source: 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile).

So, to compile gem5.opt for the ARM ISA, the nightly will use:

```
docker run -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) --rm 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies<http://gcr.io/gem5-test/ubuntu-20.04_all-dependencies>
 scons build/ARM/gem5.opt
```

I'm going to guess you probably still have Python2 somewhere on your machine 
and it's using it during the compilation. I'll setup some tests on my end and 
see if I can recreate this problem. I _think_ right now we only test in 
environments that either have only Python2 or have only Python3, so we should 
probably have some tests to check what happens if someone has both.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Oct 8, 2020 at 4:10 PM Poremba, Matthew 
mailto:matthew.pore...@amd.com>> wrote:

[AMD Public Use]

Hi Bobby,


What is/was the fix for this issue? I also cannot build even though I have 
python 3.6 installed (via apt-get on Ubuntu 20.04).  I am manually passing 
python3-config to scons but I’m getting a syntax error when it sees the 
metaclass keyword.


-Matt

From: Bobby Bruce via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: Thursday, October 8, 2020 3:19 PM
To: gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Bobby Bruce mailto:bbr...@ucdavis.edu>>
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

[CAUTION: External Email]
Hey all,

The source of this issue is that our Jenkin's server was using Python2, and a 
commit was merged w

[gem5-dev] Re: Build failed in Jenkins: Nightly #91

[Giacomo Travaglini via gem5-dev]

Forgot to mention: I am choosing the latter

Giacomo

From: Giacomo Travaglini
Sent: 13 October 2020 16:40
To: gem5 Developer List ; Poremba, Matthew 

Cc: Jieming Yin 
Subject: RE: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi all,

I had the same issue. The problem in my case was in scons, which was selecting 
python2 when building gem5 disregarding my python3 virtualenv

$less `which scons`
#! /usr/bin/python

And /usr/bin/python was linked to python2.7.

So the available solutions are:


  *   Installing a newer scons version with

#!/usr/bin/env python


  *   changing the symbolic link,
  *   modify the shebang of the preinstalled one,
  *   CL selection of the scons interpreter:
alias scons=python `which scons`

Kind Regards

Giacomo

From: Jieming Yin via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: 09 October 2020 02:43
To: Poremba, Matthew mailto:matthew.pore...@amd.com>>
Cc: gem5 Developer List mailto:gem5-dev@gem5.org>>; Jieming 
Yin mailto:bjm...@gmail.com>>
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi Matt,

My workaround is to do it in a python2 manner:

class SEWorkload(Workload):
type = 'SEWorkload'
__metaclass__ = SEWorkloadMeta

I have the same syntax error because I am running the gem5-gcn docker, and I 
have both python2 and python3 installed. But I don't really know how to fix it, 
it seems python2 is used sometimes.

Jieming

On Thu, Oct 8, 2020 at 7:43 PM Bobby Bruce via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Hey Matt,

Before the nightly tests were run on Jenkins server which was an Ubuntu 18.04 
machine with Python2.

The nightly tests will now run using our Ubuntu 20.04 docker image: 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies
 (Dockerfile source: 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile).

So, to compile gem5.opt for the ARM ISA, the nightly will use:

```
docker run -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) --rm 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies
 scons build/ARM/gem5.opt
```

I'm going to guess you probably still have Python2 somewhere on your machine 
and it's using it during the compilation. I'll setup some tests on my end and 
see if I can recreate this problem. I _think_ right now we only test in 
environments that either have only Python2 or have only Python3, so we should 
probably have some tests to check what happens if someone has both.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Oct 8, 2020 at 4:10 PM Poremba, Matthew 
mailto:matthew.pore...@amd.com>> wrote:

[AMD Public Use]

Hi Bobby,


What is/was the fix for this issue? I also cannot build even though I have 
python 3.6 installed (via apt-get on Ubuntu 20.04).  I am manually passing 
python3-config to scons but I’m getting a syntax error when it sees the 
metaclass keyword.


-Matt

From: Bobby Bruce via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: Thursday, October 8, 2020 3:19 PM
To: gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Bobby Bruce mailto:bbr...@ucdavis.edu>>
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

[CAUTION: External Email]
Hey all,

The source of this issue is that our Jenkin's server was using Python2, and a 
commit was merged which utilized some Python3 exclusive features: 
https://gem5-review.googlesource.com/c/public/gem5/+/33900

We are going to drop support for Python2 in the next release, so I've upgraded 
our nightly tests to use Python3. They should pass tonight.

I'm unsure if this has been officially announced in any capacity, but as we're 
dropping Python2 support in the next release, you may submit patches containing 
Python3 code without any requirement of providing some Python2 backwards 
compatibility.

The compilation tests also failed as we're using Python2 there as well. I'm 
currently working on a fix for these tests.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: 
https://www.bobbybruce.net


On Wed, Oct 7, 2020 at 11:49 PM jenkins-no-reply--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
See 

[gem5-dev] Re: Build failed in Jenkins: Nightly #91

[Giacomo Travaglini via gem5-dev]

Hi all,

I had the same issue. The problem in my case was in scons, which was selecting 
python2 when building gem5 disregarding my python3 virtualenv

$less `which scons`
#! /usr/bin/python

And /usr/bin/python was linked to python2.7.

So the available solutions are:


  *   Installing a newer scons version with

#!/usr/bin/env python


  *   changing the symbolic link,
  *   modify the shebang of the preinstalled one,
  *   CL selection of the scons interpreter:

alias scons=python `which scons`

Kind Regards

Giacomo

From: Jieming Yin via gem5-dev 
Sent: 09 October 2020 02:43
To: Poremba, Matthew 
Cc: gem5 Developer List ; Jieming Yin 
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

Hi Matt,

My workaround is to do it in a python2 manner:

class SEWorkload(Workload):
type = 'SEWorkload'
__metaclass__ = SEWorkloadMeta

I have the same syntax error because I am running the gem5-gcn docker, and I 
have both python2 and python3 installed. But I don't really know how to fix it, 
it seems python2 is used sometimes.

Jieming

On Thu, Oct 8, 2020 at 7:43 PM Bobby Bruce via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Hey Matt,

Before the nightly tests were run on Jenkins server which was an Ubuntu 18.04 
machine with Python2.

The nightly tests will now run using our Ubuntu 20.04 docker image: 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies
 (Dockerfile source: 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile).

So, to compile gem5.opt for the ARM ISA, the nightly will use:

```
docker run -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) --rm 
gcr.io/gem5-test/ubuntu-20.04_all-dependencies
 scons build/ARM/gem5.opt
```

I'm going to guess you probably still have Python2 somewhere on your machine 
and it's using it during the compilation. I'll setup some tests on my end and 
see if I can recreate this problem. I _think_ right now we only test in 
environments that either have only Python2 or have only Python3, so we should 
probably have some tests to check what happens if someone has both.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Oct 8, 2020 at 4:10 PM Poremba, Matthew 
mailto:matthew.pore...@amd.com>> wrote:

[AMD Public Use]

Hi Bobby,


What is/was the fix for this issue? I also cannot build even though I have 
python 3.6 installed (via apt-get on Ubuntu 20.04).  I am manually passing 
python3-config to scons but I’m getting a syntax error when it sees the 
metaclass keyword.


-Matt

From: Bobby Bruce via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: Thursday, October 8, 2020 3:19 PM
To: gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Bobby Bruce mailto:bbr...@ucdavis.edu>>
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #91

[CAUTION: External Email]
Hey all,

The source of this issue is that our Jenkin's server was using Python2, and a 
commit was merged which utilized some Python3 exclusive features: 
https://gem5-review.googlesource.com/c/public/gem5/+/33900

We are going to drop support for Python2 in the next release, so I've upgraded 
our nightly tests to use Python3. They should pass tonight.

I'm unsure if this has been officially announced in any capacity, but as we're 
dropping Python2 support in the next release, you may submit patches containing 
Python3 code without any requirement of providing some Python2 backwards 
compatibility.

The compilation tests also failed as we're using Python2 there as well. I'm 
currently working on a fix for these tests.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: 
https://www.bobbybruce.net


On Wed, Oct 7, 2020 at 11:49 PM jenkins-no-reply--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
See 
>

Changes:

[giacomo.travaglini] 

[gem5-dev] Re: Register bank abstraction

[Giacomo Travaglini via gem5-dev]

This looks great Gabe! Just so you know, there is already something (old) on 
review:

https://gem5-review.googlesource.com/c/public/gem5/+/10805/3

Giacomo

From: Gabe Black via gem5-dev 
Sent: 08 October 2020 13:59
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] Register bank abstraction

Hey folks! I've been looking at some device models recently, both to fix them 
and to develop them, and I've seen a lot of boilerplate code which tries to 
figure out what size of data to extract from the packet, how to map that to 
registers, sometimes handling accesses that aren't on register boundaries, 
sometimes handling partial register writes/reads, etc. It's a real mess much of 
the time, and I think people usually write some code that's stretched 
jst far enough to cover the way, for instance, a Linux kernel driver 
pokes at their device.

To simplify that boiler-plate and to make device models significantly more 
robust in general, I thought it would be a good idea to add a RegisterBank 
abstraction which collects a contiguous bunch of registers together. It figures 
out what registers are touched by an access, and divies up the access to send 
the right data to the right registers, aligned to their base offset and 
expanded to their full size. The registers themselves by default act as dumb 
storage locations, but it's easy to add callbacks which let them implement 
whatever behavior they need to on reads or writes, or to mark some/all bits as 
read only. Partial reads/writes are handled automatically with masking and 
read/modify/write operations for reads, but that can be overridden too. The 
registers can be different sizes, have no alignment requirements, and can have 
arbitrary endianness, although the will have a default based on the settings of 
their containing RegisterBank.

I have this written up, and with the very VERY limited testing I've done so far 
it seems to work. I think tomorrow I'll continue working on a unit test, and 
you should hopefully see a review in the not too distant future.

Suggestions welcome, mostly I wanted to give people the 10 second elevator 
pitch before tossing another review on the pile!

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: MMU object vs. DTB and ITB

[Giacomo Travaglini via gem5-dev]

Hey Jason,

I have just posted the patchset:

https://gem5-review.googlesource.com/c/public/gem5/+/34975/1

Supporting a multi-level TLB design was actually the reason why I started 
implementing this.
I am not at that point yet, but I believe we are getting closer now, having a 
MMU hiding the TLB hierarchy to the rest of the cpu code.

The remaining thing after this patches would be to move most TLB methods to the 
MMU class and to make the TLB a simple passive translation cache. That will 
allow us to stack them in any way we want

Giacomo

From: Jason Lowe-Power via gem5-dev 
Sent: 21 September 2020 16:02
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Re: MMU object vs. DTB and ITB

We (well, mostly Ayaz) have also been looking at this interface. We've been 
thinking more about x86 and RISC-V, but would also like to be kept up to date!

We were also thinking that many of the TLB/MMU concepts are shared between ISAs 
(or are microarchitecture details). So, it would be nice to be able to use the 
same multi-level TLB design for any ISA similar to how we can use caches for 
any ISA. I'm not sure if this is something that's enabled by your changes, 
Giacomo, or if it's something others think is important.

Cheers,
Jason

On Mon, Sep 21, 2020 at 4:06 AM Gabe Black via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
Oh, nice. I got sidetracked with some other things I wanted to rearrange first, 
so I haven't actually started on the MMU part :-). Please add me as a reviewer!

Gabe

On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini 
mailto:giacomo.travagl...@arm.com>> wrote:
Hi  Gabe, I am actually about to post the same patchset (which is: removing the 
TLB from the CPU interface and make it interface with an MMU instead)

Giacomo

From: Gabe Black via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: 20 September 2020 04:44
To: gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Gabe Black mailto:gabebl...@google.com>>
Subject: [gem5-dev] Re: MMU object vs. DTB and ITB

Oh, this will also absorb multilevel TLBs too, like how ARM has second level 
translation in some cases. This isn't really implemented in x86, but could also 
be used for it's multilevel translation in SVM and VT's nested page table 
schemes.

Gabe

On Sat, Sep 19, 2020 at 8:25 PM Gabe Black 
mailto:gabebl...@google.com>> wrote:
Hi folks. I've been thinking about how to rework the 
scanning-through-page-translation thing we currently do when translating a 
region of addresses through both the ITB and DTB. We currently do that one page 
at a time by trying one, and then the other. That requires knowing what "the" 
page size is, which introduces a dependence on the ISA and also constraints 
things to a single page size.

One improvement that I think makes sense is to instead use an approach where 
you'd ask for a translation for a region and let whatever is translating for 
you decide how to break things up. Then it can use a single page size, the size 
of whatever the mapping is, a single byte, etc., as it sees fit without there 
ever needing to be a particular page size. This would fit mostly nicely with 
the idea of a range based for loop or generator object.

One problem with this approach is how we try one TLB and then the other if we 
can't get a translation. With a range based for loop, there isn't a good way 
that I'm aware of to iterate over two different objects at the same time, and 
also there wouldn't be any coordination between the TLBs. For instance, what 
should happen in both have a translation? Or if they're to the same place, 
who's idea of the size of the step takes precedence?

That led me to the idea of merging the TLBs into a single object called the 
MMU. This fits pretty well with the structure of actual hardware, and would 
also absorb the "UnifiedTLB" concept which was added to the CPU, since the 
structure of the TLBs would no longer be visible to the CPU.

I think this makes a lot of sense and will probably take a stab at it this 
weekend, but since it's a structural shift that will be fairly visible in a lot 
of places I wanted to let everybody know a little ahead of time in case there 
are any big concerns.

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to 
gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents 

[gem5-dev] Re: MMU object vs. DTB and ITB

[Giacomo Travaglini via gem5-dev]

Hi  Gabe, I am actually about to post the same patchset (which is: removing the 
TLB from the CPU interface and make it interface with an MMU instead)

Giacomo

From: Gabe Black via gem5-dev 
Sent: 20 September 2020 04:44
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] Re: MMU object vs. DTB and ITB

Oh, this will also absorb multilevel TLBs too, like how ARM has second level 
translation in some cases. This isn't really implemented in x86, but could also 
be used for it's multilevel translation in SVM and VT's nested page table 
schemes.

Gabe

On Sat, Sep 19, 2020 at 8:25 PM Gabe Black 
mailto:gabebl...@google.com>> wrote:
Hi folks. I've been thinking about how to rework the 
scanning-through-page-translation thing we currently do when translating a 
region of addresses through both the ITB and DTB. We currently do that one page 
at a time by trying one, and then the other. That requires knowing what "the" 
page size is, which introduces a dependence on the ISA and also constraints 
things to a single page size.

One improvement that I think makes sense is to instead use an approach where 
you'd ask for a translation for a region and let whatever is translating for 
you decide how to break things up. Then it can use a single page size, the size 
of whatever the mapping is, a single byte, etc., as it sees fit without there 
ever needing to be a particular page size. This would fit mostly nicely with 
the idea of a range based for loop or generator object.

One problem with this approach is how we try one TLB and then the other if we 
can't get a translation. With a range based for loop, there isn't a good way 
that I'm aware of to iterate over two different objects at the same time, and 
also there wouldn't be any coordination between the TLBs. For instance, what 
should happen in both have a translation? Or if they're to the same place, 
who's idea of the size of the step takes precedence?

That led me to the idea of merging the TLBs into a single object called the 
MMU. This fits pretty well with the structure of actual hardware, and would 
also absorb the "UnifiedTLB" concept which was added to the CPU, since the 
structure of the TLBs would no longer be visible to the CPU.

I think this makes a lot of sense and will probably take a stab at it this 
weekend, but since it's a structural shift that will be fairly visible in a lot 
of places I wanted to let everybody know a little ahead of time in case there 
are any big concerns.

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] testlib dumping execution time for every testcase

[Giacomo Travaglini via gem5-dev]

Hi devs,

We've posted a patchset which allows us to dump the execution time of every 
testcase during kokoro runs.

https://gem5-review.googlesource.com/c/public/gem5/+/32653/1

This will make it possible for us to track performance regressions before a 
commit is merged, hence preventing slowdowns in our simulations.

Feel free to review the patches; further info can be found at 
https://gem5.atlassian.net/browse/GEM5-548

Kind Regards

Giacomo

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: The Nightly Build system is now Live (Compiler tests too!)

[Giacomo Travaglini via gem5-dev]

Thanks Bobby and Mike!

These are amazing news

Giacomo

From: Bobby Bruce via gem5-dev 
Sent: 27 July 2020 19:55
To: gem5 Developer List 
Cc: Bobby Bruce 
Subject: [gem5-dev] The Nightly Build system is now Live (Compiler tests too!)

Dear all,

After some tinkering, we now have a nightly build system deployed, run from our 
Jenkins: https://jenkins.gem5.org. If I've set up the permissions correctly, 
everyone should be able to see the status of all our builds from there. Please 
note, at the time of writing, we're still experimenting with other 
testing/building setups, so there may be builds there that I haven't explained 
in this email. These can be ignored.

Right now, the Nightly Builds compile the NULL, ARM, MIPS, POWER, RISCV, SPARC, 
and X86 ".opt" variants of gem5, run the unit tests (those executed via `scons 
build/null/unittests.opt`), and the "long" testlib regression tests (those 
executed via `scons ./main.py run --length long` from the `tests` directory) on 
the gem5 develop branch. In order to test that our email provider is 
functioning correctly, I've set this up to send an email to the gem5-dev 
mailing list on success or failure, though once I've confirmed the email 
notifications are working correctly I'll switch this to send on failure only.

The nightly builds will execute every day at 11PM PST (6AM UTC). They take 
around 6 to 7 hours to complete, therefore normally finishing around 6 to 7 AM 
PST (1PM to 2PM UTC). The email sent on the failure will list the commits 
included since the last run (in addition to the stdout/stderr logs, and a link 
to an archive of the `test/.testing-results` directory) which should help us 
narrow down any cause-of-failure.

In addition to the Nightly Builds, there are also Compile Tests, which I've 
setup to run every Wednesday. These take roughly 24 hours to complete in our 
current setups, so expect results on Thursdays. The Compiler Tests simply run 
the `./util/compiler-tests.sh` script on the develop branch. In short, these 
run all variants of gem5, ".opt" and '.fast", across all major versions of our 
supported compilers (not a complete cross product, but decent coverage -- 
please see the script if you want to know exactly what's run).

That's pretty much it for now. We've got plans to expand what's tested in the 
near future: running more tests, more frequently, as well as improve testing 
for gem5 in general. I hope this email has given a decent overview of what's 
going on, but please don't hesitate to get in contact with me if you have any 
questions.

I'd also like to take this opportunity to thank Mike Upton for helping us set 
up the Jenkins server and deal with all the teething problems. His assistance 
is much appreciated.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: bug squashing renamed pinned registers in o3?

[Giacomo Travaglini via gem5-dev]

Thanks Gabe,

Please let me know if you can reproduce the problem with the mentioned patch. 
If that’s the case, we should open a JIRA ticket so that I can have a look at 
that

Giacomo

From: Gabe Black 
Sent: 25 June 2020 05:28
To: Giacomo Travaglini 
Cc: gem5 Developer List ; Weiping Liao 
; Earl Ou ; Yu-hsin Wang 

Subject: Re: [gem5-dev] bug squashing renamed pinned registers in o3?

Hi Giacomo, thanks for your reply. To answer your questions, it looks like no 
for 1 (unless my grep was bad), and checkpoint save/restore for 2. I think 
we've been able to reproduce this problem much more easily with older versions 
of gem5, likely missing that fix, although I think we may have also seen it 
with newer versions. I've only been looking at it recently and was looking for 
the easiest way to reproduce, so I've only directly tried the older version.

I've cc-ed some Google folks that can hopefully share more details and confirm 
if they've seen this problem on a branch which does have the CL you mentioned 
in 1.

To Google folks, we should cherry-pick that CL into our branch to at least make 
the problem less common. We should have it already in our rebase branch, since 
it looks like it went in upstream in early March.

Gabe

On Wed, Jun 24, 2020 at 2:18 AM Giacomo Travaglini 
mailto:giacomo.travagl...@arm.com>> wrote:
Hi Gabe,

We are encountering the same problem on top of develop but it’s still worth 
asking:


  1.  Do you have https://gem5-review.googlesource.com/c/public/gem5/+/25743 ?
  2.  Are you encountering this in a simulation which is using a CPU switch or 
checkpoint save/restore

Kind Regards

Giacomo

From: Gabe Black via gem5-dev mailto:gem5-dev@gem5.org>>
Sent: 23 June 2020 06:24
To: gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Gabe Black mailto:gabebl...@google.com>>
Subject: [gem5-dev] bug squashing renamed pinned registers in o3?

Hi folks, specifically ARM folks. We've been seeing a problem with O3 where 
when switching vector register renaming modes (full vectors vs vector 
elements), the CPU checks its bookkeeping and finds that a vector register is 
missing, ie with no instructions in flight, the free list has one fewer 
register in it than the difference between the total number of physical vector 
registers, and the number that should be taken up with architectural state.

This problem has been somewhat difficult to reproduce, although we can get it 
to happen, and it does happen often enough that it's been a real pain for us. 
Given that it's not very easy to get it to happen which makes it hard to 
observe, I've been digging around in the code trying to understand what all the 
pieces do and why the bookkeeping might be wrong.

The most promising thing I've found so far is that when squashing, the rename 
stage looks at its history and rolls back renames for squashed instructions. 
Some registers are fixed and not renamed, so rolling back those would be 
pointless. Also those registers should not go on the free list.

The way O3 detects those special registers is that they have the same index 
before and after renaming. If that is the case, O3 ignores those entries, and 
does not roll them back or mark their target as free.

This check is slightly out of date though, since with the recently added pinned 
register writes, a register will be renamed to the same thing several times in 
a row. When these entries are checked, they will not be rolled back (I think 
this part is still fine), but they will also not be marked as free.

This isn't exactly a smoking gun though, since the more I think about it, the 
more I think this may actually be ok. If one of the later writes is squashed, 
the register isn't "free" since it still holds the (partially written) 
architectural state. If everything gets squashed all the way back to the first 
entry which did change what register to use, then the slightly outdated check 
won't trigger and things should be freed up correctly (I think).

This code is mostly new to me though, so I'm not super confident making any 
grand declarations about what's going on. All the pieces seem to be there 
though, which makes me very suspicious.

Maybe something goes wrong if the right number of writes never happens because 
later writers get squashed?

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev 

[gem5-dev] Re: bug squashing renamed pinned registers in o3?

[Giacomo Travaglini via gem5-dev]

Hi Gabe,

We are encountering the same problem on top of develop but it’s still worth 
asking:


  1.  Do you have https://gem5-review.googlesource.com/c/public/gem5/+/25743 ?
  2.  Are you encountering this in a simulation which is using a CPU switch or 
checkpoint save/restore

Kind Regards

Giacomo

From: Gabe Black via gem5-dev 
Sent: 23 June 2020 06:24
To: gem5 Developer List 
Cc: Gabe Black 
Subject: [gem5-dev] bug squashing renamed pinned registers in o3?

Hi folks, specifically ARM folks. We've been seeing a problem with O3 where 
when switching vector register renaming modes (full vectors vs vector 
elements), the CPU checks its bookkeeping and finds that a vector register is 
missing, ie with no instructions in flight, the free list has one fewer 
register in it than the difference between the total number of physical vector 
registers, and the number that should be taken up with architectural state.

This problem has been somewhat difficult to reproduce, although we can get it 
to happen, and it does happen often enough that it's been a real pain for us. 
Given that it's not very easy to get it to happen which makes it hard to 
observe, I've been digging around in the code trying to understand what all the 
pieces do and why the bookkeeping might be wrong.

The most promising thing I've found so far is that when squashing, the rename 
stage looks at its history and rolls back renames for squashed instructions. 
Some registers are fixed and not renamed, so rolling back those would be 
pointless. Also those registers should not go on the free list.

The way O3 detects those special registers is that they have the same index 
before and after renaming. If that is the case, O3 ignores those entries, and 
does not roll them back or mark their target as free.

This check is slightly out of date though, since with the recently added pinned 
register writes, a register will be renamed to the same thing several times in 
a row. When these entries are checked, they will not be rolled back (I think 
this part is still fine), but they will also not be marked as free.

This isn't exactly a smoking gun though, since the more I think about it, the 
more I think this may actually be ok. If one of the later writes is squashed, 
the register isn't "free" since it still holds the (partially written) 
architectural state. If everything gets squashed all the way back to the first 
entry which did change what register to use, then the slightly outdated check 
won't trigger and things should be freed up correctly (I think).

This code is mostly new to me though, so I'm not super confident making any 
grand declarations about what's going on. All the pieces seem to be there 
though, which makes me very suspicious.

Maybe something goes wrong if the right number of writes never happens because 
later writers get squashed?

Gabe
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse

[Giacomo Travaglini via gem5-dev]

I agree with Daniel and Ciro; it's difficult/annoying to navigate through old 
unanswered emails and I presume nobody does that at the moment.
Most of the time if your email doesn't get a quick response as soon as it gets 
posted, you can forget about getting some help as time passes; there is a short 
window and you really have to hope someone flagged your email or got some time 
to address your problem.

I wouldn't use JIRA to be honest for asking questions; that's beyond the scope 
of JIRA and it would be chaotic to mix Bug Reports, Improvement tasks with 
normal questions (like: I cannot build gem5 on my machine, or does anyone know 
how this works)

Giacomo


-Original Message-
From: Ciro Santilli via gem5-dev 
Sent: 10 June 2020 09:21
To: gem5 Developer List 
Cc: Ciro Santilli 
Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with 
Discourse

I would just use JIRA. But after that, Discourse is the second best. And 
anything is better than a mailing list :-) 
From: Jason Lowe-Power via gem5-dev 
Sent: Tuesday, June 9, 2020 11:40 PM
To: gem5 Developer List 
Cc: gem5 users mailing list ; Jason Lowe-Power 

Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with 
Discourse

+1 for Discourse :).

Just to give a bit more context: I'm also trying to find a good forum for 
community engagement during my online Learning gem5 class this summer. I would 
like to find a platform that could be used generally for my class this summer, 
future iterations of the class, and general gem5 questions, as I believe there 
will be significant overlap between these groups.

Other potential options that IMO have more cons than pros when compared to
Discourse:
- Slack/Teams/etc.
- gitter.im
- stackoverflow

That said, we're open to suggestions :). Our goal is to create the most 
welcoming and inclusive environment possible. We'll go where our users are!

Cheers,
Jason

On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> In an effort to better support the gem5 community, there has been a
> suggestion that we drop the gem5-users mailing list and replace it
> with Discourse, https://www.discourse.org/about, a web-based
> discussion platform. I'm writing this email to propose this to the
> community and ask for feedback on the matter.
>
> We have noticed that using mailing lists as our primary communication
> platform is problematic. Sending an email to a list can be daunting
> experience, requiring an etiquette many are not accustom to. I'm sure
> I'm not the only one who feels like they are unduly bothering a large
> number of people when posting to a list (like I'm doing right now :)
> ). This is, of course, an unfortunate hurdle for many to get over when
> they encounter problems using gem5, particularly those new to the
> project. I've come to believe mailing lists are simply not a very good
> technology for fostering community engagement and helping those who are 
> running into difficulties.
> Mailing lists are also difficult to search, and lack proper formatting
> mechanisms to neatly display attributes such as code and output logs.
>
> Looking around at alternative technologies available, Discourse
> appears to be a suitable replacement. For those unaware, Discourse is
> (essentially) a revamp of messaging forums. It is an increasingly
> popular platform for users and developers in open source projects to
> communicate with one another (see LLVM's discourse as an example:
> https://llvm.discourse.group ).
> All-in-all, I think it's a well-designed product and contains all the
> features we'd expect and need to get our work done. I can see no
> immediate downsides to using it, though feedback from the community on
> the matter would be greatly appreciated, particularly from those who
> have used Discourse before. Dissenting opinions on the whole idea of
> moving away from the gem5-user's mailing list are also welcome.
>
> So, let me know what you think! :)
>
> Please note, regardless as to any decision made, we will continue the
> use of the gem5-dev mailing list for technical discussions for the
> foreseeable future.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an
> email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to 
gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to 
gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any 

[gem5-dev] Re: New ARM patches on staging branch

[Giacomo Travaglini via gem5-dev]

Hi Jason,

As you can see from the ticket below:

https://gem5.atlassian.net/browse/GEM5-611

It won’t be possible otherwise to run gem5-ARM in KVM mode with the in source 
bootloader.
It is not a compiler fix. Considering the are several people using KVM, I 
consider this critical and would personally
vote to merge them in the gem5-20 branch.

Giacomo

From: Jason Lowe-Power 
Sent: 28 May 2020 15:49
To: gem5 Developer List ; Giacomo Travaglini 

Cc: Bobby Bruce 
Subject: New ARM patches on staging branch

Hey Giacomo,

I noticed you just pushed two change to the staging branch:
https://gem5-review.googlesource.com/c/public/gem5/+/29613
https://gem5-review.googlesource.com/c/public/gem5/+/29612

We were going to merge the staging into develop and release this morning (i.e., 
it a couple of hours). Are these patches *required* for gem5-20, or can they go 
into develop instead?

Said another way, in the past few days, we've only been pushing compiler fixes 
to the staging branch. Are these compiler fixes, or other bugs?

I'd *really* like to get this release out ASAP. Could you describe the severity 
of the problem that these fixes pertain to?

Thanks,
Jason
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: New ARM patches on staging branch

[Giacomo Travaglini via gem5-dev]

Thanks Jason, I will ping other Arm people

Giacomo

From: Jason Lowe-Power 
Sent: 28 May 2020 16:14
To: Giacomo Travaglini 
Cc: gem5 Developer List ; Bobby Bruce 
Subject: Re: New ARM patches on staging branch

Hi Giacomo,

Thanks for letting us know. I've gone ahead and hit maintainer +1 on them so we 
can get kokoro's results ASAP. Can you find someone to review them so we can 
merge them today and release this afternoon (they look fine to me, but I have 
never looked at this code before ;)).

Thanks!
Jason


On Thu, May 28, 2020 at 7:56 AM Giacomo Travaglini 
mailto:giacomo.travagl...@arm.com>> wrote:
Hi Jason,

As you can see from the ticket below:

https://gem5.atlassian.net/browse/GEM5-611

It won’t be possible otherwise to run gem5-ARM in KVM mode with the in source 
bootloader.
It is not a compiler fix. Considering the are several people using KVM, I 
consider this critical and would personally
vote to merge them in the gem5-20 branch.

Giacomo

From: Jason Lowe-Power mailto:power...@gmail.com>>
Sent: 28 May 2020 15:49
To: gem5 Developer List mailto:gem5-dev@gem5.org>>; Giacomo 
Travaglini mailto:giacomo.travagl...@arm.com>>
Cc: Bobby Bruce mailto:bbr...@ucdavis.edu>>
Subject: New ARM patches on staging branch

Hey Giacomo,

I noticed you just pushed two change to the staging branch:
https://gem5-review.googlesource.com/c/public/gem5/+/29613
https://gem5-review.googlesource.com/c/public/gem5/+/29612

We were going to merge the staging into develop and release this morning (i.e., 
it a couple of hours). Are these patches *required* for gem5-20, or can they go 
into develop instead?

Said another way, in the past few days, we've only been pushing compiler fixes 
to the staging branch. Are these compiler fixes, or other bugs?

I'd *really* like to get this release out ASAP. Could you describe the severity 
of the problem that these fixes pertain to?

Thanks,
Jason
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] GCB status

[Giacomo Travaglini via gem5-dev]

Hi Bobby,

It seems like we are just using kokoro now as CI platform. Is this intended?
(What happened with GCB?)

Kind Regards

Giacomo
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s