[gem5-dev] Re: For fun x86 bare metal CLs

Cool! Thanks for the updates. Steve On Mon, Jan 24, 2022 at 6:45 AM Gabe Black via gem5-dev wrote: > BTW, I've started trying to get this test program to run to flush out bugs > in our pre-64bit x86 support. It's been very helpful and usable, and I'm > hoping once I get it working (or at

[gem5-dev] Re: deprecating warn_once

syntax, >> warn("xyz"), but that relies on the source location (file, line, >> column which may be iffy) to be unique, which is defeated by, for instance, >> putting multiple warn_once-s in a macro which then all look like they came >> from the location of the macro in the

[gem5-dev] Re: deprecating warn_once

Hi Gabe, Is there a use case for GEM5_ONCE() other than warn_once()? Thanks, Steve On Mon, Jul 26, 2021 at 6:06 PM Gabe Black via gem5-dev wrote: > Hi folks. I'm continuing to research how to turn warn, panic, etc, into > regular functions instead of macros, and one particularly sticky

[gem5-dev] Re: ChunkGenerator granularity, interface

Thanks for the effort, Gabe! I totally agree that making the interface support range-based for loops makes sense. That would be a nice improvement. Having TLBs (or page tables?) support some kind of variable-size chunk loop range object that deals with multiple page sizes, maybe automatically

[gem5-dev] Re: Remove CP annotation support?

I assume this is leftover from Ali's thesis, which sadly did not take the world by storm as it deserved to. So I expect he'd be OK with us getting rid of it, as would I. Steve On Wed, Aug 19, 2020 at 8:57 AM Jason Lowe-Power wrote: > Hi all, > > Generally, I think that any code that doesn't

[gem5-dev] Re: ISA description structure

The original ISA description language has certainly been extended/leveraged way beyond what it was originally designed for. It was written to replace the SimpleScalar Alpha decode logic which was based on cpp macros (!) so it was a big advance at the time, but given the expanded scope of doing

Re: [gem5-dev] RFC: Removing authors from file headers

Agreed, let's get rid of them. I occasionally get direct emails from people who saw my name in the authors list, and even when the attribution is still relevant, it's typically been so long since I wrote that code that I don't remember the details anyway. Git blame is the right tool if you want

Re: [gem5-dev] Turning off the zizzer cron job

I do not look at the emails :). Steve On Fri, Jan 10, 2020 at 3:19 PM Jason Lowe-Power wrote: > Hi all, > > Does anyone have a reason to continue running the nightly > builds/regressions on zizzer? Are the results used by anyone? As far as I > can tell all of the tests either fail, are

Re: [gem5-dev] Alpha ABI?

ers or stack > overflow asking for help getting an ancient Alpha disk image with Parsec on > it running. There's no way it's appropriate to use a disk image, kernel > image, and benchmarks compiled ~10 years ago for research today. > > , > > Jason > > On Tue, Dec 17, 201

Re: [gem5-dev] Alpha ABI?

If I have anything it's on the hard drive of a machine that needs some work before it will even boot, sorry... On Mon, Dec 16, 2019 at 11:19 PM Gabe Black wrote: > Hey, does anybody have some documentation tucked away somewhere which > documents the Alpha ABI? I don't seem to have that

Re: [gem5-dev] Port configuration overhaul

