Re: [gem5-dev] Mailing list archives non-public

[Bjoern A. Zeeb]

On 7 Apr 2020, at 8:36, Bobby Bruce wrote:


The gem5-dev mailing list archives can be found here:
https://www.mail-archive.com/gem5-dev@gem5.org/



Well then there is even less reason why the official once at 
http://m5sim.org/mailman/listinfo/gem5-dev (see signature) are closed if 
there are public copies otherwise.


/bz



On Tue, Apr 7, 2020 at 1:27 AM Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:


Hi,

what’s the reason that mailing list archives for open source 
research

projects are non-public?
It’s really hard to reference gem5-dev discussions that way.


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Mailing list archives non-public

[Bjoern A. Zeeb]

Hi,

what’s the reason that mailing list archives for open source research 
projects are non-public?

It’s really hard to reference gem5-dev discussions that way.


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]

[Bjoern A. Zeeb]

On 16 Dec 2019, at 19:50, Jason Lowe-Power wrote:

I think master should be development.
I think gem5 should “”””release once per year (a 
release is not what you described the stable branch would be).



I kept thinking ... feel free to ignore my 50 cents below:

(i) I don’t want to fight the rest of the world treating git one way, 
where development is master.
(ii) I am still not sure how “stable” will be screwed up 1 or 3 
times a year if you “merge” “development” over a “stable” 
branch.  If “stable” is “master” and the next pull accidentally 
ends on top of it it’ll be in conflict hell.  Do you plan to point 
HEAD to development instead?  Your plan very much sounds nice (fast 
forward) for the one having no changes in “stable” but horrible for 
anyone doing their work there.
(iii) I am still not sure how referencing “one stable branch” can be 
named in a paper if you need a git hash or a date as well (sounds like 
CVS times).  Even if you’d provide tags, any bugfix merges will still 
not be the same code.  And in the end local modifications will mean it 
wasn’t gem5 “stable” but a local tree of a gem5 stable + changes 
(which also should be published).


Like many I’ve seen plenty of research projects being done on a 
(stale) “stable” branch and once the research was done the work was 
forgotten or at best tarballed away or a “dead repo somewhere” and 
basically lost.  I have seen few people doing their engineering for the 
research on development branch and then actually merging to stable and 
that’s usually the projects which are in use, cited often, look for 
something beyond a paper, ..  Strangely this is also how release 
engineering usually seems to work.


One will need to branch for once own research anyway, be it from master, 
development, or stable.  If you work directly on master you simply screw 
yourself or you don’t use git.


One will need to be able to diff ones own work to a “parent” in 
order to extract changes to be pushed to gem5 for upstreaming.  If I 
work on a stable branch which gets a major upgrade in between, I need to 
solve those changes and conflicts first and then again against 
development when porting forward (which usually is a lot harder than 
back-porting)?



I think gem5’s interest should be to make research easy and to engage 
the community to make their changes upstreamable so that the work is not 
lost but integrated and available for many.  The big companies named do 
a great job of doing this, but how much 3rd party research community 
actually comes back into the tree?


If I were to do gem5 research I’d do for 1 project (if you do multiple 
in parallel you do more sophisticated naming of multiple branches ;-):


(a) branch development (ideally “master”) -> bz_master & do 
continuous changes and pull/merge regularly from upstream.
(b) upstream all changes not needing “confidentiality” until 
publication (easy given they are based off the development branch).
(c) pick the latest stable branch (which kind of implies there is a 
release structure again of say stable/20200401 or whatever name you give 
it.
(d) make a branch if (c) bz_stable_20200401 and backport my changes to 
that.   This is the branch I might be stuck with for 3-6 years for my 
research (think of a PhD lifetime in various parts of the world).  In a 
real world I’ll probably have a bz_stable_20201001 by the time I 
finally get to the point when the 1st bit of engineering is done and I 
can write up a first paper.  Either a forward port stable->stable or a 
backport to a different stable;  the first real pain unless you chose 
wisely and your development branch basically matches your new stable 
branch at that point.
(e) keep the cycle alive with back porting becoming harder and harder as 
the years go by.

(f) publish and upstream rest of the changes.
(g) go through the “review process, refine changes, ...”
(h) Say paper 1/2/3.  Peer reviewed.   Work upstreamed to community, 
reviewed. Found mistake from 1st paper during that process, updated the 
results since. Being honest ;-)



While your question of “what will be master?” seems important, the 
question you are asking is “do we want to be using the SCM system 
differently than most of the world raising the bar to entry just an 
extra bit?”


If I look up there, I, as a developer and user, have totally different 
things to sort out than the default of a branch.


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] name for fake linux

[Bjoern A. Zeeb]

On 10 Dec 2019, at 17:14, Jason Lowe-Power wrote:


One option is gem5Linux since it is kind of "gem5 flavored" Linux.

SELinux isn't that bad. I doubt too many people will think that gem5
is implementing a secure linux ;).

Other options:
EmuLinux (surprisingly doesn't return anything on Google except qemu)
SEModeLinux
SEOnlyLinux

After thinking about it for a few minutes, I don't think the name is
*too* important. I'd be ok with anything :)


I was going to suggest making it a Suffix:  LinuxSE, I’d assume 
there’d be a FreeBSDSE and others as well.  Now, I don’t know what 
the people in Sweden will think of that ;-)


Otherwise I’d spell it CaMelCaSe: SyscallEmuLinux, SyscallEmuFreeBSD, 
..  for a C++/Python class name that doesn’t sound too bad.


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Can X-Gerrit-MessageType be put into the subject?

[Bjoern A. Zeeb]

Hi,

following the gem5-dev emails is kind of hard by subject as you never 
know if a change was new and added, updated, or merged.  That 
information is in the headers but reading those is even worse.  If one 
splits the emails into different mail boxes doing that one loses track 
of the lifetime of a change and can’t nicely use a threaded view 
anymore as it is now split over multiple mailboxes.


Would it be possible to put the X-Gerrit-MessageType into the subject as 
well?


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Gem5 Full System Crashes

[Bjoern A. Zeeb]

On 3 Jun 2019, at 15:37, Stefan Waczynski wrote:


I also saw an error in the terminal output when booting with
AtomicSimpleCPU, but it did not seem to affect the booting process and
functionality for the Atomic model:
ACPI: Early table checksum verification disabled
ACPI BIOS Error (bug): A valid RSDP was not found 
(20160422/tbxfroot-243)


That is expected as the gem5 ACPI stub pretends to support ACPI but 
simply does not in any way.  I always assumed it was a “get around 
things mandating ACPI but happy to learn otherwise if they just find 
ACPI somehow exists”.



I am not sure what all your other (linux) crashes are;  last time I 
tried FS mode with FreeBSD (with patches) I found TLB and other issues;  
I still think nothing ever made it upstream (or the discussion was too 
tedious) but I am happy to dig things up again in case someone will find 
it valuable.


/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Cron /z/m5/regression/do-regression --scratch all

[Bjoern A. Zeeb]

On 27 May 2019, at 21:28, Cron Daemon wrote:

* 
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3: 
FAILED!
* 
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual: 
FAILED!
* 
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full: 
FAILED!
* 
build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: 
FAILED!
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer: 
FAILED!
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level: 
FAILED!
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory: 
FAILED!
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token: 
FAILED!
* 
build/X86/tests/opt/long/fs/10.linux-boot/x86/linux/pc-o3-timing: 
FAILED!
* 
build/X86/tests/opt/long/fs/10.linux-boot/x86/linux/pc-switcheroo-full: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: 
FAILED!
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple: 
CHANGED!

..
..
..
..  is there any interest in actually getting things to pass again or 
..?


I am mostly wondering, having watched this for a while now, in what 
state the current repo is in, and if anything is supposed to work or if 
the tests are out of date or ..?


It doesn’t leave people with a lot of confidence and given there is no 
updated stable branch anymore, you simply cannot afford keeping such a 
state for long.



/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] separating OS initialization from the System simobjects

[Bjoern A. Zeeb]

On 26 Aug 2017, at 20:11, Gabe Black wrote:

Hi folks. Currently OS initialization in FS mode is intimately tied to 
the
System simobjects, the objects which also act as a collection point 
for
simobjects which belong to a particular computer/system. I'm planning 
to
attempt to put together some CLs which will separate those two and 
make the
OS a separate object/concept which is applied to a system. That, 
combined
with some ideas I have for how processes are handled, will I think 
better

abstract the hardware from the software it's going to run and make how
processes and OSes are handled more symmetric, bringing SE mode and FS 
mode

closer together.

This is something I'm thinking of working on for fun on the side so I 
don't
know if or when it might be ready, but I figured I'd send out a heads 
up in

case somebody wants to voice an objection.


I’ve added (better) FreeBSD support next to Linux for X86_64, arm, and 
armv8.
I need to cleanup some code before I can submit them but it might help 
with
another (maybe not just second) system syndrome and give you some 
guidance on

what your abstraction might (should) also include.

I’ll try to look into getting some patches out the next 8 days.

/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3810: x86: adjust Walker::WalkerState::pageFault to not change mode

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3810/
---

Review request for Default.


Repository: gem5


Description
---

After http://repo.gem5.org/gem5/rev/47b4fcb10c11 it is possible to run into the 
assertion in src/cpu/o3/fetch.hh::finish() asserting the mode is Execute (which 
it seems no longer is).  Rather than adjusting the mode, revert to the old 
behaviour only setting it for fault generation but not altering it for the 
walker.


Diffs
-

  src/arch/x86/pagetable_walker.cc 63325e5b0a9d 

Diff: http://reviews.gem5.org/r/3810/diff/


Testing
---

The problematic code no longer triggers the panic and the OS in FS continues to 
boot.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: sim: fix build breakage in process.cc after b...

[Bjoern A. Zeeb]

changeset d0586994a10e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d0586994a10e
description:
sim: fix build breakage in process.cc after brandon@11801

Seeing build breakage after brandon@11801:

 [ CXX] X86/sim/process.cc -> .o build/X86/sim/process.cc:137:64:
error: field '_pid' is uninitialized when used here
[-Werror,-Wuninitialized] static_cast(new
ArchPageTable(name(), _pid, system)) : ^ 
build/X86/sim/process.cc:138:64:
error: field '_pid' is uninitialized when used here
[-Werror,-Wuninitialized] static_cast(new
FuncPageTable(name(), _pid))), ^ 2 errors generated.

Testing Done: Compiles now on FreeBSD 10 with clang.

Reviewed at http://reviews.gem5.org/r/3804/

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/sim/process.cc |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diffs (15 lines):

diff -r 30aada507f03 -r d0586994a10e src/sim/process.cc
--- a/src/sim/process.ccThu Feb 09 19:03:55 2017 -0500
+++ b/src/sim/process.ccThu Feb 09 19:03:58 2017 -0500
@@ -134,8 +134,9 @@
   useArchPT(params->useArchPT),
   kvmInSE(params->kvmInSE),
   pTable(useArchPT ?
-static_cast(new ArchPageTable(name(), _pid, system)) :
-static_cast(new FuncPageTable(name(), _pid))),
+static_cast(new ArchPageTable(name(), params->pid,
+system)) :
+static_cast(new FuncPageTable(name(), params->pid))),
   initVirtMem(system->getSystemPort(), this,
   SETranslatingPortProxy::Always),
   fd_array(make_shared>()),
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: dev: net/i8254xGBe add two more wakeup regist...

[Bjoern A. Zeeb]

changeset de0de48a2d1c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=de0de48a2d1c
description:
dev: net/i8254xGBe add two more wakeup registers to ignore

There are drivers writing to WUFC uncondtionally of anything.  In order 
to
not panic gem5 in these cases, ignore writes to WUFC and WUS as we do 
for
WUC.  Similarly return 0 (default reset value) on reads.

Testing Done: Booted in FS with such a driver revision which would
previously panic and now boots fine.

Reviewed at http://reviews.gem5.org/r/3791/

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/dev/net/i8254xGBe.cc  |  4 
 src/dev/net/i8254xGBe_defs.hh |  2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diffs (33 lines):

diff -r 61c625151d9a -r de0de48a2d1c src/dev/net/i8254xGBe.cc
--- a/src/dev/net/i8254xGBe.cc  Thu Feb 09 18:54:28 2017 -0500
+++ b/src/dev/net/i8254xGBe.cc  Thu Feb 09 18:59:55 2017 -0500
@@ -240,6 +240,8 @@
 pkt->set(regs.pba());
 break;
   case REG_WUC:
+  case REG_WUFC:
+  case REG_WUS:
   case REG_LEDCTL:
 pkt->set(0); // We don't care, so just return 0
 break;
@@ -546,6 +548,8 @@
 regs.pba.txa(64 - regs.pba.rxa());
 break;
   case REG_WUC:
+  case REG_WUFC:
+  case REG_WUS:
   case REG_LEDCTL:
   case REG_FCAL:
   case REG_FCAH:
diff -r 61c625151d9a -r de0de48a2d1c src/dev/net/i8254xGBe_defs.hh
--- a/src/dev/net/i8254xGBe_defs.hh Thu Feb 09 18:54:28 2017 -0500
+++ b/src/dev/net/i8254xGBe_defs.hh Thu Feb 09 18:59:55 2017 -0500
@@ -94,6 +94,8 @@
 const uint32_t REG_VFTA = 0x05600;
 
 const uint32_t REG_WUC  = 0x05800;
+const uint32_t REG_WUFC = 0x05808;
+const uint32_t REG_WUS  = 0x05810;
 const uint32_t REG_MANC = 0x05820;
 const uint32_t REG_SWSM = 0x05B50;
 const uint32_t REG_FWSM = 0x05B54;
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: arm: AArch64 report cache size correctly when...

[Bjoern A. Zeeb]

changeset 61c625151d9a in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=61c625151d9a
description:
arm: AArch64 report cache size correctly when reading CTR_EL0

Trying to read MISCREG_CTR_EL0 on AArch64 returned 0 as is was not
implmemented.  With that an operating system relying on the cache line
sizes reported in order to manage the caches would (a) panic given the
returned value 0 is not valid (high bit is RES1) or (b) worst case would
assume a cache line size of 4 doing a tremendous amount of extra
instruction work (including fetching).  Return the same values as for 
ARMv7
as the fields seem to be the same, or RES0/1 seem to be reported
accordingly for AArch64

In collaboration with:  Andrew Turner

Testing Done: Checked on FreeBSD boots with extra printfs;  also 
observed a
reduction of a factor of about 10 in instruction fetches for a simple
micro-test.

Reviewed at http://reviews.gem5.org/r/3667/

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/arch/arm/isa.cc |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diffs (13 lines):

diff -r f254d8a17da9 -r 61c625151d9a src/arch/arm/isa.cc
--- a/src/arch/arm/isa.cc   Tue Feb 07 15:28:33 2017 +
+++ b/src/arch/arm/isa.cc   Thu Feb 09 18:54:28 2017 -0500
@@ -594,7 +594,8 @@
 warn_once("The ccsidr register isn't implemented and "
 "always reads as 0.\n");
 break;
-  case MISCREG_CTR:
+  case MISCREG_CTR: // AArch32, ARMv7, top bit set
+  case MISCREG_CTR_EL0: // AArch64
 {
 //all caches have the same line size in gem5
 //4 byte words in ARM
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: sim: Patch to fix the statfs build

[Bjoern A. Zeeb]

changeset 30aada507f03 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30aada507f03
description:
sim: Patch to fix the statfs build

See developers mailing list.  Trying to unbreak statfs.

Testing Done:
Builds on FreeBSD now.

Reviewed at http://reviews.gem5.org/r/3803/

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/sim/syscall_emul.hh |  26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diffs (54 lines):

diff -r 83677ded6358 -r 30aada507f03 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Thu Feb 09 19:00:00 2017 -0500
+++ b/src/sim/syscall_emul.hh   Thu Feb 09 19:03:55 2017 -0500
@@ -70,6 +70,8 @@
 #include 
 #if (NO_STATFS == 0)
 #include 
+#else
+#include 
 #endif
 #include 
 #include 
@@ -527,21 +529,37 @@
 {
 TypedBufferArg tgt(addr);
 
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
-tgt->f_type = 0;
+tgt->f_type = TheISA::htog(host->f_type);
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+tgt->f_bsize = TheISA::htog(host->f_iosize);
 #else
-tgt->f_type = TheISA::htog(host->f_type);
+tgt->f_bsize = TheISA::htog(host->f_bsize);
 #endif
-tgt->f_bsize = TheISA::htog(host->f_bsize);
 tgt->f_blocks = TheISA::htog(host->f_blocks);
 tgt->f_bfree = TheISA::htog(host->f_bfree);
 tgt->f_bavail = TheISA::htog(host->f_bavail);
 tgt->f_files = TheISA::htog(host->f_files);
 tgt->f_ffree = TheISA::htog(host->f_ffree);
 memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+tgt->f_namelen = TheISA::htog(host->f_namemax);
+tgt->f_frsize = TheISA::htog(host->f_bsize);
+#elif defined(__APPLE__)
+tgt->f_namelen = 0;
+tgt->f_frsize = 0;
+#else
 tgt->f_namelen = TheISA::htog(host->f_namelen);
 tgt->f_frsize = TheISA::htog(host->f_frsize);
+#endif
+#if defined(__linux__)
 memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
+#else
+/*
+ * The fields are different sizes per OS. Don't bother with
+ * f_spare or f_reserved on non-Linux for now.
+ */
+memset(>f_spare, 0, sizeof(tgt->f_spare));
+#endif
 
 tgt.copyOut(mem);
 }
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

changeset 83677ded6358 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=83677ded6358
description:
scons: make build better on FreeBSD

Various changes we found needed to build gem5 successfully on
FreeBSD.

Reviewed at http://reviews.gem5.org/r/3378/

Signed-off-by: Jason Lowe-Power 

diffstat:

 SConstruct |  20 ++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diffs (51 lines):

diff -r de0de48a2d1c -r 83677ded6358 SConstruct
--- a/SConstructThu Feb 09 18:59:55 2017 -0500
+++ b/SConstructThu Feb 09 19:00:00 2017 -0500
@@ -655,6 +655,9 @@
  '-Wno-sign-compare', '-Wno-unused-parameter'])
 # We always compile using C++11
 main.Append(CXXFLAGS=['-std=c++11'])
+if sys.platform.startswith('freebsd'):
+main.Append(CCFLAGS=['-I/usr/local/include'])
+main.Append(CXXFLAGS=['-I/usr/local/include'])
 else:
 print termcap.Yellow + termcap.Bold + 'Error' + termcap.Normal,
 print "Don't know what compiler options to use for your compiler."
@@ -771,6 +774,10 @@
 main.Append(CXXFLAGS=['-stdlib=libc++'])
 main.Append(LIBS=['c++'])
 
+# On FreeBSD we need libthr.
+if sys.platform.startswith('freebsd'):
+main.Append(LIBS=['thr'])
+
 else:
 print termcap.Yellow + termcap.Bold + 'Error' + termcap.Normal,
 print "Don't know what compiler options to use for your compiler."
@@ -884,8 +891,12 @@
 # Check for 'timeout' from GNU coreutils. If present, regressions will
 # be run with a time limit. We require version 8.13 since we rely on
 # support for the '--foreground' option.
-timeout_lines = readCommand(['timeout', '--version'],
-exception='').splitlines()
+if sys.platform.startswith('freebsd'):
+timeout_lines = readCommand(['gtimeout', '--version'],
+exception='').splitlines()
+else:
+timeout_lines = readCommand(['timeout', '--version'],
+exception='').splitlines()
 # Get the first line and tokenize it
 timeout_version = timeout_lines[0].split() if timeout_lines else []
 main['TIMEOUT'] =  timeout_version and \
@@ -1083,6 +1094,11 @@
 if conf.CheckLibWithHeader(None, 'execinfo.h', 'C',
'backtrace_symbols_fd((void*)0, 0, 0);'):
 backtrace_impls.append("glibc")
+elif conf.CheckLibWithHeader('execinfo', 'execinfo.h', 'C',
+   'backtrace_symbols_fd((void*)0, 0, 0);'):
+# NetBSD and FreeBSD need libexecinfo.
+backtrace_impls.append("glibc")
+main.Append(LIBS=['execinfo'])
 
 if backtrace_impls[-1] == "none":
 default_backtrace_impl = "none"
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3808: mem: fix printing of 1st cache tags line

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3808/
---

Review request for Default.


Repository: gem5


Description
---

Rather than having the 1st line on the Log line and every other line on its 
own, add a new line to have a common format for all of them.  Makes parsing a 
lot easier.

Before:
1813979170500: system.l2cache: recvTimingReq tags:set: 0 block: 0 
state: f (M) valid: 1 writable: 1 readable: 1 dirty: 1 tag: fff3
set: 0 block: 1 state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 
tag: f9a3

After:
1813979170500: system.l2cache: recvTimingReq tags:
set: 0 block: 0 state: f (M) valid: 1 writable: 1 readable: 1 dirty: 1 
tag: fff3
set: 0 block: 1 state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 
tag: f9a3


Diffs
-

  src/mem/cache/cache.cc 63325e5b0a9d 

Diff: http://reviews.gem5.org/r/3808/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Can someone please commit these three?

[Bjoern A. Zeeb]

Hi,

getting these tiny things in and out of a tree is really helpful;  could 
someone please commit them?


http://reviews.gem5.org/r/3667/   (ARM, 3 months Ship it!)
http://reviews.gem5.org/r/3791/ (e1000)
http://reviews.gem5.org/r/3378/ (seems everyone is fine with it now)


Thanks,

Bjoern
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3804: sim: fix build breakage in process.cc after brandon@11801

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3804/
---

Review request for Default.


Repository: gem5


Description
---

Seeing build breakage after brandon@11801:

 [ CXX] X86/sim/process.cc -> .o 
build/X86/sim/process.cc:137:64: error: field '_pid' is uninitialized when used 
here [-Werror,-Wuninitialized]
static_cast(new ArchPageTable(name(), _pid, system)) :
   ^
build/X86/sim/process.cc:138:64: error: field '_pid' is uninitialized when used 
here [-Werror,-Wuninitialized]
static_cast(new FuncPageTable(name(), _pid))),
   ^
2 errors generated.


Diffs
-

  src/sim/process.cc 63325e5b0a9d 

Diff: http://reviews.gem5.org/r/3804/diff/


Testing
---

Compiles now on FreeBSD 10 with clang.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Bjoern A. Zeeb]

On 2 Feb 2017, at 16:31, Bjoern A. Zeeb wrote:

Hi,

OK, I updated the diff.  Can everyone please check if the diff from  
http://reviews.gem5.org/r/3803/  works for you now?



/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3803: sim: Patch to fix the statfs build

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3803/
---

Review request for Default.


Repository: gem5


Description
---

See developers mailing list.  Trying to unbreak statfs.


Diffs
-

  src/sim/syscall_emul.hh 63325e5b0a9d 

Diff: http://reviews.gem5.org/r/3803/diff/


Testing
---

Builds on FreeBSD now.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/
---

(Updated Feb. 3, 2017, 4:20 p.m.)


Review request for Default.


Changes
---

Update: adding the comment that libexecinfo is used on Net/FreeBSD


Repository: gem5


Description
---

scons: make build better on FreeBSD

Various changes we found needed to build gem5 successfully on
FreeBSD.


Diffs (updated)
-

  SConstruct 63325e5b0a9d 

Diff: http://reviews.gem5.org/r/3378/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Bjoern A. Zeeb]

On 1 Feb 2017, at 21:41, Matthias Jung wrote:

Moin,


on my MAC I run into the same issue:
http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt


When I use your patch I run into some other errors:

In file included from build/ARM/arch/arm/linux/process.cc:56:
build/ARM/sim/syscall_emul.hh:545:41: error: no member named 
'f_namemax' in 'statfs'

tgt->f_namelen = TheISA::htog(host->f_namemax);
    ^
build/ARM/sim/syscall_emul.hh:551:34: error: no member named 'f_spare' 
in 'statfs'

memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
     ^
build/ARM/sim/syscall_emul.hh:551:56: error: no member named 'f_spare' 
in 'statfs'

memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
   ^
3 errors generated.
scons: *** [build/ARM/arch/arm/linux/process.o] Error 1
scons: building terminated because of errors.


If I can help somehow to fix it and get gem5 running on OSX again 
please let me know.


Grml, then either the man page or the header file lied to me or I looked 
in the wrong place.  I’ll go and see and update the patch.





Am 25.01.2017 um 00:46 schrieb Bjoern A. Zeeb 
<bzeeb-li...@lists.zabbadoz.net>:


On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:


Hi Brandon,

I think this is a "real" bug:
http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt.
I think there are a few more places that need an #ifdef NO_STATFS. 
Could
you look into it and post a patch if there's a problem? If not, 
please

reply to the gem5 QA post and let them know.


Can people try this one and probably get the #ifdefs right for NetBSD 
as well?  There are at least 3 different checks for that code;  if 
people don’t care about “style” I could get it right, but ..


diff -r e47703369039 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
@@ -70,6 +70,8 @@
#include 
#if (NO_STATFS == 0)
#include 
+#else
+#include 
#endif
#include 
#include 
@@ -530,20 +532,25 @@
{
TypedBufferArg tgt(addr);

+tgt->f_type = TheISA::htog(host->f_type);
#if defined(__OpenBSD__) || defined(__APPLE__) || 
defined(__FreeBSD__)

-tgt->f_type = 0;
+tgt->f_bsize = TheISA::htog(host->f_iosize);
#else
-tgt->f_type = TheISA::htog(host->f_type);
+tgt->f_bsize = TheISA::htog(host->f_bsize);
#endif
-tgt->f_bsize = TheISA::htog(host->f_bsize);
tgt->f_blocks = TheISA::htog(host->f_blocks);
tgt->f_bfree = TheISA::htog(host->f_bfree);
tgt->f_bavail = TheISA::htog(host->f_bavail);
tgt->f_files = TheISA::htog(host->f_files);
tgt->f_ffree = TheISA::htog(host->f_ffree);
memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+#if defined(__OpenBSD__) || defined(__APPLE__) || 
defined(__FreeBSD__)

+tgt->f_namelen = TheISA::htog(host->f_namemax);
+tgt->f_frsize = TheISA::htog(host->f_bsize);
+#else
tgt->f_namelen = TheISA::htog(host->f_namelen);
tgt->f_frsize = TheISA::htog(host->f_frsize);
+#endif
memcpy(>f_spare, >f_spare, sizeof(host->f_spare));

tgt.copyOut(mem);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Bjoern A. Zeeb]

On 26 Jan 2017, at 17:04, Potter, Brandon wrote:

Hi,

in case you are having troubles getting gem5 compiling on it in general 
please give me a shout as I might have fixes that are either in review 
or on my local disk and I am more than happy to work with someone to 
make sure they are all in.


/bz


Hello all,

I'm trying to resolve this issue. I'm setting up FreeBSD 11 on a 
VirtualBox instance now to see if I can resolve the problems. 
Hopefully this covers OSX indirectly as well.