Thanks for digging this up, Jason. I knew this issue had been addressed multiple times before (I think I even had a patch at one point that was a smaller change, but held it off in favor of Andreas's version). I don't know why Andreas's change was never committed either. Anyway, it will be good

[gem5-dev] more on Nate Binkert

Following up on Jason's note to the gem5-dev list, I wanted to share a brief post I wrote for the SIGARCH blog: https://www.sigarch.org/remembering-nathan-binkert I think it's safe to say that gem5 would not exist if it were not for Nate. About 15 years ago, when he was my PhD student at

Re: [gem5-dev] annoying rebuild of swig wrappers during NULL build

Yup, I remember getting frustrated by this and looking into it and realizing that the problem is that the dependencies get reordered. Seemed like the right thing would be to sort the dependencies at the right point so that the insertion order doesn't matter, but I never figured out when or how to

Re: [gem5-dev] scons question

l is to > > make > > > things like redirection, etc., work. We take advantage of that in at > > least > > > one place I've seen, but it might be feasible to remove that and > > specialize > > > env['SPAWN'] in a way that breaks redirection but allows arbitr

Re: [gem5-dev] scons question

#3 is the traditional solution :) On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < anthony.gutier...@amd.com> wrote: > There are a three ways to fix this as far as I can tell: > > 1) Modify our Scons setup to use staged linking. > 2) Recompile your kernel to allow for larger ARG_MAX. > 3)

Re: [gem5-dev] scons question

Agreed. I actually looked into doing this once briefly (primarily to reduce link time), but it looked like it wasn't going to be trivial, so I punted. On Thu, Apr 13, 2017 at 10:09 AM, Andreas Hansson wrote: > The best solution, in my view, would be to link the various

Re: [gem5-dev] Should we reduce testing for poorly supported architectures?

I agree on 1-3 and the list of "poorly supported" ISAs (maybe "minimally supported" would be a better term). On 4, I'm against pulling the tests for O3, since some of the things that O3 implements are only stressed by these ISAs. (SPARC and register windows, for example.) WRT minor, I think

Re: [gem5-dev] nightly regressions

Here's the changeset Andreas was referring to: http://repo.gem5.org/gem5?cmd=changeset;node=b2720503a978 On Tue, Apr 4, 2017 at 9:20 AM, Gabe Black wrote: > I can't add reviewers due to a known issue, but here is the stack of CLs > which fix the regressions: > >

Re: [gem5-dev] Exception in Speculated Instruction?

ach if > > this is in SE mode for instance, and there's nowhere for the full blown > > architectural exception mechanism to send simulated execution to handle > > things. > > > > Gabe > > > > On Fri, Mar 10, 2017 at 3:13 PM, Steve Reinhardt <ste...@gmail.

Re: [gem5-dev] Exception in Speculated Instruction?

; complexity; does x86 have additional code beyond this to handle unaligned > accesses? > > On Fri, Mar 10, 2017 at 5:14 PM, Steve Reinhardt <ste...@gmail.com> wrote: > > > Have you looked at how x86 supports unaligned accesses? The gem5 memory > > system does no

Re: [gem5-dev] Exception in Speculated Instruction?

gt; ld s1,0(a1) < this is executed speculatively, but a1 isn't a valid > address > ... > > Register a1 contains -1 at this point. > > The commit log doesn't show me any information about that last instruction > except for when it is inserted into the ROB, which is why I originall

Re: [gem5-dev] Exception in Speculated Instruction?

The instruction should be marked as causing a fault, but the fault action should not be invoked until the instruction is committed. Because it's a mis-speculated instruction, it will never be committed, so the fault should never be observed. I'm not sure what you mean by "crashes", so I'm not sure

Re: [gem5-dev] Review Request 3836: x86: remove unnecessary parameter from functions

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3836/#review9477 --- Ship it! Ship It! - Steve Reinhardt On Feb. 23, 2017, 2:17 p.m

Re: [gem5-dev] Review Request 3806: sparc: fix bugs caused by cd7f3a1dbf55

, but this looks sufficiently complicated that it's quite believable. Also thanks for the thorough comments; at least if there ever are any issues with or questions about the code, there won't be much doubt about what you intended. - Steve Reinhardt On Feb. 10, 2017, 12:31 p.m., Brandon Potter wrote

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

croops/ldstop.isa (line 644) <http://reviews.gem5.org/r/3793/#comment7946> comment here too - Steve Reinhardt On Jan. 27, 2017, 9:40 a.m., Jason Lowe-Power wrote: > > --- > This is an automatically generated e-mail. To

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

rstand if you don't want to mess with that at this point though, so I won't press you on it. - Steve Reinhardt On Jan. 26, 2017, 8:51 a.m., Jason Lowe-Power wrote: > > --- > This is an automatically generated e-mail. To reply

Re: [gem5-dev] Bug in x86 stack instructions

hings I should > run? > >> > >> My intuition says this is an OK change. The addr field in the Request > >> should never have the upper-order 32 bits set if the instruction is a > >> 32-bit-mode instruction. The instruction implementation already takes > care > >> o

Re: [gem5-dev] Bug in x86 stack instructions

ver, I'm not sure how to tell if > the instruction is "an implicit stack operation" from the decoder. > > Thanks, > Jason > > On Tue, Jan 24, 2017 at 9:05 AM Steve Reinhardt <ste...@gmail.com> wrote: > > My recollection of how all this works is that the

Re: [gem5-dev] Bug in x86 stack instructions

My recollection of how all this works is that the arguments to the 'st' micro-op get turned into arguments to a call to the StoreOp constructor: 597 class StoreOp(LdStOp): 598

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

the synthetic part. > > It would be great if someone could dig into these issues. > > Steve Reinhardt wrote: > It's been quite a while since I've looked at this... in fact I was going > to say that there might be a memory leak, but looking back at

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

restructuring the cache" on the to-do list. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2691/#review9228 --------

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

lly need a microcode ROM? Seems like this whole file should not be necessary. - Steve Reinhardt On Oct. 13, 2016, 9:48 a.m., Alec Roelke wrote: > > --- > This is an automatically generated e-mail. To reply, visit:

Re: [gem5-dev] Review Request 3662: syscall_emul: [patch 2/22] move SyscallDesc into its own .hh and .cc

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3662/#review8939 --- Ship it! Ship It! - Steve Reinhardt On Oct. 19, 2016, 3:30 p.m

Re: [gem5-dev] Review Request 3671: syscall_emul: [patch 5/22] remove LiveProcess class and use Process instead

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3671/#review8938 --- Ship it! Yes, thanks! - Steve Reinhardt On Oct. 19, 2016, 12:27 p.m

Re: [gem5-dev] Review Request 3677: syscall_emul: [patch 11/22] extend functionality of fcntl

to make a template out of it (as there's no dependency on the ISA/OS). - Steve Reinhardt On Oct. 17, 2016, 9:05 a.m., Brandon Potter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://review

Re: [gem5-dev] Review Request 3676: syscall_emul: [patch 10/22] refactor fdentry and add fdarray class

force sim_fd to -1 for emulated devices, you'll automatically get EBADF for those without putting in any additional checks. - Steve Reinhardt On Oct. 18, 2016, 1:01 p.m., Brandon Potter wrote: > > --- > This is an

Re: [gem5-dev] Review Request 3674: syscall_emul: [patch 8/22] refactor process class

tor.cc (line 42) <http://reviews.gem5.org/r/3674/#comment7676> why do we need to include process.hh here? - Steve Reinhardt On Oct. 17, 2016, 8:23 a.m., Brandon Potter wrote: > > --- > This is an automatically generated e-

Re: [gem5-dev] Review Request 3673: syscall_emul: [patch 7/22] remove numCpus method

> On Oct. 18, 2016, 8:42 a.m., Jason Lowe-Power wrote: > > This is fine with me how it is. However, it's kind of moot if we're > > removing ALPHA support. > > Brandon Potter wrote: > Yeah, I am waiting to see if that materializes. If it does, I'll change > the patch to remove the numCpus

Re: [gem5-dev] Review Request 3672: syscall_emul: [patch 6/22] remove unused fields from Process class

think the overhead of maintaining Alpha Linux support is pretty low, at least comparable to some of the Tru64 stuff, in terms of wonky things that aren't hidden away in their own source files. Though I haven't looked at the code in a while so I could be wrong. - Steve Reinhardt On Oct. 17, 2016

Re: [gem5-dev] Review Request 3670: syscall_emul: [patch 4/22] remove redundant M5_pid field from process

and could be as complicated as keeping a map of which PIDs are used, or as simple as just tracking the max manually assigned PID and then incrementing from there. - Steve Reinhardt On Oct. 17, 2016, 8:14 a.m., Brandon Po

Re: [gem5-dev] Review Request 3643: style: [patch 3/22] reduce include dependencies in some headers

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3643/#review8929 --- Ship it! Ship It! - Steve Reinhardt On Oct. 17, 2016, 8:12 a.m

Re: [gem5-dev] Review Request 3660: style: [patch 1/22] use /r/3648/ to reorganize includes

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3660/#review8928 --- Ship it! Ship It! - Steve Reinhardt On Oct. 17, 2016, 8:07 a.m

Re: [gem5-dev] Review Request 3662: syscall_emul: [patch 2/22] move SyscallDesc into its own .hh and .cc

desc->warnOnce() ? "\n (further warnings will be suppressed)" : ""); } src/sim/syscall_desc.hh (line 85) <http://reviews.gem5.org/r/3662/#comment7674> again, this could be a one-liner. - St