I don't expect that moving the offending system calls into Linux 
specific files will resolve the problem where the underlying host OS 
needs to make the system call on behalf of the target (like what 
happens with fallocate). I think the only way to resolve the issue is 
to add in preprocessor directives to prevent compilation/linkage 
errors on platforms that don't support what's necessary under the 
covers. (Correct me if there's a better way to handle this.)


I'll post a patch and respond to the mailing list when I have it 
working.


Regards,
Brandon

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas 
Hansson

Sent: Thursday, January 26, 2017 2:18 AM
To: gem5 Developer List <gem5-dev@gem5.org>
Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change

Hi all,

While I agree about the end goal (test every commit on every platform) 
I would suggest we go about this one step at a time. The likelihood of 
breakage is only high for anything related to syscall emulation, so it 
really only affects a small part of the developer community. Agreed?


With that in mind I think we can prevent 99% of the issues if syscall 
emulation patches are built on a BSD system with clang. I would be 
wrong, but I would think this is a very good filter, with a fairly low 
cost and effort of deployment. Virtualbox + some flavour of BSD would 
do it.


Andreas

On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
<gem5-dev-boun...@gem5.org on behalf of ja...@lowepower.com> wrote:

Yeah, it's a major problem that we say that we support macOS and 
others

when we allow commits that break builds on these other OSes.

If we are going to say that we have support for OSes other than 
Linux,
we need to at least verify gem5 builds on these OSes, preferably 
before

accepting a commit. I'm currently testing out the free Travis-CI
service ( https://travis-ci.org/powerjg/gem5-ci-test). We could
probably hook this up to our gem5 github page, if it works out.

Another important point, though, is that we can't expect all 
committers

to own multiple machines to test their changes on. We need something
that will do pre-commit builds on all the platforms we claim to
support.

We're in the middle of moving the regression tests to a hosted 
jenkins

instance. Hopefully this will solve some of these issues (though I
don't think it will support multiple OS builds).

Do others have any ideas on a long-term solution here?

Cheers,
Jason

On Tue, Jan 24, 2017 at 5:46 PM Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:

On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:


Hi Brandon,

I think this is a "real" bug:


http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-bu
ild
-arm-gem5-opt
.

I think there are a few more places that need an #ifdef NO_STATFS.
Could
you look into it and post a patch if there's a problem? If not,
please reply to the gem5 QA post and let them know.


Can people try this one and probably get the #ifdefs right for NetBSD
as well?  There are at least 3 different checks for that code;  if
people don’t care about “style” I could get it right, but ..

diff -r e47703369039 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
@@ -70,6 +70,8 @@
 #include 
 #if (NO_STATFS == 0)
 #include 
+#else
+#include 
 #endif
 #include 
 #include 
@@ -530,20 +532,25 @@
 {
 TypedBufferArg tgt(addr);

+tgt->f_type = TheISA::htog(host->f_type);
 #if defined(__OpenBSD__) || defined(__APPLE__) || 
defined(__FreeBSD__)

-tgt->f_type = 0;
+tgt->f_bsize = TheISA::htog(host->f_iosize);
 #else
-tgt->f_type = TheISA::htog(host->f_type);
+tgt->f_bsize = TheISA::htog(host->f_bsize);
 #endif
-tgt->f_bsize = TheISA::htog(host->f_bsize);
 tgt->f_blocks = TheISA::htog(host->f_blocks);
 tgt->f_bfree = TheISA::htog(host->f_bfree);
 tgt->f_bavail = TheISA::htog(host->f_bavail);
 tgt->f_files = TheISA::htog(host->f_files);
 tgt->f_ffree = TheISA::htog(host->f_ffree);
 memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+#if defined(__OpenBSD__) || defined(__APPLE__) || 
defined(__FreeBSD__)

+tgt->f_namelen = TheISA::htog(host->f_namemax);
+tgt->f_frsize = TheISA::htog(host->f_bsize); #else
 tgt->f_namel

[gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3791/
---

Review request for Default.


Repository: gem5


Description
---

There are drivers writing to WUFC uncondtionally of anything.  In order to not 
panic gem5 in these cases, ignore writes to WUFC and WUS as we do for WUC.  
Similarly return 0 (default reset value) on reads.


Diffs
-

  src/dev/net/i8254xGBe.cc e47703369039 
  src/dev/net/i8254xGBe_defs.hh e47703369039 

Diff: http://reviews.gem5.org/r/3791/diff/


Testing
---

Booted in FS with such a driver revision which would previously panic and now 
boots fine.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Bjoern A. Zeeb]

On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:


Hi Brandon,

I think this is a "real" bug:
http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt.
I think there are a few more places that need an #ifdef NO_STATFS. 
Could

you look into it and post a patch if there's a problem? If not, please
reply to the gem5 QA post and let them know.


Can people try this one and probably get the #ifdefs right for NetBSD as 
well?  There are at least 3 different checks for that code;  if people 
don’t care about “style” I could get it right, but ..


diff -r e47703369039 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
@@ -70,6 +70,8 @@
 #include 
 #if (NO_STATFS == 0)
 #include 
+#else
+#include 
 #endif
 #include 
 #include 
@@ -530,20 +532,25 @@
 {
 TypedBufferArg tgt(addr);

+tgt->f_type = TheISA::htog(host->f_type);
 #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
-tgt->f_type = 0;
+tgt->f_bsize = TheISA::htog(host->f_iosize);
 #else
-tgt->f_type = TheISA::htog(host->f_type);
+tgt->f_bsize = TheISA::htog(host->f_bsize);
 #endif
-tgt->f_bsize = TheISA::htog(host->f_bsize);
 tgt->f_blocks = TheISA::htog(host->f_blocks);
 tgt->f_bfree = TheISA::htog(host->f_bfree);
 tgt->f_bavail = TheISA::htog(host->f_bavail);
 tgt->f_files = TheISA::htog(host->f_files);
 tgt->f_ffree = TheISA::htog(host->f_ffree);
 memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
+tgt->f_namelen = TheISA::htog(host->f_namemax);
+tgt->f_frsize = TheISA::htog(host->f_bsize);
+#else
 tgt->f_namelen = TheISA::htog(host->f_namelen);
 tgt->f_frsize = TheISA::htog(host->f_frsize);
+#endif
 memcpy(>f_spare, >f_spare, sizeof(host->f_spare));

 tgt.copyOut(mem);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] changeset in gem5: syscall_emul: implement fallocate

[Bjoern A. Zeeb]

On 15 Dec 2016, at 18:17, Brandon Potter wrote:


changeset f9aa72424274 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=f9aa72424274
description:
syscall_emul: implement fallocate


Same problem here;  you are calling fallocate() which is a linux 
specific function and thus fails to compile elsewhere.




diffstat:

 src/arch/x86/linux/process.cc |   2 +-
 src/sim/syscall_emul.cc   |  21 +
 src/sim/syscall_emul.hh   |   4 
 3 files changed, 26 insertions(+), 1 deletions(-)

diffs (57 lines):

diff -r deaf82fd2e7c -r f9aa72424274 src/arch/x86/linux/process.cc
--- a/src/arch/x86/linux/process.cc Thu Dec 15 13:16:03 2016 -0500
+++ b/src/arch/x86/linux/process.cc Thu Dec 15 13:16:25 2016 -0500
@@ -503,7 +503,7 @@
 /* 282 */ SyscallDesc("signalfd", unimplementedFunc),
 /* 283 */ SyscallDesc("timerfd_create", unimplementedFunc),
 /* 284 */ SyscallDesc("eventfd", unimplementedFunc),
-/* 285 */ SyscallDesc("fallocate", unimplementedFunc),
+/* 285 */ SyscallDesc("fallocate", fallocateFunc),
 /* 286 */ SyscallDesc("timerfd_settime", unimplementedFunc),
 /* 287 */ SyscallDesc("timerfd_gettime", unimplementedFunc),
 /* 288 */ SyscallDesc("accept4", unimplementedFunc),
diff -r deaf82fd2e7c -r f9aa72424274 src/sim/syscall_emul.cc
--- a/src/sim/syscall_emul.cc   Thu Dec 15 13:16:03 2016 -0500
+++ b/src/sim/syscall_emul.cc   Thu Dec 15 13:16:25 2016 -0500
@@ -935,6 +935,27 @@
 }

 SyscallReturn
+fallocateFunc(SyscallDesc *desc, int callnum, LiveProcess *process,
+  ThreadContext *tc)
+{
+int index = 0;
+int tgt_fd = process->getSyscallArg(tc, index);
+int mode = process->getSyscallArg(tc, index);
+off_t offset = process->getSyscallArg(tc, index);
+off_t len = process->getSyscallArg(tc, index);
+
+int sim_fd = process->getSimFD(tgt_fd);
+if (sim_fd < 0)
+return -EBADF;
+
+int result = fallocate(sim_fd, mode, offset, len);
+if (result < 0)
+return -errno;
+
+return 0;
+}
+
+SyscallReturn
 accessFunc(SyscallDesc *desc, int callnum, LiveProcess *p, 
ThreadContext *tc,

 int index)
 {
diff -r deaf82fd2e7c -r f9aa72424274 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Thu Dec 15 13:16:03 2016 -0500
+++ b/src/sim/syscall_emul.hh   Thu Dec 15 13:16:25 2016 -0500
@@ -157,6 +157,10 @@
 SyscallReturn ignoreFunc(SyscallDesc *desc, int num,
  LiveProcess *p, ThreadContext *tc);

+// Target fallocateFunc() handler.
+SyscallReturn fallocateFunc(SyscallDesc *desc, int num,
+LiveProcess *p, ThreadContext *tc);
+
 /// Target exit() handler: terminate current context.
 SyscallReturn exitFunc(SyscallDesc *desc, int num,
LiveProcess *p, ThreadContext *tc);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] changeset in gem5: syscall_emul: add support for x86 statfs syst...

[Bjoern A. Zeeb]

On 15 Dec 2016, at 18:17, Brandon Potter wrote:


changeset deaf82fd2e7c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=deaf82fd2e7c
description:
syscall_emul: add support for x86 statfs system calls



Does this compile on anything but Linux?   statfs.h doesn’t exists 
elsewhere I guess?   statfs is historic and still more or less OS 
specific.


Did you actually implement statfs, or is this statvfs as in 
http://pubs.opengroup.org/onlinepubs/95399/basedefs/sys/statvfs.h.html 
?   Not sure what the linux syscall does there?





diffstat:

 src/arch/x86/linux/linux.hh   |  18 ++
 src/arch/x86/linux/process.cc |   2 +-
 src/sim/syscall_emul.hh   |  32 ++--
 3 files changed, 49 insertions(+), 3 deletions(-)

diffs (110 lines):

diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/linux.hh
--- a/src/arch/x86/linux/linux.hh   Thu Dec 15 13:14:41 2016 -0500
+++ b/src/arch/x86/linux/linux.hh   Thu Dec 15 13:16:03 2016 -0500
@@ -67,6 +67,24 @@
 int64_t unused0[3];
 } tgt_stat64;

+typedef struct {
+long val[2];
+} tgt_fsid;
+
+typedef struct {
+long f_type;
+long f_bsize;
+long f_blocks;
+long f_bfree;
+long f_bavail;
+long f_files;
+long f_ffree;
+tgt_fsid f_fsid;
+long f_namelen;
+long f_frsize;
+long f_spare[5];
+} tgt_statfs;
+
 static const int TGT_SIGHUP = 0x01;
 static const int TGT_SIGINT = 0x02;
 static const int TGT_SIGQUIT= 0x03;
diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/process.cc
--- a/src/arch/x86/linux/process.cc Thu Dec 15 13:14:41 2016 -0500
+++ b/src/arch/x86/linux/process.cc Thu Dec 15 13:16:03 2016 -0500
@@ -355,7 +355,7 @@
 /* 134 */ SyscallDesc("uselib", unimplementedFunc),
 /* 135 */ SyscallDesc("personality", unimplementedFunc),
 /* 136 */ SyscallDesc("ustat", unimplementedFunc),
-/* 137 */ SyscallDesc("statfs", unimplementedFunc),
+/* 137 */ SyscallDesc("statfs", statfsFunc),
 /* 138 */ SyscallDesc("fstatfs", unimplementedFunc),
 /* 139 */ SyscallDesc("sysfs", unimplementedFunc),
 /* 140 */ SyscallDesc("getpriority", unimplementedFunc),
diff -r 104a404d426e -r deaf82fd2e7c src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Thu Dec 15 13:14:41 2016 -0500
+++ b/src/sim/syscall_emul.hh   Thu Dec 15 13:16:03 2016 -0500
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -451,6 +452,7 @@
 //
 //

+typedef struct statfs hst_statfs;
 #if NO_STAT64
 typedef struct stat hst_stat;
 typedef struct stat hst_stat64;
@@ -556,6 +558,32 @@
 tgt.copyOut(mem);
 }

+template 
+static void
+copyOutStatfsBuf(SETranslatingPortProxy , Addr addr,
+ hst_statfs *host)
+{
+TypedBufferArg tgt(addr);
+
+#if defined(__OpenBSD__) || defined(__APPLE__) || 
defined(__FreeBSD__)

+tgt->f_type = 0;
+#else
+tgt->f_type = TheISA::htog(host->f_type);
+#endif
+tgt->f_bsize = TheISA::htog(host->f_bsize);
+tgt->f_blocks = TheISA::htog(host->f_blocks);
+tgt->f_bfree = TheISA::htog(host->f_bfree);
+tgt->f_bavail = TheISA::htog(host->f_bavail);
+tgt->f_files = TheISA::htog(host->f_files);
+tgt->f_ffree = TheISA::htog(host->f_ffree);
+memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+tgt->f_namelen = TheISA::htog(host->f_namelen);
+tgt->f_frsize = TheISA::htog(host->f_frsize);
+memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
+
+tgt.copyOut(mem);
+}
+
 /// Target ioctl() handler.  For the most part, programs call ioctl()
 /// only to find out if their stdout is a tty, to determine whether 
to

 /// do line or block buffering.  We always claim that output fds are
@@ -1156,7 +1184,7 @@
 if (result < 0)
 return -errno;

-OS::copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
+copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );

 return 0;
 }
@@ -1182,7 +1210,7 @@
 if (result < 0)
 return -errno;

-OS::copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );
+copyOutStatfsBuf(tc->getMemProxy(), bufPtr, );

 return 0;
 }
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 MinorCPU Branch Prediction

[Bjoern A. Zeeb]

On 9 Dec 2016, at 16:56, Jason Lowe-Power wrote:


Hi Bjoern,

It's not fully tested, and I don't think everything works perfectly.
However, I've had pretty good luck running simple benchmarks with it.


Ok, a first FS run wasn’t exactly happy.  And now it’s possibly the 
time to go back to the original topic;  if there’s anything I should 
extract or try, let me know.


PS: panic messages like this are not particularly helpful;  one almost 
wants to know an address or something along with them immediately?


panic: Invalid microop!
 @ tick 1608517106500
[invoke:build/X86/arch/generic/debugfaults.hh, line 94]


#3  0x0099c5c6 in abortHandler (sigtype=) 
at build/X86/sim/init_signals.cc:151

#4  0x000801eb0b4a in pthread_sigmask () from /lib/libthr.so.3
#5  0x000801eb022c in pthread_getspecific () from /lib/libthr.so.3
#6  
#7  0x0008039d735a in thr_kill () from /lib/libc.so.7
#8  0x0008039d7346 in raise () from /lib/libc.so.7
#9  0x0008039d72c9 in abort () from /lib/libc.so.7
#10 0x00974ced in __exit_epilogue (code=, 
func=0x1462ae8 "invoke", file=0x14bbfa2 
"build/X86/arch/generic/debugfaults.hh", line=94, format=optimized out>)

at build/X86/base/misc.cc:94
#11 0x006f55c6 in _Z14__exit_messageIJEEvPKciS1_S1_iS1_DpRKT_ 
(prefix=, code=, func=optimized out>, file=,
line=, format=) at 
misc.hh:81
#12 0x0081c5d2 in 
_Z14__exit_messageIJEEvPKciS1_S1_iRKNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcDpRKT_ 
(prefix=0x188b4 , code=0,
func=0x0, file=0x8039d737a "\017\202202\b", line=0, 
format=@0xf84d5c54a000) at misc.hh:89
#13 0x00a5c7c1 in GenericISA::M5DebugFault::invoke (this=0x0, 
tc=0x6, inst=@0x0) at debugfaults.hh:94
#14 0x00a0901f in Minor::Execute::commitInst (this=0x8045322f0, 
inst={data = 0x80444aa00}, early_memory_issue=, 
branch=@0x804449d80, fault=@0x7fffd670,
committed=, completed_mem_issue=optimized out>) at build/X86/cpu/minor/execute.cc:974
#15 0x00a0a2f4 in Minor::Execute::commit (this=0x8045322f0, 
thread_id=, only_commit_microops=false, 
discard=false, branch=@0x804449d80)

at build/X86/cpu/minor/execute.cc:1279
#16 0x00a0b129 in Minor::Execute::evaluate (this=0x8045322f0) at 
build/X86/cpu/minor/execute.cc:1460
#17 0x00a33160 in Minor::Pipeline::evaluate (this=0x804532000) 
at build/X86/cpu/minor/pipeline.cc:135
#18 0x009b277d in Ticked::ClockEvent::process (this=0x804532010) 
at ticked_object.hh:80
#19 0x00998dbe in EventQueue::serviceOne (this=out>) at build/X86/sim/eventq.cc:228
#20 0x009b2edc in doSimLoop (eventq=0x80442b740) at 
build/X86/sim/simulate.cc:218
#21 0x009b2b6c in simulate (num_cycles=) at 
build/X86/sim/simulate.cc:131
#22 0x00897a03 in _wrap_simulate (self=, 
args=) at build/X86/python/swig/event_wrap.cc:5698

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 MinorCPU Branch Prediction

[Bjoern A. Zeeb]

On 9 Dec 2016, at 16:56, Jason Lowe-Power wrote:


Hi Bjoern,

It's not fully tested, and I don't think everything works perfectly.


Well, that’s true for more gem5 X86 things ;-)



However, I've had pretty good luck running simple benchmarks with it.


Great;  I’ll give it a go and see.

The command line scons .. CPU_MODELS=.. works;  editing build_opts/X86 
did not make it show up in CPU_MODELS when I printed it on the next 
scons run even after rm -rf build/X86;  I’ll go and check on a clean 
checkout again when I have more time unless someone beats me to it.


Happy weekend!

/bz
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 MinorCPU Branch Prediction

[Bjoern A. Zeeb]

On 23 Nov 2016, at 4:05, Ayaz Akram wrote:


Hi,

I had posted a problem that I faced with x86 minor cpu regarding 
branch
prediction on gem5 users mailing list (link of that post is given 
below):


sorry for hijacking this;  how do you get MinorCPU running on X86?

I added printf during compilation and I do see:

XXX-BZ supported CPU_MODELS: AtomicSimpleCPU,O3CPU,TimingSimpleCPU
XXX-BZ supported CPU_MODELS subst: AtomicSimpleCPU O3CPU TimingSimpleCPU
XXX-BZ CpuModel keys O3CPU
XXX-BZ CpuModel keys AtomicSimpleCPU
XXX-BZ CpuModel keys no
XXX-BZ CpuModel keys MinorCPU
XXX-BZ CpuModel keys CheckerCPU
XXX-BZ CpuModel keys TimingSimpleCPU
XXX-BZ CpuModel items O3CPU default 1
XXX-BZ CpuModel items AtomicSimpleCPU default 1
XXX-BZ CpuModel items no default 0
XXX-BZ CpuModel items MinorCPU default 1
XXX-BZ CpuModel items CheckerCPU default 0
XXX-BZ CpuModel items TimingSimpleCPU default 1
XXX-BZ sorted AtomicSimpleCPU
XXX-BZ sorted MinorCPU
XXX-BZ sorted O3CPU
XXX-BZ sorted TimingSimpleCPU

When I do list the CPU types on X86 it’s not there (funnily the 
arm_detail is listed unconditionally):


$ ./build/X86/gem5.opt configs/example/fs.py --list-cpu-types
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
..
command line: ./build/X86/gem5.opt configs/example/fs.py 
--list-cpu-types

..
Available CPU classes:
arm_detailed
AtomicSimpleCPU
Simple CPU model executing a configurable number of 
instructions per
cycle. This model uses the simplified 'atomic' memory 
mode.

TraceCPU
Trace CPU model which replays traces generated in a 
prior simulation
using DerivO3CPU or its derived classes. It interfaces 
with L1

caches.
DerivO3CPU
TimingSimpleCPU

CPU aliases:
timing => TimingSimpleCPU
detailed => DerivO3CPU
atomic => AtomicSimpleCPU
trace => TraceCPU

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3690: x86, ext: fix buf overflow in fp80 ops; pad fp80_t in fputils

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3690/#review9029
---

Ship it!


Tested on X86 booting FreeBSD reverting my own simple workaround.
I can say that gem5 does no longer panic when booting FreeBSD FS with this 
patch applied.
I cannot say whether it works correctly currently.
However it improves the situation :)

- Bjoern A. Zeeb


On Nov. 1, 2016, 7:36 p.m., Tony Gutierrez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3690/
> ---
> 
> (Updated Nov. 1, 2016, 7:36 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11888:ed39f10e4ff3
> ---
> x86, ext: fix buf overflow in fp80 ops; pad fp80_t in fputils
> 
> the compiler seems to align the fp80_t data struct, so here we add
> explicit padding to avoid confusion.
> 
> storeFloat80() will try to write all 16B of the fp80_t to the bits[] array
> of the calling instruction. this happens because storeFloat80() points its
> local fp80_t* to the memory the caller allocated for bits[], which is only
> 10B, thus we get an overflow that is flagged by clang's asan. here we
> get the fp80 value first, the memcpy() the bits[] of fp80_t to the mem
> allocated by the caller.
> 
> 
> Diffs
> -
> 
>   ext/fputils/fpbits.h c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   ext/fputils/include/fputils/fptypes.h 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/isa/microops/fpop.isa c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/utility.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3690/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tony Gutierrez
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: arm, dev: pl011 console interactivity

[Bjoern A. Zeeb]

changeset 6281479f9713 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6281479f9713
description:
arm, dev: pl011 console interactivity

Improve PL011 console interactivity

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/dev/arm/pl011.cc |  10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diffs (27 lines):

diff -r b3c3893811af -r 6281479f9713 src/dev/arm/pl011.cc
--- a/src/dev/arm/pl011.cc  Sat Oct 15 15:06:24 2016 -0500
+++ b/src/dev/arm/pl011.cc  Sat Oct 15 15:11:04 2016 -0500
@@ -86,6 +86,11 @@
 // Since we don't simulate a FIFO for incoming data, we
 // assume it's empty and clear RXINTR and RTINTR.
 clearInterrupts(UART_RXINTR | UART_RTINTR);
+if (term->dataAvailable()) {
+DPRINTF(Uart, "Re-raising interrupt due to more data "
+"after UART_DR read\n");
+dataAvailable();
+}
 }
 break;
   case UART_FR:
@@ -224,6 +229,11 @@
   case UART_ICR:
 DPRINTF(Uart, "Clearing interrupts 0x%x\n", data);
 clearInterrupts(data);
+if (term->dataAvailable()) {
+DPRINTF(Uart, "Re-raising interrupt due to more data after "
+"UART_ICR write\n");
+dataAvailable();
+}
 break;
   default:
 panic("Tried to write PL011 at offset %#x that doesn't exist\n", 
daddr);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3667: arm: AArch64 report cache size correctly when reading CTR_EL0

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3667/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

Trying to read MISCREG_CTR_EL0 on AArch64 returned 0 as is was not 
implmemented.  With that an operating system relying on the cache line sizes 
reported in order to manage the caches would (a) panic given the returned value 
0 is not valid (high bit is RES1) or (b) worst case would assume a cache line 
size of 4 doing a tremendous amount of extra instruction work (including 
fetching).  Return the same values as for ARMv7 as the fields seem to be the 
same, or RES0/1 seem to be reported accordingly for AArch64

In collaboration with:  Andrew Turner


Diffs
-

  src/arch/arm/isa.cc 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3667/diff/


Testing
---

Checked on FreeBSD boots with extra printfs;  also observed a reduction of a 
factor of about 10 in instruction fetches for a simple micro-test.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3623: arm, dev: pl011 console interactivity

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3623/
---

(Updated Sept. 19, 2016, 10:31 p.m.)


Review request for Default and Andreas Sandberg.


Changes
---

Removed useless conditional check as pointed out by Andreas.


Repository: gem5


Description
---

Improve PL011 console interactivity


Diffs (updated)
-

  src/dev/arm/pl011.cc d726d0cea027 

Diff: http://reviews.gem5.org/r/3623/diff/


Testing
---

We are operating in "register mode" (not FIFO) which means if we clear an 
interrupt and have more data available, we need to re-raise the interrupt 
again.  Add two more cases where this is needed.

With this the interactivity on FreeBSD went to usable.  Before this after a 
certain event, it could take up to 15(?) additional charatcers to get 
previously pasted command lines echoed and executed.

I have a possible report about similar behaviour from people at ARM on Linux 
(uncofirmed) and I am putting the patch up so they can test.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3623: arm, dev: pl011 console interactivity

[Bjoern A. Zeeb]

> On Sept. 6, 2016, 10:52 a.m., Andreas Sandberg wrote:
> > src/dev/arm/pl011.cc, line 232
> > <http://reviews.gem5.org/r/3623/diff/1/?file=57828#file57828line232>
> >
> > I'm not sure I understand exactly what this condition is supposed to 
> > test. The check currently tests if there is an unmasked RX interrupt 
> > pending before raising a new RX interrupt. I suspect the intention might be 
> > to check if the RX interrupt is enabled (maskInt() is a bit of a misnomer).
> > 
> > You shouldn't need to worry about the mask (or whether the interrupt is 
> > pending) here since setInterrupts won't poke the GIC unless there is a new 
> > interrupt pending (raising a pending interrupt is effectively a no-op).

Doh!  Sure.  I see what you mean.  It should have been imsc & UART_RXINTR which 
is pointless as that's indeed what is abstracted through dataAvailable() in the 
pl011 code.  I'll drop the condition and re-check.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3623/#review8711
---


On Sept. 5, 2016, 10:22 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3623/
> ---
> 
> (Updated Sept. 5, 2016, 10:22 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Improve PL011 console interactivity
> 
> 
> Diffs
> -
> 
>   src/dev/arm/pl011.cc d726d0cea027 
> 
> Diff: http://reviews.gem5.org/r/3623/diff/
> 
> 
> Testing
> ---
> 
> We are operating in "register mode" (not FIFO) which means if we clear an 
> interrupt and have more data available, we need to re-raise the interrupt 
> again.  Add two more cases where this is needed.
> 
> With this the interactivity on FreeBSD went to usable.  Before this after a 
> certain event, it could take up to 15(?) additional charatcers to get 
> previously pasted command lines echoed and executed.
> 
> I have a possible report about similar behaviour from people at ARM on Linux 
> (uncofirmed) and I am putting the patch up so they can test.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3623: arm, dev: pl011 console interactivity

[Bjoern A. Zeeb]

> On Sept. 6, 2016, 9:34 a.m., Andreas Sandberg wrote:
> > src/dev/arm/pl011.cc, line 232
> > <http://reviews.gem5.org/r/3623/diff/1/?file=57828#file57828line232>
> >
> > Do you actually need the check against maskInt() here? The necessary 
> > checks should already be inplace in dataAvailable()/raiseInterrupts().

I can't see the conditional check in either;  well setInterrupts() does have a 
check but to my understanding is not exactly doing this based on what's passed 
in for this code path.   It's just RX and not TX.  I think the 8250 UART code 
does the same, so keeping it "similar" seems a good idea ;-)


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3623/#review8709
-------


On Sept. 5, 2016, 10:22 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3623/
> ---
> 
> (Updated Sept. 5, 2016, 10:22 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Improve PL011 console interactivity
> 
> 
> Diffs
> -
> 
>   src/dev/arm/pl011.cc d726d0cea027 
> 
> Diff: http://reviews.gem5.org/r/3623/diff/
> 
> 
> Testing
> ---
> 
> We are operating in "register mode" (not FIFO) which means if we clear an 
> interrupt and have more data available, we need to re-raise the interrupt 
> again.  Add two more cases where this is needed.
> 
> With this the interactivity on FreeBSD went to usable.  Before this after a 
> certain event, it could take up to 15(?) additional charatcers to get 
> previously pasted command lines echoed and executed.
> 
> I have a possible report about similar behaviour from people at ARM on Linux 
> (uncofirmed) and I am putting the patch up so they can test.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3623: arm, dev: pl011 console interactivity

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3623/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

Improve PL011 console interactivity


Diffs
-

  src/dev/arm/pl011.cc d726d0cea027 

Diff: http://reviews.gem5.org/r/3623/diff/


Testing
---

We are operating in "register mode" (not FIFO) which means if we clear an 
interrupt and have more data available, we need to re-raise the interrupt 
again.  Add two more cases where this is needed.

With this the interactivity on FreeBSD went to usable.  Before this after a 
certain event, it could take up to 15(?) additional charatcers to get 
previously pasted command lines echoed and executed.

I have a possible report about similar behaviour from people at ARM on Linux 
(uncofirmed) and I am putting the patch up so they can test.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] X86 RSP return address (after MemWrite) not yet updated issue?

[Bjoern A. Zeeb]

On 25 Aug 2016, at 22:09, Andreas Hansson wrote:


Hi all,


Thanks a lot for that reply.


Two thoughts:

1. Does X86 + o3 + classic memory system actually work?
2. The interleaving of “real” timing accesses and the functional 
“debug”
accesses is not well defined. In general I would encourage to not 
assume

anything.

If you are indeed using classic (see 1), then I think I know what is
causing the issue. In functional cache accesses we check the cache 
itself
before we check the MSHRs. Thus, if a write is done from the 
perspective

of the LSQ, you won’t necessarily see it by means of the functional
access. Is it a bug (see 2), we’d have to decide?


I think that might be related to the only(1) other issue I see on x86 + 
o3 + classic.
How can we fix this?   Why is it not an issue on ARM (which does the 
same)?  Is it because there you only have a the register but no memory 
access?



(1) well or not.  I found a couple of “timing sensitive” issues to 
which I either have a workaround by changing latencies or adding an 
extra function call somewhere into my OS code to spread critical 
accesses further apart.  I am happy to provide trace that show these 
problems, e.g. I was hitting the IOAPIC with 64 bytes packets rather 
than 4 byte packets when I enabled the L2 cache;  and I do have a case 
where after a page table walk I hit a PTE of 0 and the fault is delayed 
for ages (or not delivered) causing problems on the next access as that 
expects the page to be mapped in the kernel.



Whatever gets us closer to be able to successfully run this, would be 
good :)



On 25/08/2016, 21:52, "gem5-dev on behalf of Potter, Brandon"
 wrote:


Hi Bjoern,

Did you ever solve this issue?  I see what you're describing, but 
it's

not obvious to me what causes the problem.


No.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Fault handling issue

[Bjoern A. Zeeb]

On 19 Aug 2016, at 17:45, Rodolfo Guilherme Wottrich wrote:

Hi Rodolfo,

how did you solve this (code wise).  I am trying to hunt down an 
undelivered Page Fault on x86 FS and another problem only showing up as 
I add more caches (e.g., a L2) and I am just curious about all kinds of 
x86 problems other people see and their code changes to fix things.


Thanks,
Bjoern

For future reference: my problem was not that subsequent instructions 
would
not squash. I missed out on the fact that the store queue's behaviour 
is
asynchronous and although the instructions had been committed many 
cycles
before, the requests would still be in the store queue to be consumed 
by
the cache. It was only a matter of forcefully removing the stores for 
the

LSQ and it worked.

---
Rodolfo Wottrich

On Mon, Aug 15, 2016 at 5:24 PM, Rodolfo Guilherme Wottrich <
rgw...@gmail.com> wrote:


Hi Fernando,

Thank you for the suggestion. Yes, I have tried that, but the problem 
is

that no similar faults take happen, especially in SE mode.
I wonder if it may be the case of some squashing function call that I 
am

missing.

Does anybody have experience with squashing instructions in the 
commit

stage?


---
Rodolfo Wottrich

On Mon, Aug 8, 2016 at 10:08 AM, Fernando Endo 


wrote:


Hello,

Probably I can't technically help you here, but have you considered
observing the simulator behavior when similar faults happen? For 
example,
simulate a program that access an invalid address and enable all 
related

debug flags to track it (--debug-flags option).

Hope it helps,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France


2016-08-03 3:30 GMT+02:00 Rodolfo Guilherme Wottrich 
:



Hello,

I would like to request some assistance if possible. For my PhD 
work, I
need to be able to trigger a CPU fault when a particular condition 
in

the

L1 cache controller is met. I am using an o3 x86 CPU and Ruby in SE

mode.


I have come to a partial solution to the problem, based on a patch 
I

found

which dealt with a similar situation. That involves creating a new
Sequencer callback function that is used only at that specific

situation in

the cache controller which triggers a sequence of actions that

eventually
lead to a Fault object being instantiated in the LSQ and in the 
commit

stage of the pipeline.

The problem is that although the Fault and its handling are 
"working"

(control flow changes and registers are updated as they should),

subsequent
requests still keep being received by the cache in the mandatory 
queue

from
the instructions following the offending one. Those instructions 
should

have been cancelled as in a branch misprediction and their requests

should

have been removed from the LSQ to avoid inconsistency.

Can anybody think of why I am having such a problem/how can I solve 
it?

I

can provide specifics once the discussion starts.

Thank you in advance.
Cheers,

---
Rodolfo Wottrich
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev





___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] X86 RSP return address (after MemWrite) not yet updated issue?

[Bjoern A. Zeeb]

Hi,

I was trying to skip FreeBSD’s DELAY() on X86_64 very much like we do 
on ARM for Linux (or FreeBSD for that matter) and started to implement 
things and found a strange behaviour:


From my src/arch/x86/utility.cc

void
skipFunction(ThreadContext *tc)
{
PCState newPC = tc->pcState();
Addr sp = tc->readIntReg(INTREG_RSP);
DPRINTF(XXXBZ, "XXX-BZ sp %#x\n", sp);
Addr npc;
// XXX For some reason the memory write is not visible yet *sigh*
//CopyOut(tc, , sp, sizeof(Addr));
FSTranslatingPortProxy  = tc->getVirtProxy();
proxy.readBlob(sp, (uint8_t *), sizeof(Addr));
DPRINTF(XXXBZ, "XXX-BZ npc %#x\n", npc);
newPC.set(npc);
// Don't forget to increment the sp again.
tc->setIntReg(INTREG_RSP, sp + 8);
tc->pcState(newPC);
}


As you can see I tried two ways to read the return address off the 
stack, and neither (on the first try) returns the current one (after the 
memory write) but the previous one, which makes the preceding function 
part since the last ret to be run twice and on the 2nd iteration the 
memory location on the stack returns the proper (former) return address 
and we continue.   I would expected the correct value to be visible 
given the instruction was committed and logged with the DPRINTF.


That’s not the behaviour I expected.  Is there anything I am doing 
wrong or is this a (caching) bug?  Can anyone enlighten me?


My command line (including private options):

command line: ./build/X86/gem5.opt -r -e -d m5out-amd64-1 
--stdout-file=fbsd301452-detailed-00117.log 
--stderr-file=fbsd301452-detailed-00117.err --debug-flags=Exec,XXXBZ 
configs/example/fs.py --mem-size=1024MB --os-type=FreeBSD --virtblk 
--loader-config-file=loader-amd64.conf --cpu-type=detailed 
--disk-image=disk-amd64-r301452.img --kernel=kernel-amd64-r301452 
--command-line=-hvs --caches --l2cache --l3cache --simple-trace-en


Bjoern



222604924000: system.cpu T0 : @_vprintf+255: ret
222604924000: system.cpu T0 : @_vprintf+255.0  :   RET_NEAR : ld   t1, 
SS:[rsp] : MemRead :  D=0x803e4d23 A=0x80974b98
222604924500: system.cpu T0 : @_vprintf+255.1  :   RET_NEAR : addi   
rsp, rsp, 0x8 : IntAlu :  D=0x80974ba0
222604924500: system.cpu T0 : @_vprintf+255.2  :   RET_NEAR : wripi   , 
t1, 0 : IntAlu :
222604933000: system.cpu T0 : @printf+83: cmp   
DS:[0x8095c638], 0
222604933000: system.cpu T0 : @printf+83.0  :   CMP_M_I : limm   t2, 0   
: IntAlu :  D=0x
222604933000: system.cpu T0 : @printf+83.1  :   CMP_M_I : ld   t1, 
DS:[0x8095c638] : MemRead :  D=0x 
A=0x8095c638
222604933000: system.cpu T0 : @printf+83.2  :   CMP_M_I : sub   t0, t1, 
t2 : IntAlu :  D=0x