Re: [gem5-dev] Review Request 3675: syscall_emul: [patch 9/22] remove unused global variable (num_processes)

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3675/#review8926 --- Ship it! Ship It! - Steve Reinhardt On Oct. 17, 2016, 8:25 a.m

Re: [gem5-dev] Review Request 3662: syscall_emul: [patch 2/22] move SyscallDesc into its own .hh and .cc

> On Oct. 11, 2016, 4:43 p.m., Tony Gutierrez wrote: > > src/sim/syscall_desc.hh, line 66 > > > > > > (void) is not necessary in c++. also this is not gem5 convention. > > Brandon Potter wrote: > I tried to get the same

Re: [gem5-dev] Review Request 3671: syscall_emul: [patch 5/22] remove LiveProcess class and use Process instead

> On Oct. 17, 2016, 3:25 p.m., Jason Lowe-Power wrote: > > Seems reasonable to me, but do we have any historical context for > > "LiveProcess"? > > > > Couple of small things below. > > Brandon Potter wrote: > I do not know about the historical context for LiveProcess. This is >

Re: [gem5-dev] Stable release

I agree with #1. The existence of gem5-stable is just confusing, since we don't have a good process to keep it up-to-date. Steve On Fri, Sep 30, 2016 at 8:56 AM Beckmann, Brad wrote: > I strongly support 1 as well. > > Brad > > > -Original Message- > From:

[gem5-dev] changeset in gem5: tests: remove EIO tests

changeset b2720503a978 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=b2720503a978 description: tests: remove EIO tests An email sent to gem5-users and gem5-dev asking if anyone was still using EIO traces got no responses, so it seems like it's

[gem5-dev] Review Request 3607: tests: remove EIO tests

/config.ini 55bd18998b7c tests/quick/se/20.eio-short/ref/alpha/eio/simple-atomic/config.json 55bd18998b7c tests/quick/se/20.eio-short/ref/alpha/eio/simple-atomic/simerr 55bd18998b7c Diff: http://reviews.gem5.org/r/3607/diff/ Testing --- Thanks, Steve Reinhardt

Re: [gem5-dev] Review Request 3582: syscall_emu: Corrected a bug on the syscall "read()" when reading EOF

e code used to look like. The fact that there used to be a bug here is irrelevant to people who look at this code in the future. - Steve Reinhardt On July 23, 2016, 6:16 a.m., Nicolas Derumigny wrote: > > --- > This is an automatica

Re: [gem5-dev] Review Request 3559: mem: Add a FromCache packet attribute

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3559/#review8555 --- Ship it! Ship It! - Steve Reinhardt On July 12, 2016, 12:13 a.m

[gem5-dev] changeset in gem5: stats: update EIO stats

changeset 80e79ae636ca in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=80e79ae636ca description: stats: update EIO stats diffstat: tests/quick/se/20.eio-short/ref/alpha/eio/simple-atomic/config.ini | 20 +

Re: [gem5-dev] Test infrastructure improvements

Hi Andreas, For the most part this all sounds pretty good. Thanks for all the effort. Just a few comments: - The scons support is very useful to make sure we don't re-run tests unnecessarily when binaries don't change. This is particularly important as long as we're running periodic (nightly,

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

> I suspect that is the most common CPU ISA used with Ruby. > > Thanks, > > Brad > > > > -Original Message- > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve > Reinhardt > Sent: Wednesday, June 08, 2016 4:01 PM > To: gem5 Developer List <gem

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

mit count. > > Again, let’s not obsess about the numbers. Let us instead focus on making > the most of our efforts and decide what is needed and what is not. > > AndreasH > > On 08/06/2016, 23:05, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-boun...@gem5.org on be

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

e know if you want the > spreadsheet...), but let’s not fool ourselves. Keeping things around has > noticeable implications on the overall progress. > > AndreasH > > > On 08/06/2016, 17:11, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-boun...@gem5.org on

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

On Wed, Jun 8, 2016 at 8:12 AM Andreas Sandberg wrote: > > > >Once the bar for reaching this point is raised by adding the steps of > >determining that gem5 *used to* support the ISA of interest, finding and > >extracting the old revision that still had that support in

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

On Mon, Jun 6, 2016 at 1:27 PM Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > > 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

[gem5-dev] changeset in gem5: stats: update EIO stats

changeset 4ad81380c5e8 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=4ad81380c5e8 description: stats: update EIO stats diffstat: tests/quick/se/20.eio-short/ref/alpha/eio/simple-atomic/simout |10 +-

[gem5-dev] anyone out there using EIO trace support?

If not, we are likely to drop it... so speak up now if you care! Thanks, Steve ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Heterogeneous ISA Simulation Support

The situation hasn't changed. ISA is still a compile-time constant. That said, I don't know of any other systems that simulate both x86 and ARM even with a compile-time switch, so if you're bound and determined to do it, my guess is that gem5 is probably the best starting point you're going to

Re: [gem5-dev] Review Request 3474: cpu, x86: Allow the TLB to be warmed up before CPU switch

that you would have a different TLB model for your > detailed simulation vs. warmup. That would be a reason to use the > "takeOverFrom" method instead of just switching the pointers or doing an > automatic deep copy via type_info (if that's what you're proposing). Though &g

Re: [gem5-dev] Review Request 3475: sim: Fix fork for multithreaded simulations

> On May 23, 2016, 9:48 a.m., Joel Hestness wrote: > > src/sim/simulate.cc, line 92 > > > > > > It might be safer to use an initial PID that will definitely not be a > > valid PID (e.g. -1) rather than 0, which is a valid

Re: [gem5-dev] Review Request 3474: cpu, x86: Allow the TLB to be warmed up before CPU switch

> On May 26, 2016, 6:16 a.m., Curtis Dunham wrote: > > src/arch/x86/tlb.cc, line 128 > > > > > > If this just (essentially) copy constructs a new TLB from the old, why > > can't the same TLB be used .. just reconnecting

Re: [gem5-dev] gem5 not building with gcc-4.7 -- bump required gcc version?

(additional gcc reference [2]), and the new PCI > >support > > > > > >[1] http://repo.gem5.org/gem5/rev/d9a0136ab8cc > >[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285 > >[3] > > > >-Original Message- > >From: gem5-dev [mailto:gem5-dev-bou

Re: [gem5-dev] changeset in gem5: tests: update EIO ref stats for removed cache...

we should do the same :-) > > Andreas > > On 13/05/2016, 16:46, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-boun...@gem5.org on behalf of ste...@gmail.com> wrote: > > >I don't know of anyone using EIO either, but that's what you thought about &

Re: [gem5-dev] changeset in gem5: tests: update EIO ref stats for removed cache...

se do voice your opinion. > > We also have to ensure all tests can run in a non-centralised CI > environment in a not-too-distant future. I wouldn’t know how to accomplish > that with these encumbered EIO tests. > > Andreas > > > On 12/05/2016, 23:16, "gem5-dev on

Re: [gem5-dev] RFC: Commit message style changes

the repo. > > //Andreas > > [1] > https://github.com/gem5/gem5/commit/a91c1e69a880dd6eec3cc980801ea18ddcbe7c3 > 1 > > On 12/05/2016, 23:25, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-boun...@gem5.org on behalf of ste...@gmail.com> wrote: > > >

Re: [gem5-dev] Review Request 3458: cpu: Physical register structural + flat indexing

needed. Also, why not just compare _flatIdx? src/cpu/o3/comm.hh (line 83) <http://reviews.gem5.org/r/3458/#comment7132> see my comment on the previous patch on restructuring this expression. - Steve Reinhardt On April 28, 20

Re: [gem5-dev] Review Request 3457: arch, cpu: Architectural Register structural indexing

amp;& (regClass == IntRegClass || (THE_ISA == ALPHA_ISA && regClass == FloatRegClass))); - Steve Reinhardt On April 28, 2016, 4:56 a.m., Andreas Sandberg wrote: > > -

Re: [gem5-dev] RFC: Commit message style changes

Hi Andreas, We discussed this internally today and the general feeling here is that the simple formatting changes (1 and 2 on your list) seem fine. Item 3 is OK as a recommendation/long-term goal but isn't something we'd want to enforce until we're all in the position where the insertion of

Re: [gem5-dev] changeset in gem5: tests: update EIO ref stats for removed cache...

once in a while. Steve On Sun, May 8, 2016 at 11:22 AM Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Steve, > > Should we perhaps just retire EIO? > > Andreas > > On 07/05/2016, 19:43, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-bou

[gem5-dev] changeset in gem5: tests: update EIO ref stats for removed cache...

changeset a22c4bac7e15 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=a22c4bac7e15 description: tests: update EIO ref stats for removed cache stats Complaints about changes in EIO tests were due to reference files that still have removed cache stats

Re: [gem5-dev] bare-metal SPARC support

Hi Dan, Thanks for your willingness to work on the SPARC support. There actually is support for SPARC full-system mode; there's even a regression test that gets run with: scons build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic Unfortunately that test relies on a

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3452: mem: Deallocate all write-queue entries when sent

/cache.cc (line 2219) <http://reviews.gem5.org/r/3452/#comment7074> spelling... there's at least one typo here, some would say two ;) - Steve Reinhardt On April 20, 2016, 10:18 a.m., Andreas Hansson wrote: > > --- > This is a

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

> On April 17, 2016, 10:06 p.m., Steve Reinhardt wrote: > > src/mem/cache/write_queue_entry.hh, line 80 > > <http://reviews.gem5.org/r/3407/diff/2/?file=54859#file54859line80> > > > > Is this 'pkt' field still used? I'd think not, in which case it

Re: [gem5-dev] Review Request 3401: x86: fix TLB issue

al masking of the A20 address bit (asserting the A20M# input signal). • Writes to certain model-specific registers with the WRMSR instruction; see the BIOS and Kernel Developer's Guide applicable to your product for more information - Steve Reinhardt On April 13, 2016, 6:37 a.m., Bjoern A.

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

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3194/#review8248 --- Ship it! Thanks! - Steve Reinhardt On April 13, 2016, 7:23 a.m

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

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3447/#review8247 --- Ship it! Ship It! - Steve Reinhardt On April 13, 2016, 7:12 a.m

Re: [gem5-dev] Review Request 3408: mem: Align downstream cache packet creation in atomic and timing

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3408/#review8241 --- Ship it! Ship It! - Steve Reinhardt On April 9, 2016, 9:21 a.m

Re: [gem5-dev] Review Request 3407: mem: Simplify cache packet handling for uncacheable writes

level and keeping a copy of the pointer ourselves---makes the ownership situation ambiguous. - Steve Reinhardt On April 9, 2016, 9:20 a.m., Andreas Hansson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > h

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

ly, visit: http://reviews.gem5.org/r/2691/#review8197 --- On April 14, 2016, 10:42 p.m., Steve Reinhardt wrote: > > --- > This is an automatically generated e-mail. To reply, visi

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

/mem/cache/mshr.hh df24b9af42c72606f1fa8e5aa0502b53e81ea176 src/mem/packet.hh df24b9af42c72606f1fa8e5aa0502b53e81ea176 src/mem/packet.cc df24b9af42c72606f1fa8e5aa0502b53e81ea176 Diff: http://reviews.gem5.org/r/2691/diff/ Testing --- Thanks, Steve Reinh

Re: [gem5-dev] changeset in gem5: misc: Don't build region.py as a PySource

We had an internal discussion about this and the consensus from AMD is that bumping the dependence up to 2.7 would be fine. There might be some short-term internal impacts but we can work around them, and being able to migrate to argparse is worth it. We feel we should keep to the base 2.7 for

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

e On Thu, Apr 14, 2016 at 10:48 AM Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Steve, > > This patch review, and this conversation (until it ended up on the mailing > list). 3449. My first comment. > > Andreas > > From: Steve Reinhardt <ste...@gmail.com&

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

are also > no tests using it (for those reasons), so the functionality is likely to > not track changes in the code base. Marco is in a much better position than > I am in estimating the effort required to address these issues. > > Do we all agree that getting this sorted benefit

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

Hi Andreas, Can you elaborate on the "rough edges" that need to be addressed in MemChecker, other than adding a regression that uses it? Forcing Marco to deal with our regression system seems a bit out of scope. Steve On Thu, Apr 14, 2016 at 10:03 AM Andreas Hansson

Re: [gem5-dev] changeset in gem5: misc: Don't build region.py as a PySource

Our problem is also in dealing with RHEL/CentOS machines. While it's easy enough to install a newer compiler and switch to that (just by setting CC and CXX), the process of using a non-default Python installation is more onerous and intimidating to infrequent users. I'm also not very happy in

[gem5-dev] Python 2.7 dependency (was Re: changeset in gem5: scons, style: Rename style.py to hgstyle.py)

Nikoleris <nikos.nikole...@arm.com> > Reviewed-by: Curtis Dunham <curtis.dun...@arm.com> > Reviewed-by: Nathanael Premillieu <nathananel.premill...@arm.com> > Reviewed-by: Steve Reinhardt <steve.reinha.

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

Hi Bjoern, As Jason said, we do use the x86 ISA regularly inside AMD, though we primarily use SE mode. The FS mode support was developed with the goal of getting Linux to boot, so I'm not surprised it doesn't work for other OSes. I don't know how widely used x86 FS is. The out-of-sequence Exec

Re: [gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

Just trying the first test that failed, I get: % sudo -u m5test build/ALPHA/gem5.opt /z/m5/regression/zizzer/gem5/tests/run.py build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for

[gem5-dev] changeset in gem5: syscall_emul: remove mmapFlagTable

changeset cfad34a15729 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=cfad34a15729 description: syscall_emul: remove mmapFlagTable After all this it turns out we don't even use it. diffstat: src/arch/alpha/linux/linux.hh | 3 --

[gem5-dev] changeset in gem5: syscall_emul: factor out flag tables into com...

changeset 3d47d83a48eb in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=3d47d83a48eb description: syscall_emul: factor out flag tables into common file The openFlagTable and mmapFlagTables for emulated Linux platforms are basically identical, but are

Re: [gem5-dev] Review Request 3403: syscall: remove mmapFlagTable

eview8125 --- On March 25, 2016, 8:40 p.m., Steve Reinhardt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://re

Re: [gem5-dev] Trunk does not build due to recent syscall_emul patch

, looking at the error message below there is also O_NOATIME, and then > quite a bunch of the MAP_* flags. > > Andreas > > On 24/03/2016, 21:14, "gem5-dev on behalf of Steve Reinhardt" > <gem5-dev-boun...@gem5.org on behalf of ste...@gmail.com> wrote: > > >Is

  1   2   3   4   5   6   7   8   9   10   >