222604933000: system.cpu T0 : @printf+92: jnz   0xb
222604933000: system.cpu T0 : @printf+92.0  :   JNZ_I : rdip   t1, 
%ctrl153,  : IntAlu :  D=0x803e4d2e
222604933000: system.cpu T0 : @printf+92.1  :   JNZ_I : limm   t2, 0xb   
: IntAlu :  D=0x000b
222604933000: system.cpu T0 : @printf+92.2  :   JNZ_I : wrip   , t1, t2  
: IntAlu :
222604933000: system.cpu T0 : @printf+94: mov   
DS:[0x8095cab8], 0x1
222604933000: system.cpu T0 : @printf+94.0  :   MOV_M_I : limm   t1d, 
0x1 : IntAlu :  D=0x0001
222604933000: system.cpu T0 : @printf+94.1  :   MOV_M_I : st   t1d, 
DS:[0x8095cab8] : MemWrite :  D=0x0001 
A=0x8095cab8

222604933500: system.cpu T0 : @printf+105: add  rax, 0x50
222604933500: system.cpu T0 : @printf+105.0  :   ADD_R_I : limm   t1, 
0x50 : IntAlu :  D=0x0050
222604933500: system.cpu T0 : @printf+105.1  :   ADD_R_I : add   rsp, 
rsp, t1 : IntAlu :  D=0x

222604933500: system.cpu T0 : @printf+109: pop  rbp
222604933500: system.cpu T0 : @printf+109.0  :   POP_R : ld   t1, 
SS:[rsp] : MemRead :  D=0x80974c60 A=0x80974bf0
222604933500: system.cpu T0 : @printf+109.1  :   POP_R : addi   rsp, 
rsp, 0x8 : IntAlu :  D=0x80974bf8
222604933500: system.cpu T0 : @printf+109.2  :   POP_R : mov   rbp, rbp, 
t1 : IntAlu :  D=0x80974c60

222604933500: system.cpu T0 : @printf+110: ret
222604933500: system.cpu T0 : @printf+110.0  :   RET_NEAR : ld   t1, 
SS:[rsp] : MemRead :  D=0x80611d2e A=0x80974bf8
222604933500: system.cpu T0 : @printf+110.1  :   RET_NEAR : addi   rsp, 
rsp, 0x8 : IntAlu :  D=0x80974c00
222604933500: system.cpu T0 : @printf+110.2  :   RET_NEAR : wripi   , 
t1, 0 : IntAlu :

222604944000: system.cpu T0 : @init_TSC+894: rdtsc
222604944000: system.cpu T0 : @init_TSC+894.0  :   RDTSC : rdtsc   t1d, 
%ctrl26,  : IntAlu :  D=0x1a895d29
222604944000: system.cpu T0 : @init_TSC+894.1  :   RDTSC : mov   eax, 
eax, t1d : IntAlu :  D=0x1a895d29
222604944000: system.cpu T0 : @init_TSC+894.2  :   RDTSC : srli   t1, 
t1, 0x20 : IntAlu :  D=0x
222604944000: system.cpu T0 : @init_TSC+894.3  :   RDTSC : mov 

Re: [gem5-dev] changeset in gem5: x86, sim: add some syscalls to X86

[Bjoern A. Zeeb]

On 6 Aug 2016, at 7:48, Andreas Hansson wrote:


No worries. The distributed gem5 build farm strikes again. Typically
building on OSX with clang serves as a good check since it more or 
less

pareto-dominates in terms of pickiness.


I guess I should submit my remaining build-on-FreeBSD changes (contrary 
to the build for FreeBSD which will come soon-ish as well), and you can 
have more diversity on the build-farm, can have clang, and don’t need 
a commercial OS ;-)


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Let's retire some ISAs

[Bjoern A. Zeeb]

> On 06 Jun 2016, at 19:05 , Beckmann, Brad  wrote:
> 
Hi,

> As others have already pointed out, there is still significant industry 
> support for MIPS, SPARC, and POWER.  Perhaps an argument could be made 
> against ALPHA, but how hard is that ISA to maintain?  Also there is some 
> historical significance to ALPHA, since it was the first ISA.  As Boris just 
> pointed out, if anything, we should actively be encouraging someone to add 
> RISC-V.  We only drive people away from the simulator when we discuss 
> removing features.

I looked at MIPS (FS) support a few months back;  it’s just not there;  I mean 
literally, what is there is not even a start to get it to working in any 
reasonable timeframe.  I’d love to see 64bit MIPS support but that’s quite a 
lot of man hours.

One thing people need to remember however is that retiring (currently) unusable 
code does not mean that the code disappears, it sits in attic and could be 
brought back;  the effort to get it working is needed now and will be then.   
The question simply is how likely is it going to happen and when does the cost 
of keeping it around by far exceed the cost of resurrecting it.

My experience with x86_64 on non-Linux was not entirely happy the last 9 
months, that I’d rather wish the “advertising” would have been correct or I 
might have never gone down that path; you need to be realistic in terms of what 
people can expect and I’d rather have 3 properly working ISAs than 7 out of 
which I waste a year of time to get anywhere.  In that way I think Andreas is 
right:  you need at least 3 people per ISA that feel responsible and commit 
themselves to (a) review patches and get them in, (b) keep enough Open Source 
bits available for tests and reproducibility, and (c) fee actively responsible 
for further development, documentation, keeping things going.

Just my 3cts
Bjoern

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

> On April 13, 2016, 4:03 p.m., Andreas Hansson wrote:
> > SConstruct, line 639
> > <http://reviews.gem5.org/r/3378/diff/2/?file=54872#file54872line639>
> >
> > Surely this is included by default?!
> 
> Bjoern A. Zeeb wrote:
> clang -cc1 -v /dev/null
> clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target 
> x86_64-unknown-freebsd10.3
> ignoring nonexistent directory "/usr/lib/clang/3.4.1/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include/clang/3.4.1
>  /usr/include
> End of search list.
> 
> Andreas Hansson wrote:
> Is the compiler configured/installed properly? I've had a look at gcc and 
> clang on a few OSX/Linux permutations and /usr/local/include is listed for 
> all of them.

Yes, it's the built-in compiler from the FreeBSD base system.  I just 
triple-checked with people; it is on purpose;  the FreeBSD ports framework does 
add a -I${LOCALBASE}/include already, but building gem5 alone, it needs the 
extra include.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review8200
---


On April 13, 2016, 2:18 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated April 13, 2016, 2:18 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct 9c7b55faea5d 
>   tests/SConscript 9c7b55faea5d 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

> On April 13, 2016, 4:03 p.m., Andreas Hansson wrote:
> > SConstruct, line 639
> > <http://reviews.gem5.org/r/3378/diff/2/?file=54872#file54872line639>
> >
> > Surely this is included by default?!

clang -cc1 -v /dev/null
clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target 
x86_64-unknown-freebsd10.3
ignoring nonexistent directory "/usr/lib/clang/3.4.1/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/clang/3.4.1
 /usr/include
End of search list.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review8200
---


On April 13, 2016, 2:18 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated April 13, 2016, 2:18 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct 9c7b55faea5d 
>   tests/SConscript 9c7b55faea5d 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: config, x86: Properly space pad the X86IntelM...

[Bjoern A. Zeeb]

changeset fc247b9c42b6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=fc247b9c42b6
description:
config, x86: Properly space pad the X86IntelMPBus Entry descriptions

According to the Intel Multi Processor Specification rev 1.4 (-006) (*),
section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII
(blank-filled) strings<<.
This patch properly pads the entries with the missing spaces at the end.

(*) http://www.intel.com/design/pentium/datashts/24201606.pdf

Committed by Jason Lowe-Power 

diffstat:

 configs/common/FSConfig.py   |  4 ++--
 src/arch/x86/bios/IntelMP.py |  2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diffs (27 lines):

diff -r 2af4c6a4f3f5 -r fc247b9c42b6 configs/common/FSConfig.py
--- a/configs/common/FSConfig.pyThu May 19 15:19:35 2016 -0500
+++ b/configs/common/FSConfig.pyThu May 19 15:19:35 2016 -0500
@@ -553,9 +553,9 @@
 # In gem5 Pc::calcPciConfigAddr(), it required "assert(bus==0)",
 # but linux kernel cannot config PCI device if it was not connected to PCI 
bus,
 # so we fix PCI bus id to 0, and ISA bus id to 1.
-pci_bus = X86IntelMPBus(bus_id = 0, bus_type='PCI')
+pci_bus = X86IntelMPBus(bus_id = 0, bus_type='PCI   ')
 base_entries.append(pci_bus)
-isa_bus = X86IntelMPBus(bus_id = 1, bus_type='ISA')
+isa_bus = X86IntelMPBus(bus_id = 1, bus_type='ISA   ')
 base_entries.append(isa_bus)
 connect_busses = X86IntelMPBusHierarchy(bus_id=1,
 subtractive_decode=True, parent_bus=0)
diff -r 2af4c6a4f3f5 -r fc247b9c42b6 src/arch/x86/bios/IntelMP.py
--- a/src/arch/x86/bios/IntelMP.py  Thu May 19 15:19:35 2016 -0500
+++ b/src/arch/x86/bios/IntelMP.py  Thu May 19 15:19:35 2016 -0500
@@ -115,7 +115,7 @@
 
 bus_id = Param.UInt8(0, 'bus id assigned by the bios')
 bus_type = Param.String("", 'string that identify the bus type')
-# Legal values for bus_type are:
+# Legal values for bus_type are [space padded to 6 bytes]:
 #
 # "CBUS", "CBUSII", "EISA", "FUTURE", "INTERN", "ISA", "MBI", "MBII",
 # "MCA", "MPI", "MPSA", "NUBUS", "PCI", "PCMCIA", "TC", "VL", "VME",
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: arm, dev: PL011 UART_FR read status enhancement

[Bjoern A. Zeeb]

changeset 2af4c6a4f3f5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=2af4c6a4f3f5
description:
arm,dev: PL011 UART_FR read status enhancement

Given we do not simulate a FIFO currently there are only two states
we can be in upon read: empty or full.  Properly signal the latter.

Add and sort constants for states in the header file.

Committed by Jason Lowe-Power 

diffstat:

 src/dev/arm/pl011.cc |  3 ++-
 src/dev/arm/pl011.hh |  4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diffs (28 lines):

diff -r 8b23edf06cd3 -r 2af4c6a4f3f5 src/dev/arm/pl011.cc
--- a/src/dev/arm/pl011.cc  Thu May 19 15:19:35 2016 -0500
+++ b/src/dev/arm/pl011.cc  Thu May 19 15:19:35 2016 -0500
@@ -91,7 +91,8 @@
   case UART_FR:
 data =
 UART_FR_CTS | // Clear To Send
-(!term->dataAvailable() ? UART_FR_RXFE : 0) | // RX FIFO Empty
+// Given we do not simulate a FIFO we are either empty or full.
+(!term->dataAvailable() ? UART_FR_RXFE : UART_FR_RXFF) |
 UART_FR_TXFE; // TX FIFO empty
 
 DPRINTF(Uart,
diff -r 8b23edf06cd3 -r 2af4c6a4f3f5 src/dev/arm/pl011.hh
--- a/src/dev/arm/pl011.hh  Thu May 19 15:19:35 2016 -0500
+++ b/src/dev/arm/pl011.hh  Thu May 19 15:19:35 2016 -0500
@@ -120,8 +120,10 @@
 static const int UART_DR = 0x000;
 static const int UART_FR = 0x018;
 static const int UART_FR_CTS  = 0x001;
+static const int UART_FR_RXFE = 0x010;
+static const int UART_FR_TXFF = 0x020;
+static const int UART_FR_RXFF = 0x040;
 static const int UART_FR_TXFE = 0x080;
-static const int UART_FR_RXFE = 0x010;
 static const int UART_IBRD = 0x024;
 static const int UART_FBRD = 0x028;
 static const int UART_LCRH = 0x02C;
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: x86, dev: properly space the APIC registers

[Bjoern A. Zeeb]

changeset 8b23edf06cd3 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8b23edf06cd3
description:
x86, dev: properly space the APIC registers

Registers are 0x10 and not 0x8 apart.  The latter leads to invalid
calculations of index in array which in turn means that we will not
find the interrupt we were looking (been notified) for in the OS.

Committed by Jason Lowe-Power 

diffstat:

 src/arch/x86/interrupts.cc |  30 +++---
 1 files changed, 3 insertions(+), 27 deletions(-)

diffs (65 lines):

diff -r c926270c33c8 -r 8b23edf06cd3 src/arch/x86/interrupts.cc
--- a/src/arch/x86/interrupts.ccThu May 19 15:19:34 2016 -0500
+++ b/src/arch/x86/interrupts.ccThu May 19 15:19:35 2016 -0500
@@ -112,58 +112,34 @@
 regNum = APIC_SPURIOUS_INTERRUPT_VECTOR;
 break;
   case 0x100:
-  case 0x108:
   case 0x110:
-  case 0x118:
   case 0x120:
-  case 0x128:
   case 0x130:
-  case 0x138:
   case 0x140:
-  case 0x148:
   case 0x150:
-  case 0x158:
   case 0x160:
-  case 0x168:
   case 0x170:
-  case 0x178:
-regNum = APIC_IN_SERVICE((paddr - 0x100) / 0x8);
+regNum = APIC_IN_SERVICE((paddr - 0x100) / 0x10);
 break;
   case 0x180:
-  case 0x188:
   case 0x190:
-  case 0x198:
   case 0x1A0:
-  case 0x1A8:
   case 0x1B0:
-  case 0x1B8:
   case 0x1C0:
-  case 0x1C8:
   case 0x1D0:
-  case 0x1D8:
   case 0x1E0:
-  case 0x1E8:
   case 0x1F0:
-  case 0x1F8:
-regNum = APIC_TRIGGER_MODE((paddr - 0x180) / 0x8);
+regNum = APIC_TRIGGER_MODE((paddr - 0x180) / 0x10);
 break;
   case 0x200:
-  case 0x208:
   case 0x210:
-  case 0x218:
   case 0x220:
-  case 0x228:
   case 0x230:
-  case 0x238:
   case 0x240:
-  case 0x248:
   case 0x250:
-  case 0x258:
   case 0x260:
-  case 0x268:
   case 0x270:
-  case 0x278:
-regNum = APIC_INTERRUPT_REQUEST((paddr - 0x200) / 0x8);
+regNum = APIC_INTERRUPT_REQUEST((paddr - 0x200) / 0x10);
 break;
   case 0x280:
 regNum = APIC_ERROR_STATUS;
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: dev, virtio: properly set PCI address space t...

[Bjoern A. Zeeb]

changeset c926270c33c8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c926270c33c8
description:
dev, virtio: properly set PCI address space to use IOREG

VirtIO spec < 1.0 demands IOREG to be used on PCI and not memory mapped.
Set the correct bit on the PCI address accordingly.

Committed by Jason Lowe-Power 

diffstat:

 src/dev/virtio/VirtIO.py |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 54cf9a388a9d -r c926270c33c8 src/dev/virtio/VirtIO.py
--- a/src/dev/virtio/VirtIO.py  Mon May 16 15:36:24 2016 -0400
+++ b/src/dev/virtio/VirtIO.py  Thu May 19 15:19:34 2016 -0500
@@ -65,7 +65,7 @@
 
 ClassCode = 0xff # Misc device
 
-BAR0 = 0x # Anywhere in 32-bit space
+BAR0 = 0x0001 # Anywhere in 32-bit space; IOREG
 BAR0Size = '0B' # Overridden by the device model
 
 InterruptPin = 0x01 # Use #INTA
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3375: arm, dev: add (dummy) ISecR support to the PL390 GIC

[Bjoern A. Zeeb]

> On March 15, 2016, 11:13 p.m., Andreas Sandberg wrote:
> > Thanks for looking into this!
> > 
> > I'd suggest that you implement this as a GICv1 without security extensions. 
> > According to the architecture spec, the ICDISRn registers should be RAZ/WI 
> > in that case, so no need to store additional state.
> 
> Bjoern A. Zeeb wrote:
> Well the problem seems to be that a pfr(1) returns with & 0x00f0 
> being true, which is how FreeBSD (and probably everyone else) would detect 
> whether SecExt are present.  So I assume we should drop the bits as well from 
> ArmISA.py id_pfr1 ( id_pfr1 = Param.UInt32(0x1011, "Processor Feature 
> Register 1") )?
> At least currently assuming they are not there is not an option.
> 
> Side note: FreeBSD code doesn't all do the right thing everywhere either 
> depending on that flag but for as long as it's there we do and gem5 doesn't.
> 
> Andreas Sandberg wrote:
> Good point. We obviously shouldn't set the TZ bits in PFR unless security 
> extensions have been enabled. I have tasked someone with looking into this 
> issue and I hope to have a patch shortly.
> 
> Andreas Sandberg wrote:
> Ok, I have done some more digging. According to the GICv2 manual:
> 
>   * A processor that implements the ARM Virtualization Extensions must 
> also implement the ARM Security Extensions.
>   * A GIC that implements the GIC Virtualization Extensions is not 
> required to implement the GIC Security Extensions.
> 
> My interpretation of this is that is incorrect for an operating system to 
> assume that the GIC supports security extensions just because the CPU does. 
> (That doesn't mean that we should do the right thing in ID_PFRx though.)
> 
> We are doing a fairly substantial refresh of the GIC code base at the 
> moment and we will implement GICD_IGROUPr (ICDISR) as a GICv1 without 
> security extensions, which would implement a superset of this this patch. I 
> don't have an ETA yet, but I suspect we can post it externally within a 
> couple of weeks.

OK,  I looked at as much bits as I could find.  It seems for the GIC in gem5 
the TYPER (not named that way;  that's a v1 vs. v2 thing I guess) register does 
the right thing and not set the Security Extensions bit.  I have adjusted the 
arm(v6/7) and the armv8 code for the GIC (v1/2) on FreeBSD to check for that 
bit before trying to issue writes for ICDISRn.

With rgards to the CPU I can't say much apart from that wasn't an issue so far. 
 I am certain FreeBSD does not have proper checks for the SecExt being there in 
all places it needs to have them either, but that's not a gem5 issue.

I'll discard this one and upstream the OS improvement after it's been reviewed 
there.   Thanks for pointing out the right GIC bits here.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3375/#review8090
---


On March 15, 2016, 4:58 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3375/
> ---
> 
> (Updated March 15, 2016, 4:58 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm,dev: add (dummy) ISecR support to the PL390 GIC
> 
> Add (dummy) support for Interrupt Security Registers to allow
> software to read/write them even though we do not properly
> implement checks yet.   This avoids hitting panic()s and
> seems to be `good enough' to get certain software running
> happily.
> 
> 
> Diffs
> -
> 
>   src/dev/arm/gic_pl390.hh 2fd64ea0a7cb 
>   src/dev/arm/gic_pl390.cc 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3375/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3466: dev, virtio: properly set PCI address space to use IOREG

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3466/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

dev, virtio: properly set PCI address space to use IOREG

VirtIO spec < 1.0 demands IOREG to be used on PCI and not memory mapped.
Set the correct bit on the PCI address accordingly.


Diffs
-

  src/dev/virtio/VirtIO.py 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3466/diff/


Testing
---

Booted FreeBSD X86, armv7, and arm64 with a VirtIO disk.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3454: misc: Appease clang-3.4.1

[Bjoern A. Zeeb]

> On April 26, 2016, 8:54 p.m., Bjoern A. Zeeb wrote:
> > This was fixed in HEAD after I noticed that we aren't spec compliant; but 
> > older versions indeed need the cast.
> > 
> > I am currently using at least an #ifdef here:
> > 
> > --- a/src/sim/init_signals.cc   Tue Apr 05 08:08:12 2016 -0500
> > +++ b/src/sim/init_signals.cc   Tue Apr 26 20:51:26 2016 +
> > @@ -66,7 +66,11 @@
> >  setupAltStack()
> >  {
> >  stack_t stack;
> > +#ifdef __FreeBSD__
> > +stack.ss_sp = (char *)fatalSigStack;
> > +#else
> >  stack.ss_sp = fatalSigStack;
> > +#endif
> >  stack.ss_size = sizeof(fatalSigStack);
> >  stack.ss_flags = 0;
> > 
> > But for the FreeBSD block we almost also need to check __FreeBSD_version >= 
> > 11xx but I haven't done the due diligence yet what the exact version 
> > number should be.

https://svnweb.freebsd.org/base?view=revision=294930

PS: this has nothing to do with clang really.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3454/#review8274
---


On April 26, 2016, 6:02 p.m., Pierre-Yves Péneau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3454/
> ---
> 
> (Updated April 26, 2016, 6:02 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Appease clang-3.4.1
> 
> 
> Diffs
> -
> 
>   src/sim/init_signals.cc e41eca4aecbb 
> 
> Diff: http://reviews.gem5.org/r/3454/diff/
> 
> 
> Testing
> ---
> 
> Fresh install of FreeBSD 10.3-RELEASE (i386), default clang compiler (3.4.1)
> 
> 
> Thanks,
> 
> Pierre-Yves Péneau
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3454: misc: Appease clang-3.4.1

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3454/#review8274
---


This was fixed in HEAD after I noticed that we aren't spec compliant; but older 
versions indeed need the cast.

I am currently using at least an #ifdef here:

--- a/src/sim/init_signals.cc   Tue Apr 05 08:08:12 2016 -0500
+++ b/src/sim/init_signals.cc   Tue Apr 26 20:51:26 2016 +
@@ -66,7 +66,11 @@
 setupAltStack()
 {
 stack_t stack;
+#ifdef __FreeBSD__
+stack.ss_sp = (char *)fatalSigStack;
+#else
 stack.ss_sp = fatalSigStack;
+#endif
 stack.ss_size = sizeof(fatalSigStack);
 stack.ss_flags = 0;

But for the FreeBSD block we almost also need to check __FreeBSD_version >= 
11xx but I haven't done the due diligence yet what the exact version number 
should be.

- Bjoern A. Zeeb


On April 26, 2016, 6:02 p.m., Pierre-Yves Péneau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3454/
> ---
> 
> (Updated April 26, 2016, 6:02 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Appease clang-3.4.1
> 
> 
> Diffs
> -
> 
>   src/sim/init_signals.cc e41eca4aecbb 
> 
> Diff: http://reviews.gem5.org/r/3454/diff/
> 
> 
> Testing
> ---
> 
> Fresh install of FreeBSD 10.3-RELEASE (i386), default clang compiler (3.4.1)
> 
> 
> Thanks,
> 
> Pierre-Yves Péneau
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3194: config, x86: Properly space pad the X86IntelMPBus Entry descriptions.

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3194/
---

(Updated April 20, 2016, 12:56 p.m.)


Review request for Default, Jason Lowe-Power and Steve Reinhardt.


Summary (updated)
-

config, x86: Properly space pad the X86IntelMPBus Entry descriptions.


Repository: gem5


Description
---

According to the Intel Multi Processor Specification rev 1.4 (-006) (*), 
section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII 
(blank-filled) strings<<.
Properly pad the entries with the missing spaces at the end.

(*) http://www.intel.com/design/pentium/datashts/24201606.pdf


Diffs
-

  configs/common/FSConfig.py 9c7b55faea5d 
  src/arch/x86/bios/IntelMP.py 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3194/diff/


Testing
---

Booting FreeBSD in FS mode no longer complains about unknown busses "PCI" and 
"ISA".


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Does anyone care about X86 ISA simulations?

[Bjoern A. Zeeb]

On Wed, 13 Apr 2016, Steve Reinhardt wrote:

Hi,


Everything else you mention sounds like a real bug though.  FP support
(esp. x87 rather than SSE) has never been all that solid.  Are you using my
locked access patch (http://reviews.gem5.org/r/2691/)?  If not, atomic
accesses are not truly atomic with the O3 CPU, which could be causing some
problems.


I tried your updated patch.  Thanks for that!
Unfortunately it doesn't cause a change in behaviour for the problem I
am still seeing.  I'll try to get an excessive trace out again to analyze
the panic on a nofault entry.

Bjoern
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: arm, dev: remove PMU assertion hit on reset

[Bjoern A. Zeeb]

changeset 717172baf4dd in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=717172baf4dd
description:
arm,dev: remove PMU assertion hit on reset

Remve the assertion that we always need to add a delta larger than
zero as that does not seem to be true when we hit it in the
'PMU reset cycle counter to zero' case.

Committed by Jason Lowe-Power 

diffstat:

 src/arch/arm/pmu.cc |  2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diffs (12 lines):

diff -r ae6e3dd1c32c -r 717172baf4dd src/arch/arm/pmu.cc
--- a/src/arch/arm/pmu.cc   Fri Apr 15 10:02:58 2016 -0500
+++ b/src/arch/arm/pmu.cc   Fri Apr 15 10:03:03 2016 -0500
@@ -574,8 +574,6 @@
 const uint64_t msb(1ULL << (overflow64 ? 63 : 31));
 const uint64_t old_value(value);
 
-assert(delta > 0);
-
 value += delta;
 
 // Overflow if the msb goes from 1 to 0
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: FreeBSD does not provide MAP_NORESERVE e...

[Bjoern A. Zeeb]

changeset ae6e3dd1c32c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ae6e3dd1c32c
description:
mem: FreeBSD does not provide MAP_NORESERVE either

Like OS X, FreeBSD does not support MAP_NORESERVE.
Handle accordingly and update comment.

Committed by Jason Lowe-Power 

diffstat:

 src/mem/physical.cc |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diffs (17 lines):

diff -r a89bc3bc9f1e -r ae6e3dd1c32c src/mem/physical.cc
--- a/src/mem/physical.cc   Fri Apr 15 09:55:26 2016 -0500
+++ b/src/mem/physical.cc   Fri Apr 15 10:02:58 2016 -0500
@@ -59,10 +59,10 @@
 /**
  * On Linux, MAP_NORESERVE allow us to simulate a very large memory
  * without committing to actually providing the swap space on the
- * host. On OSX the MAP_NORESERVE flag does not exist, so simply make
- * it 0.
+ * host. On FreeBSD or OSX the MAP_NORESERVE flag does not exist,
+ * so simply make it 0.
  */
-#if defined(__APPLE__)
+#if defined(__APPLE__) || defined(__FreeBSD__)
 #ifndef MAP_NORESERVE
 #define MAP_NORESERVE 0
 #endif
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2691: mem: implement x86 locked accesses in timing-mode classic cache

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2691/#review8197
---


Can you please update it?
It neither applies cleanly nor does it compile afterwards.

- Bjoern A. Zeeb


On Jan. 19, 2016, 3:46 a.m., Steve Reinhardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2691/
> ---
> 
> (Updated Jan. 19, 2016, 3:46 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10745:9b84d1b570e3
> ---
> mem: implement x86 locked accesses in timing-mode classic cache
> 
> Add LockedRMW(Read|Write)(Req|Resp) commands.  In timing mode,
> use a combination of clearing permission bits and leaving
> an MSHR in place to prevent accesses & snoops from touching
> a locked block between the read and write parts of an locked
> RMW sequence.
> 
> 
> Diffs
> -
> 
>   src/mem/packet.cc d06e5a6b4b7f05a642c3e2bee12cfeb130dede16 
>   src/mem/cache/cache.cc d06e5a6b4b7f05a642c3e2bee12cfeb130dede16 
>   src/mem/cache/mshr.hh d06e5a6b4b7f05a642c3e2bee12cfeb130dede16 
>   src/mem/packet.hh d06e5a6b4b7f05a642c3e2bee12cfeb130dede16 
> 
> Diff: http://reviews.gem5.org/r/2691/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steve Reinhardt
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/
---

(Updated April 13, 2016, 2:18 p.m.)


Review request for Default.


Changes
---

Update the diff addressing the test case and using a different strategy for the 
FreeBSD specific bits


Repository: gem5


Description
---

scons: make build better on FreeBSD

Various changes we found needed to build gem5 successfully on
FreeBSD.


Diffs (updated)
-

  SConstruct 9c7b55faea5d 
  tests/SConscript 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3378/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3194: Properly space pad the X86IntelMPBus Entry descriptions.

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3194/
---

(Updated April 13, 2016, 2:23 p.m.)


Review request for Default, Jason Lowe-Power and Steve Reinhardt.


Changes
---

Update diff.  Be careful given the "whitespace only" changes in FSConfig.py are 
the actual changes!


Repository: gem5


Description
---

According to the Intel Multi Processor Specification rev 1.4 (-006) (*), 
section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII 
(blank-filled) strings<<.
Properly pad the entries with the missing spaces at the end.

(*) http://www.intel.com/design/pentium/datashts/24201606.pdf


Diffs (updated)
-

  configs/common/FSConfig.py 9c7b55faea5d 
  src/arch/x86/bios/IntelMP.py 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3194/diff/


Testing
---

Booting FreeBSD in FS mode no longer complains about unknown busses "PCI" and 
"ISA".


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3447: x86, dev: properly space the APIC registers

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3447/
---

Review request for Default, Jason Lowe-Power and Steve Reinhardt.


Repository: gem5


Description
---

x86, dev: properly space the APIC registers

Registers are 0x10 and not 0x8 apart.  The latter leads to invalid calculations 
of index in array which in turn means that we will not find the interrupt we 
were looking (been notified) for in the OS.


Diffs
-

  src/arch/x86/interrupts.cc 9c7b55faea5d 

Diff: http://reviews.gem5.org/r/3447/diff/


Testing
---

Testing done on FreeBSD amd64 FS boot.
Testing not done for Linux.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3194: Properly space pad the X86IntelMPBus Entry descriptions.

[Bjoern A. Zeeb]

> On Nov. 5, 2015, 3:21 p.m., Nilay Vaish wrote:
> > src/arch/x86/bios/IntelMP.py, lines 118-122
> > <http://reviews.gem5.org/r/3194/diff/2/?file=51397#file51397line118>
> >
> > This is a comment.  I don't see how changing it helps.  I would rather 
> > add the "6 byte" comment near the changes made to FSConfig.py.   Also 
> > should we add a check in the corresponding c++ class?

I am indifferent on fixing the comments or removing the quotes around them, or 
just adding the note about "space padded to 6 bytes".


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3194/#review7494
---


On Nov. 4, 2015, 2:51 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3194/
> ---
> 
> (Updated Nov. 4, 2015, 2:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> According to the Intel Multi Processor Specification rev 1.4 (-006) (*), 
> section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII 
> (blank-filled) strings<<.
> Properly pad the entries with the missing spaces at the end.
> 
> (*) http://www.intel.com/design/pentium/datashts/24201606.pdf
> 
> 
> Diffs
> -
> 
>   src/arch/x86/bios/IntelMP.py 2d1d51615e0e 
>   configs/common/FSConfig.py 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3194/diff/
> 
> 
> Testing
> ---
> 
> Booting FreeBSD in FS mode no longer complains about unknown busses "PCI" and 
> "ISA".
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Does anyone care about X86 ISA simulations?

[Bjoern A. Zeeb]

On Mon, 11 Apr 2016, Jason Lowe-Power wrote:

Hi Jason,

thanks for that quick reply.


There are a number of people who use x86 with gem5. Personally, I use x86
almost exclusively. As I'm sure you know, the initial full-system support
was geared towards Linux. My experience is that x86+Linux works pretty well
(functionally at least). We have run into a number of x86 bugs over the
years, but from my point of view, it's pretty stable. However, I'll admit
I'm mostly interested in the memory system, not the core microarchitecture.
I haven't spent much time doing performance debugging of the core. I'm
happy if it can issue one memory request per cycle.

Additionally, I believe the folks at AMD who use gem5 are primarily using
the x86 ISA. However, I shouldn't speak for them :).

What kinds of problems are you running into? Mostly issues with the system
support (interrupts, APIC, etc)? Or are you actually finding issues with
the instruction implementations?


Just a few things from the top of my head:

Floating point bits crashing gem5 (these I hacked around as I don't
need the actual values saved and restored).  That's some memory
corruption going on there (cvtfp80h_int, cvtfp80l_int).  I can go and
debug this if someone is interested enough to review the diff later
on and get it in.

The bus space identifieres were not padded to 6 bytes white space
violating the spec (I have an old review around, which I couldn't
test on Linux; like none of my other chnages;  I should probably get
a test setup but ...)

The CPUID values are partialy just fantasy and not backed by actual
implementations.

Whoever started to add the ACPI bit, saying "hey we support this" must
have had a very special use case ;-)  Would be really good if
someone(tm) would actually start providing these bits as it might make
a few things easier;  I think FreeBSD's bhyve has a minimalistic BSD
licensed implementation which might be interesting;  I guess aarch64
will want to support that some time as well?

x86/interrupts.cc has the wrong offset calculations in one direction,
so the APIC bits can never have worked in any proper way.  I'll post a
patch to review for that soon.

I posted a patch for a TLB issue, which is in review, where adding a
large page after a regular page would not be handled correctly.

I have hit 1-2-3 assertions somewhere in the code, which I generously
started to ignore but probably someone(tm) should look at it with me
and decide the right way forward.

I am still hunting a different what looks like a TLB bug as I am
getting a page fault on a no-fault address.  It's been a while since I
looked at the trace (and I'll try to get a new clean one), but there
was a "tick" completely out of sequence in the Exec trace, which to my
understanding should not happen. So could also be an O3 bug, as the
same code works with the "timing" model for X86_64 w/o problem.


And then there was a bit of UART fun; ATA (IDE) I gave up on and
started to use virtio instead as it was so utterly old and not quite
to spec, ..

I'd have to go back and see what else.  I've lately cleaned up my
patchset so expect some bits;  if you (or someone else can help me to
check that whatever Linux/X86 people are using doesn't get broken by
them, that would be super helpful) as the more I get the patches out
of my tree, the more I can focus on my actual work and analysing the
remaining problems.  And I am happy to take that testing bits off the
mailing list ;-)


Bjoern
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

> On March 20, 2016, 11:42 a.m., Andreas Hansson wrote:
> > SConstruct, line 798
> > <http://reviews.gem5.org/r/3378/diff/1/?file=54100#file54100line798>
> >
> > i am surprised to not see this change in util/regress as well
> > 
> > should we parametrise the name rather?

Are you thinking about tests/SConscript maybe?


> On March 20, 2016, 11:42 a.m., Andreas Hansson wrote:
> > SConstruct, line 964
> > <http://reviews.gem5.org/r/3378/diff/1/?file=54100#file54100line964>
> >
> > should we just replace the check for message.h rather?

Seems with a recent library version the extra check is no longer needed.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review8101
-------


On March 15, 2016, 5:01 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated March 15, 2016, 5:01 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3376: arm, dev: PL011 UART_FR read status enhancement

[Bjoern A. Zeeb]

> On March 15, 2016, 9 p.m., Andreas Sandberg wrote:
> > Looks fine to me. Could you make sure that this doesn't break Linux? (I 
> > assume you have mainly tested with *BSD.)

I am not setup to test with Linux currently and I also don't have the resources 
to easily do this.   If it's crusial and people can't apply the patch to their 
local tree and see, I'll find a way.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3376/#review8089
---


On March 15, 2016, 4:59 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3376/
> ---
> 
> (Updated March 15, 2016, 4:59 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm,dev: PL011 UART_FR read status enhancement
> 
> Given we do not simulate a FIFO currently there are only two states
> we can be in upon read: empty or full.  Properly signal the latter.
> 
> Add and sort constants for states in the header file.
> 
> 
> Diffs
> -
> 
>   src/dev/arm/pl011.hh 2fd64ea0a7cb 
>   src/dev/arm/pl011.cc 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3376/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3377: arm, dev, config: always preent the PMU but add option to enable

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3377/
---

(Updated March 16, 2016, 2:09 p.m.)


Review request for Default and Andreas Sandberg.


Repository: gem5


Description (updated)
---

Changeset 11372:60739171853b
---
arm,dev,config: always preent the PMU but add option to enable

Always attach the PMU to an ARM core but do not enable the
relevant instructions/events unless asked for by setting the
new command line option --pmu.

Note: this should work fine for 1 core systems, for multi-core
there might be an interrupt delivery issue still (SPI vs. PPI).
Consider this as an example for people who want to work on it
as the question has previously come up on the mailing lists on
how to hook this up.


Diffs (updated)
-

  configs/common/Options.py 2fd64ea0a7cb 
  configs/example/fs.py 2fd64ea0a7cb 
  src/arch/arm/ArmISA.py 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3377/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3375: arm, dev: add (dummy) ISecR support to the PL390 GIC

[Bjoern A. Zeeb]

> On March 15, 2016, 11:13 p.m., Andreas Sandberg wrote:
> > Thanks for looking into this!
> > 
> > I'd suggest that you implement this as a GICv1 without security extensions. 
> > According to the architecture spec, the ICDISRn registers should be RAZ/WI 
> > in that case, so no need to store additional state.

Well the problem seems to be that a pfr(1) returns with & 0x00f0 being 
true, which is how FreeBSD (and probably everyone else) would detect whether 
SecExt are present.  So I assume we should drop the bits as well from ArmISA.py 
id_pfr1 ( id_pfr1 = Param.UInt32(0x1011, "Processor Feature Register 1") )?
At least currently assuming they are not there is not an option.

Side note: FreeBSD code doesn't all do the right thing everywhere either 
depending on that flag but for as long as it's there we do and gem5 doesn't.


> On March 15, 2016, 11:13 p.m., Andreas Sandberg wrote:
> > src/dev/arm/gic_pl390.cc, line 410
> > <http://reviews.gem5.org/r/3375/diff/1/?file=54094#file54094line410>
> >
> > Isn't there some code missing here?

Yes I know.  I had not intentions to do the 100% right thing throughout the 
entire ARM platform.  I am just working around my problem and leaving the 
comment for someone to finish the work who knows better and can test better 
than I can ;-)


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3375/#review8090
---


On March 15, 2016, 4:58 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3375/
> ---
> 
> (Updated March 15, 2016, 4:58 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm,dev: add (dummy) ISecR support to the PL390 GIC
> 
> Add (dummy) support for Interrupt Security Registers to allow
> software to read/write them even though we do not properly
> implement checks yet.   This avoids hitting panic()s and
> seems to be `good enough' to get certain software running
> happily.
> 
> 
> Diffs
> -
> 
>   src/dev/arm/gic_pl390.hh 2fd64ea0a7cb 
>   src/dev/arm/gic_pl390.cc 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3375/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3377: arm, dev, config: always preent the PMU but add option to enable

[Bjoern A. Zeeb]

> On March 15, 2016, 8:54 p.m., Andreas Sandberg wrote:
> > src/arch/arm/ArmISA.py, line 55
> > <http://reviews.gem5.org/r/3377/diff/1/?file=54099#file54099line55>
> >
> > This is a bit scary since the PMU is needs to know which interrupt to 
> > use and that's generally defined by the platform code (see 
> > src/dev/arm/ReaView.py). Ideally, this device should live with the other 
> > platform devices, but I'm not sure how we would wire it to the ISA in that 
> > case.

I had actually tried to hook the pmu up from other code rather than changing 
the NULL here, which wasn't successful.  If anyone knows a good way how to do 
it I'll be more than happy to.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3377/#review8088
---


On March 15, 2016, 5 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3377/
> ---
> 
> (Updated March 15, 2016, 5 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm,dev,config: always preent the PMU but add option to enable
> 
> Always attach the PMU to an ARM core but do not enable the
> relevant instructions/events unless asked for by setting the
> new command line option --pmu.
> 
> Note: this should work fine for 1 core systems, for multi-core
> there might be an interrupt delivery issue still (SPI vs. PPI).
> Consider this as an example for people who want to work on it
> as the question has previously come up on the mailing lists on
> how to hook this up.
> 
> 
> Diffs
> -
> 
>   configs/common/Options.py 2fd64ea0a7cb 
>   configs/example/fs.py 2fd64ea0a7cb 
>   src/arch/arm/ArmISA.py 2fd64ea0a7cb 
> 
> Diff: http://reviews.gem5.org/r/3377/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3378: scons: make build better on FreeBSD

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/
---

Review request for Default.


Repository: gem5


Description
---

scons: make build better on FreeBSD

Various changes we found needed to build gem5 successfully on
FreeBSD.


Diffs
-

  SConstruct 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3378/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3377: arm, dev, config: always preent the PMU but add option to enable

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3377/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

arm,dev,config: always preent the PMU but add option to enable

Always attach the PMU to an ARM core but do not enable the
relevant instructions/events unless asked for by setting the
new command line option --pmu.

Note: this should work fine for 1 core systems, for multi-core
there might be an interrupt delivery issue still (SPI vs. PPI).
Consider this as an example for people who want to work on it
as the question has previously come up on the mailing lists on
how to hook this up.


Diffs
-

  configs/common/Options.py 2fd64ea0a7cb 
  configs/example/fs.py 2fd64ea0a7cb 
  src/arch/arm/ArmISA.py 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3377/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3376: arm, dev: PL011 UART_FR read status enhancement

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3376/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

arm,dev: PL011 UART_FR read status enhancement

Given we do not simulate a FIFO currently there are only two states
we can be in upon read: empty or full.  Properly signal the latter.

Add and sort constants for states in the header file.


Diffs
-

  src/dev/arm/pl011.hh 2fd64ea0a7cb 
  src/dev/arm/pl011.cc 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3376/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3375: arm, dev: add (dummy) ISecR support to the PL390 GIC

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3375/
---

Review request for Default and Andreas Sandberg.


Repository: gem5


Description
---

arm,dev: add (dummy) ISecR support to the PL390 GIC

Add (dummy) support for Interrupt Security Registers to allow
software to read/write them even though we do not properly
implement checks yet.   This avoids hitting panic()s and
seems to be `good enough' to get certain software running
happily.


Diffs
-

  src/dev/arm/gic_pl390.hh 2fd64ea0a7cb 
  src/dev/arm/gic_pl390.cc 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3375/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3372: mem: FreeBSD does not provide MAP_NORESERVE either

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3372/
---

Review request for Default.


Repository: gem5


Description
---

mem: FreeBSD does not provide MAP_NORESERVE either

Like OS X, FreeBSD does not support MAP_NORESERVE.
Handle accordingly and update comment.


Diffs
-

  src/mem/physical.cc 2fd64ea0a7cb 

Diff: http://reviews.gem5.org/r/3372/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3196: tcp_iface.cc does not compile on FreeBSD

[Bjoern A. Zeeb]

> On Nov. 5, 2015, 3:44 p.m., Andreas Hansson wrote:
> > I'd suggest we roll this up with the updates to the distributed gem5 
> > functionality (soon on the reviewboard). Thanks for pointing it out.

Seems this was committed with changeset 11290.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3196/#review7498
---


On Nov. 4, 2015, 2:39 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3196/
> ---
> 
> (Updated Nov. 4, 2015, 2:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> To compile tcp_iface.cc on FreeBSD we also need to include netinet/in.h.  Do 
> so conditinally for FreeBSD.
> 
> 
> Diffs
> -
> 
>   src/dev/tcp_iface.cc 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3196/diff/
> 
> 
> Testing
> ---
> 
> Compiles now.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3248: arm: Ship Linux device trees with gem5

[Bjoern A. Zeeb]

> On Feb. 15, 2016, 10:14 p.m., Bjoern A. Zeeb wrote:
> > There are systems when you actually want to keep the pre-processed .dts 
> > files around;  e.g. not supporting the boot loader bits I can compile the 
> > DT into the kernel from the DTS files.
> > 
> > Add -P to the CPP flags to remove all the #cpp_left_behind lines.
> > 
> > I ended up using this today (sure not the most elegant solution):
> > 
> > --- Makefile.orig   2016-02-15 22:11:03.036374000 +
> > +++ Makefile2016-02-15 14:56:23.160107000 +
> > @@ -40,7 +40,7 @@ TARGETS=\
> > armv8_gem5_v1_16cpu.dtb
> > 
> >  GEN_DTS=mkdir -p .gen; \
> > -   $(CPP) -x assembler-with-cpp \
> > +   $(CPP) -x assembler-with-cpp -P \
> > $(DTC_CPP_FLAGS) \
> > -DCONF_PLATFORM=\"platforms/$(1)\" \
> > -DCONF_CPUS=$(2) \
> > @@ -50,9 +50,11 @@ all: $(TARGETS)
> > 
> >  .gen/armv7_gem5_v1_%cpu.dts: armv7.dts platforms/vexpress_gem5_v1.dtsi
> > $(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
> > +   cp -p $@ .
> > 
> >  .gen/armv8_gem5_v1_%cpu.dts: armv8.dts platforms/vexpress_gem5_v1.dtsi
> > $(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
> > +   cp -p $@ .
> > 
> >  %.dtb: .gen/%.dts
> > $(DTC) -I dts -O dtb -o $@ $<
> > @@ -60,4 +62,4 @@ all: $(TARGETS)
> > 
> >  clean:
> > $(RM) -r .gen
> > -   $(RM) *.dtb
> > +   $(RM) *.dtb armv?_gem5_v1_*.dts
> 
> Bjoern A. Zeeb wrote:
> Ignore my changes for now.  Let's get yours in.  They seem to work for me 
> as well (the 1CPU config).

And I should say with some editing due to FreeBSD FDT handling specifics.  But 
they are clearly better than the old ones in the linux github tree.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3248/#review8013
---


On Dec. 8, 2015, 10:59 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3248/
> ---
> 
> (Updated Dec. 8, 2015, 10:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11243:68bbd5bbe86f
> ---
> arm: Ship Linux device trees with gem5
> 
> Ship aarch32 and aarch64 device trees with gem5. We currently ship
> device trees as a part of the gem5 Linux kernel repository. This makes
> tracking hard since device trees are supposed to be platform dependent
> rather than kernel dependent (Linux considers device trees to be a
> stable kernel ABI). It also makes code sharing between aarch32 and
> aarch64 impossible.
> 
> This changeset implements a set of device trees for the new
> VExpress_GEM5_V1 platform. The platform is described in a shared file
> that is separate from the memory/CPU description. Due to differences
> in how secondary CPUs are initialized, aarch32 and aarch64 use
> different base files describing CPU nodes and the machine's
> compatibility property.
> 
> 
> Diffs
> -
> 
>   system/arm/dt/platforms/vexpress_gem5_v1.dtsi PRE-CREATION 
>   system/arm/dt/Makefile PRE-CREATION 
>   system/arm/dt/armv7.dts PRE-CREATION 
>   system/arm/dt/armv8.dts PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3248/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3248: arm: Ship Linux device trees with gem5

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3248/#review8018
---

Ship it!


Ship It!

- Bjoern A. Zeeb


On Dec. 8, 2015, 10:59 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3248/
> ---
> 
> (Updated Dec. 8, 2015, 10:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11243:68bbd5bbe86f
> ---
> arm: Ship Linux device trees with gem5
> 
> Ship aarch32 and aarch64 device trees with gem5. We currently ship
> device trees as a part of the gem5 Linux kernel repository. This makes
> tracking hard since device trees are supposed to be platform dependent
> rather than kernel dependent (Linux considers device trees to be a
> stable kernel ABI). It also makes code sharing between aarch32 and
> aarch64 impossible.
> 
> This changeset implements a set of device trees for the new
> VExpress_GEM5_V1 platform. The platform is described in a shared file
> that is separate from the memory/CPU description. Due to differences
> in how secondary CPUs are initialized, aarch32 and aarch64 use
> different base files describing CPU nodes and the machine's
> compatibility property.
> 
> 
> Diffs
> -
> 
>   system/arm/dt/platforms/vexpress_gem5_v1.dtsi PRE-CREATION 
>   system/arm/dt/Makefile PRE-CREATION 
>   system/arm/dt/armv7.dts PRE-CREATION 
>   system/arm/dt/armv8.dts PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3248/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3248: arm: Ship Linux device trees with gem5

[Bjoern A. Zeeb]

> On Feb. 15, 2016, 10:14 p.m., Bjoern A. Zeeb wrote:
> > There are systems when you actually want to keep the pre-processed .dts 
> > files around;  e.g. not supporting the boot loader bits I can compile the 
> > DT into the kernel from the DTS files.
> > 
> > Add -P to the CPP flags to remove all the #cpp_left_behind lines.
> > 
> > I ended up using this today (sure not the most elegant solution):
> > 
> > --- Makefile.orig   2016-02-15 22:11:03.036374000 +
> > +++ Makefile2016-02-15 14:56:23.160107000 +
> > @@ -40,7 +40,7 @@ TARGETS=\
> > armv8_gem5_v1_16cpu.dtb
> > 
> >  GEN_DTS=mkdir -p .gen; \
> > -   $(CPP) -x assembler-with-cpp \
> > +   $(CPP) -x assembler-with-cpp -P \
> > $(DTC_CPP_FLAGS) \
> > -DCONF_PLATFORM=\"platforms/$(1)\" \
> > -DCONF_CPUS=$(2) \
> > @@ -50,9 +50,11 @@ all: $(TARGETS)
> > 
> >  .gen/armv7_gem5_v1_%cpu.dts: armv7.dts platforms/vexpress_gem5_v1.dtsi
> > $(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
> > +   cp -p $@ .
> > 
> >  .gen/armv8_gem5_v1_%cpu.dts: armv8.dts platforms/vexpress_gem5_v1.dtsi
> > $(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
> > +   cp -p $@ .
> > 
> >  %.dtb: .gen/%.dts
> > $(DTC) -I dts -O dtb -o $@ $<
> > @@ -60,4 +62,4 @@ all: $(TARGETS)
> > 
> >  clean:
> > $(RM) -r .gen
> > -   $(RM) *.dtb
> > +   $(RM) *.dtb armv?_gem5_v1_*.dts

Ignore my changes for now.  Let's get yours in.  They seem to work for me as 
well (the 1CPU config).


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3248/#review8013
---


On Dec. 8, 2015, 10:59 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3248/
> ---
> 
> (Updated Dec. 8, 2015, 10:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11243:68bbd5bbe86f
> ---
> arm: Ship Linux device trees with gem5
> 
> Ship aarch32 and aarch64 device trees with gem5. We currently ship
> device trees as a part of the gem5 Linux kernel repository. This makes
> tracking hard since device trees are supposed to be platform dependent
> rather than kernel dependent (Linux considers device trees to be a
> stable kernel ABI). It also makes code sharing between aarch32 and
> aarch64 impossible.
> 
> This changeset implements a set of device trees for the new
> VExpress_GEM5_V1 platform. The platform is described in a shared file
> that is separate from the memory/CPU description. Due to differences
> in how secondary CPUs are initialized, aarch32 and aarch64 use
> different base files describing CPU nodes and the machine's
> compatibility property.
> 
> 
> Diffs
> -
> 
>   system/arm/dt/platforms/vexpress_gem5_v1.dtsi PRE-CREATION 
>   system/arm/dt/Makefile PRE-CREATION 
>   system/arm/dt/armv7.dts PRE-CREATION 
>   system/arm/dt/armv8.dts PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3248/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3248: arm: Ship Linux device trees with gem5

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3248/#review8013
---


There are systems when you actually want to keep the pre-processed .dts files 
around;  e.g. not supporting the boot loader bits I can compile the DT into the 
kernel from the DTS files.

Add -P to the CPP flags to remove all the #cpp_left_behind lines.

I ended up using this today (sure not the most elegant solution):

--- Makefile.orig   2016-02-15 22:11:03.036374000 +
+++ Makefile2016-02-15 14:56:23.160107000 +
@@ -40,7 +40,7 @@ TARGETS=\
armv8_gem5_v1_16cpu.dtb

 GEN_DTS=mkdir -p .gen; \
-   $(CPP) -x assembler-with-cpp \
+   $(CPP) -x assembler-with-cpp -P \
$(DTC_CPP_FLAGS) \
-DCONF_PLATFORM=\"platforms/$(1)\" \
-DCONF_CPUS=$(2) \
@@ -50,9 +50,11 @@ all: $(TARGETS)

 .gen/armv7_gem5_v1_%cpu.dts: armv7.dts platforms/vexpress_gem5_v1.dtsi
$(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
+   cp -p $@ .

 .gen/armv8_gem5_v1_%cpu.dts: armv8.dts platforms/vexpress_gem5_v1.dtsi
$(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
+   cp -p $@ .

 %.dtb: .gen/%.dts
$(DTC) -I dts -O dtb -o $@ $<
@@ -60,4 +62,4 @@ all: $(TARGETS)

 clean:
$(RM) -r .gen
-   $(RM) *.dtb
+   $(RM) *.dtb armv?_gem5_v1_*.dts

- Bjoern A. Zeeb


On Dec. 8, 2015, 10:59 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3248/
> ---
> 
> (Updated Dec. 8, 2015, 10:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11243:68bbd5bbe86f
> ---
> arm: Ship Linux device trees with gem5
> 
> Ship aarch32 and aarch64 device trees with gem5. We currently ship
> device trees as a part of the gem5 Linux kernel repository. This makes
> tracking hard since device trees are supposed to be platform dependent
> rather than kernel dependent (Linux considers device trees to be a
> stable kernel ABI). It also makes code sharing between aarch32 and
> aarch64 impossible.
> 
> This changeset implements a set of device trees for the new
> VExpress_GEM5_V1 platform. The platform is described in a shared file
> that is separate from the memory/CPU description. Due to differences
> in how secondary CPUs are initialized, aarch32 and aarch64 use
> different base files describing CPU nodes and the machine's
> compatibility property.
> 
> 
> Diffs
> -
> 
>   system/arm/dt/platforms/vexpress_gem5_v1.dtsi PRE-CREATION 
>   system/arm/dt/Makefile PRE-CREATION 
>   system/arm/dt/armv7.dts PRE-CREATION 
>   system/arm/dt/armv8.dts PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3248/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] tinderbox? building universe?

[Bjoern A. Zeeb]

Hi,

private reply.

> On 03 Jan 2016, at 10:50 , Andreas Hansson  wrote:
> 
> Hi Bjoern,
> 
> All architectures are built and tested on a daily basis, but unfortunately
> only using gcc 4.7 at this point. This is done by the util/regress script,
> which by default builds all architectures and Ruby protocols, and when
> passed “all” runs all regressions.
> 
> The snipped you include builds fine on gcc 4.7, 4.8 and I think even 4.9
> without the override. It is only gcc 5 and clang that warns about this.
> Admittedly it would be nice to build gem5 against all supported
> combinations of tools on a regular basis, but that is unfortunately not
> done at this time.

I see.  Thanks a lot for your reply.  I’ll try to send patches, as I have MIPS 
compiling with clang on FreeBSD HEAD as of last night.  Only took 90 minutes to 
fix everything and push it through :)

Is that regression script available somewhere in the gem5 repo?  I am wondering 
if I can run it once in a while on a FreeBSD HEAD machine and deal with the 
results or at least feed them back?Resources are a bit limited but if there 
are spare cycles, why not use them.   Would that be helpful?


Greetings,
Bjoern
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] tinderbox? building universe?

[Bjoern A. Zeeb]

Hi,

trying to build MIPS I noticed that certain architectures are simply ignored?

# grep takeOverFrom src/arch/*/tlb.hh
src/arch/alpha/tlb.hh:void takeOverFrom(BaseTLB *otlb) override {}
src/arch/arm/tlb.hh:void takeOverFrom(BaseTLB *otlb) override;
src/arch/arm/tlb.hh: * port connections during a CPU takeOverFrom() call. 
For
src/arch/generic/tlb.hh:virtual void takeOverFrom(BaseTLB *otlb) = 0;
src/arch/generic/tlb.hh: * migrating port connections during a CPU 
takeOverFrom()
src/arch/mips/tlb.hh:void takeOverFrom(BaseTLB *otlb) {}
src/arch/power/tlb.hh:void takeOverFrom(BaseTLB *otlb) {}
src/arch/sparc/tlb.hh:void takeOverFrom(BaseTLB *otlb) {}
src/arch/x86/tlb.hh:void takeOverFrom(BaseTLB *otlb) override {}
src/arch/x86/tlb.hh: * migrating port connections during a CPU 
takeOverFrom()


Neither mips, power, or sparc seem to have the override flag, which to me 
indicates that they are not going to build as-are in the gem5 branch.   Do you 
guys have a buildbot/tinderbox/“make universe” command that does nothing else 
but try to compile all supported combinations at least once a day?  I have seen 
some regression test emails flying by but . . .  how would one run make test on 
something that doesn’t even build?  Do you have a description somewhere what 
that zizzer cronjob does?   Do you have a nice webpage with a status output of 
the combinations which build and which fail tests?


Bjoern
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: util: term: drop CC from Makefile

[Bjoern A. Zeeb]

changeset 8b3c0bd14c01 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8b3c0bd14c01
description:
util: term: drop CC from Makefile

With clang there are systems without gcc being installed anymore and we 
should
not rely on that.  This patch drops CC so that system's default 
compiler is
invoked.

Committed by: Nilay Vaish 

diffstat:

 util/term/Makefile |  1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diffs (11 lines):

diff -r 50a9d73b12d9 -r 8b3c0bd14c01 util/term/Makefile
--- a/util/term/MakefileFri Dec 04 17:20:07 2015 -0600
+++ b/util/term/MakefileFri Dec 04 17:25:45 2015 -0600
@@ -26,7 +26,6 @@
 #
 # Authors: Nathan Binkert
 
-CC= gcc
 CCFLAGS= -g -O0
 
 default: m5term
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3195: gcc is not cc

[Bjoern A. Zeeb]

> On Nov. 10, 2015, 7:25 p.m., Andreas Sandberg wrote:
> > Hi! Thanks for contributing to gem5!
> > 
> > Could you just remove the CC variable instead of changing it to CC? By 
> > doing so, you'll use the system's default compiler (cc in most cases) and 
> > you will be able to override it by setting CC on the command line. Also, 
> > please write a more descriptive commit message. See 
> > http://www.m5sim.org/Submitting_Contributions for details. I'd suggest 
> > using the misc keyword.

Thanks for the pointer.   yes, you can just drop the line.  Seems fine.


- Bjoern A.


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3195/#review7537
-------


On Nov. 4, 2015, 2:36 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3195/
> ---
> 
> (Updated Nov. 4, 2015, 2:36 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> With clang there are systems without "gcc" being installed anymore and we 
> should not rely on that.  Use "cc" instead and make it compile on these 
> systems.
> 
> 
> Diffs
> -
> 
>   util/term/Makefile 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3195/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: x86: cpuid: add family to warn() message

[Bjoern A. Zeeb]

changeset b29d5816936f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b29d5816936f
description:
x86: cpuid: add family to warn() message

doCpuid() has to identical warn messages about unimplemented functions. 
 Add
the family to the log message to make them distinguishable.

Committed by: Nilay Vaish 

diffstat:

 src/arch/x86/cpuid.cc |  6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diffs (23 lines):

diff -r 80e82ce1978d -r b29d5816936f src/arch/x86/cpuid.cc
--- a/src/arch/x86/cpuid.cc Mon Nov 16 04:58:39 2015 -0600
+++ b/src/arch/x86/cpuid.cc Mon Nov 16 04:58:39 2015 -0600
@@ -138,7 +138,8 @@
   case TLB1GBPageInfo:
   case PerformanceInfo:*/
   default:
-warn("x86 cpuid: unimplemented function %u", funcNum);
+warn("x86 cpuid family 0x8000: unimplemented function %u",
+funcNum);
 return false;
 }
 } else if(family == 0x) {
@@ -157,7 +158,8 @@
  0xe7dbfbff, 0x04000209);
 break;
   default:
-warn("x86 cpuid: unimplemented function %u", funcNum);
+warn("x86 cpuid family 0x: unimplemented function %u",
+funcNum);
 return false;
 }
 } else {
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: x86: pagetable walker: fix typo in comment

[Bjoern A. Zeeb]

changeset 80e82ce1978d in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=80e82ce1978d
description:
x86: pagetable walker: fix typo in comment

diffstat:

 src/arch/x86/pagetable_walker.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 646c603c04e2 -r 80e82ce1978d src/arch/x86/pagetable_walker.cc
--- a/src/arch/x86/pagetable_walker.cc  Mon Nov 16 04:58:39 2015 -0600
+++ b/src/arch/x86/pagetable_walker.cc  Mon Nov 16 04:58:39 2015 -0600
@@ -622,7 +622,7 @@
 nextState = Waiting;
 if (timingFault == NoFault) {
 /*
- * Finish the translation. Now that we now the right entry is
+ * Finish the translation. Now that we know the right entry is
  * in the TLB, this should work with no memory accesses.
  * There could be new faults unrelated to the table walk like
  * permissions violations, so we'll need the return value as
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3198: x86/cpuid.cc add "family" to warn() message to make them more useful

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3198/
---

(Updated Nov. 4, 2015, 3:16 p.m.)


Review request for Default.


Repository: gem5


Description
---

doCpuid() has to identical warn messages about unimplemented functions.  Add 
the family to the log message to make them distinguishable.


Diffs
-

  src/arch/x86/cpuid.cc 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3198/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3196: tcp_iface.cc does not compile on FreeBSD

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3196/
---

Review request for Default.


Repository: gem5


Description
---

To compile tcp_iface.cc on FreeBSD we also need to include netinet/in.h.  Do so 
conditinally for FreeBSD.


Diffs
-

  src/dev/tcp_iface.cc 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3196/diff/


Testing
---

Compiles now.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3196: tcp_iface.cc does not compile on FreeBSD

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3196/
---

(Updated Nov. 4, 2015, 2:39 p.m.)


Review request for Default.


Repository: gem5


Description
---

To compile tcp_iface.cc on FreeBSD we also need to include netinet/in.h.  Do so 
conditinally for FreeBSD.


Diffs
-

  src/dev/tcp_iface.cc 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3196/diff/


Testing
---

Compiles now.


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3195: gcc is not cc

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3195/
---

Review request for Default.


Repository: gem5


Description
---

With clang there are systems without "gcc" being installed anymore and we 
should not rely on that.  Use "cc" instead and make it compile on these systems.


Diffs
-

  util/term/Makefile 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3195/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3197: Fix typo

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3197/
---

Review request for Default.


Repository: gem5


Description
---

Now that we know ..


Diffs
-

  src/arch/x86/pagetable_walker.cc 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3197/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3194: Properly space pad the X86IntelMPBus Entry descriptions.

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3194/
---

(Updated Nov. 4, 2015, 2:51 p.m.)


Review request for Default.


Changes
---

Also update the documenting comment in the class.


Repository: gem5


Description
---

According to the Intel Multi Processor Specification rev 1.4 (-006) (*), 
section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII 
(blank-filled) strings<<.
Properly pad the entries with the missing spaces at the end.

(*) http://www.intel.com/design/pentium/datashts/24201606.pdf


Diffs (updated)
-

  src/arch/x86/bios/IntelMP.py 2d1d51615e0e 
  configs/common/FSConfig.py 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3194/diff/


Testing
---

Booting FreeBSD in FS mode no longer complains about unknown busses "PCI" and 
"ISA".


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3198: x86/cpuid.cc add "family" to warn() message to make them more useful

[Bjoern A. Zeeb]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3198/
---

Review request for Default.


Repository: gem5


Description
---

doCpuid() has to identical warn messages about unimplemented functions.  Add 
the family to the log message to make them distinguishable.


Diffs
-

  src/arch/x86/cpuid.cc 2d1d51615e0e 

Diff: http://reviews.gem5.org/r/3198/diff/


Testing
---


Thanks,

Bjoern A. Zeeb

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev