Re: [gem5-dev] Announcing the beta of gem5's new website
Hi Jason, Thanks for sharing the website. And a lot of thanks to all those who made this possible. I had one question: Is your tutorial updated to new function call names?for example to implement new cache replacement policy, your tutorial still use old format of defining function calls and its implementation in the “src/mem/cache/tags/“ folder only, so is it still valid? On Tue, Dec 17, 2019 at 8:15 PM Jason Lowe-Power wrote: > Hi all, > > I'm excited to announce that we have a beta version of a re-designed > website at new.gem5.org! The old wiki has needed a refresh for a few > years, > and we’re excited to finally have something to share with the community! We > hope the new site has better usability and makes it easier to find > information about gem5 and how to use it. If you have any questions or > comments, don’t hesitate to reach out by replying to this email. > > We will leave this website at new.gem5.org for the next few weeks. Please > let us know if there’s any blocking issues before we turn off the old wiki > pages. Before fully transitioning, we will download a static copy of the > entire old website (including the old code reviews) and move this to > old.gem5.org for archival purposes (and in case we missed anything!). > > I'd like to thank all of those that have contributed so far. Specifically: > Jingwen Low who designed the site > Ali Saidi who kicked this off by converting the wiki to markdown almost two > years ago > Bobby Bruce who has put it a ton of time moving documentation > And Jared Barosci, Hoa Nguyen, Krithiga Murugavel, Ayaz Akram, Trivikram > Reddy, Marjan Fariborz, Mahyar Samani, Julian Toya Angeles, and Muhammet > Soytürk who have helped move documentation from the old wiki to the new > site. > See https://github.com/gem5/new-website/graphs/contributors for details > > Details on the current status of the migration can be found on Jira ( > https://gem5.atlassian.net/browse/GEM5-110). We also have a specific issue > for migrating the old documentation to the new site ( > https://gem5.atlassian.net/browse/GEM5-115). We’ve already moved most of > the documentation, but there are still a few pages that we could use your > help with! > > There will be some rough edges as we transition. Some links may be broken, > and it’s possible we missed pages that should be migrated. If you find any > issues, please let us know via the mailing list or by opening an issue on > Jira. > > The website is currently hosted on GitHub pages. If you’d like to > contribute, feel free to create a pull request on the source repository ( > https://github.com/gem5/new-website). > > Cheers, > Jason > ___ > 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] gem5 stable release proposal [PLEASE VOTE!]
Hello Jason, Thanks for such a nice and detailed explanation. My votes are as follows: *I think master should be development* *I think gem5 should be released once per year* Best regards, Abhishek On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > 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] gem5 19.0.0 : New git branching proposal
Hello Jason, This is perfect ! I had one more question, for full system simulations will there be release of images and kernel files for every architectures (arm , x86, etc)? On Thu, Dec 12, 2019 at 12:57 PM Jason Lowe-Power wrote: > Hey Abhishek, > > Emails will continue to gem5-dev on every changeset pushed to the develop > branch as they do now to master :). We can discuss if we want the same for > feature branches (if we end up using them). > > Your first interpretation on gem5 stable is correct (sorry if this wasn't > clear). It will be much more heavily tested than the minute-by-minute > releases from the develop branch. With this testing we will be publishing > the following: > - What (common) workloads are supported (e.g., SPEC, parsec, etc.). Which > workloads we use here will be discussed in the future, stay tuned. > - For all of the workloads, we will publish common statistics for a few > different systems (e.g., time to simulate, IPC, cache miss rates, memory > bandwidth, etc). The systems used and the stats will be discussed in the > future. > > The stable release will *not* be a continuous process. The only time the > stable branch will be updated is 1) At releases or 2) if a "major" bug is > encountered. For non-release updates (e.g., for bugs), we'll be very > careful to either re-validate our results or somehow know the results won't > change. > > Cheers, > Jason > > > > On Thu, Dec 12, 2019 at 9:38 AM Abhishek Singh < > abhishek.singh199...@gmail.com> wrote: > > > Hi Jason, > > > > Thanks for your email. It cleared a lot of misunderstanding which I had. > > > > Is it possible to have an email sent on every commit we make to atleast > > gem5-dev? > > The email list could be different and can be sent to people who are > > interested in this so that it does not spam to gem5-Dev list. > > > > I am talking about gem5 developer branch and not stable. > > > > This is because, it will keep all the interested community members well > > informed about new features that are added, who like to keep note of > latest > > changes and merge in their projects as required. > > > > And the way, I understand that a stable gem5 when a user desires is: > > It wants the conference accepted applications (standard workload for > > example spec, parsec, etc to run without any errors on both SE and FS > mode > > for every architecture and cpu models. > > > > If that’s what the stable releases are going to be testing before > releasing > > it, then a stable release is much more helpful and will have the wide > > reach. But when I read proposal this seems to be step by step process > > reaching it as the final goal. Please correct me on this if I understood > it > > wrong. > > > > > > The aim of stable releases is a continuous process and will always be > > doubtful unless tested with all the major conference accepted application > > on every stable releases. > > > > On Thu, Dec 12, 2019 at 12:12 PM Jason Lowe-Power > > wrote: > > > > > Hi all, > > > > > > First of all, let me say that I hope it's clear that gem5 is not > > > "controlled" in any way by me! As laid out in our governance document ( > > > http://gem5.org/Governance#Overview), "gem5 is a meritocratic, > > > consensus-based community project". Through these emails, and as the > > chair > > > of the project management committee, I'm trying to *build* consensus. > > > > > > Importantly, there's a reason we're trying to make this push for stable > > > APIs. I've heard from dozens of current and potential gem5 users that > > they > > > want stable gem5 releases. By providing stable releases, we will be > > > expanding the users of gem5 (and, IMO, making the research and papers > > that > > > use gem5 better). > > > > > > Could you please clarify the policy on breaking APIs? It makes sense > for > > > > releases to maintain stable APIs, but how does that apply to the > > > > development branch? I'm worried that it will be very hard to make > > changes > > > > that don't change any interfaces, and we definitely don't want to > > > encourage > > > > a style of development where we just add and add and add without ever > > > > refactoring or consolidating things. If APIs can continue to change > as > > > > needed in the development branch and we just need to warn people > before > > > > they're released, that seems reasonable. > > > > > >
Re: [gem5-dev] gem5 19.0.0 : New git branching proposal
e of. Note: we will make it very > clear in the release notes what is changed each time. > > If you choose to merge in the new minor release, *it should be very easy*. > We will not break any interfaces, therefore the merge should be simple. As > long as you only used "official" APIs, your code should work *without any > changes*. > > 2. On a major release > Again, you'll have the choice to merge or not. If there aren't any new > features you need, don't merge! If there are new features, then you may > want to take the effort to merge. > > To merge at a major release, you'll probably have to update your code since > APIs may have changed. These will be very well documented in the release > notes with information on how to update your code. Additionally, assuming > that you pulled the previous minor releases, you will have known this was > coming because any APIs that have changed would have been marked as > deprecated and produced compile time or run time warnings. > > 3. Contributing your code back to gem5 > If you have a big new feature (e.g., a new CPU model), you can email > gem5-dev and request a new branch. We'll set that up and then we can start > reviewing the code! There will likely be some refactoring that's required > or merging current development changes. You can do this *on top* of your > current changes, instead of having to rebase 50 changesets :). Once the > code is to a point that the maintainer and the community are happy, then it > will be a simple merge commit into the develop branch! > > Of course, small bugfixes should just be on top of develop. And, if your > big new feature requires API changes, then it may be more effort to get the > branch merged. > > If this doesn't make it clear, please let me know! > > > > To conclude: I'm trying to build consensus here. I want to see gem5 used as > broadly as possible; I want to see gem5 used to produce sustainable, > reproducible, and scientifically rigorous research; and I want to see gem5 > be easy to use. I believe this new release model will help with these > things, but I'm 100% open to modifications. > > I would appreciate specific actionable feedback. Simply saying "I don't > like the idea" is helpful, but it would be more helpful to provide updates > the proposal with your ideas on how to accomplish the goals of the gem5 > community project (again, see the Governance document: > http://gem5.org/Governance#Philosophy). > > Cheers, > Jason > > On Wed, Dec 11, 2019 at 7:49 PM Abhishek Singh < > abhishek.singh199...@gmail.com> wrote: > > > > Hi Jason, > > I agree with Gabe, it seems like gem5 is taking a way to get better but > it > > will very hard for PhD students to suddenly adapt and review thousand > lines > > of code with months of yet unseen history and iteration and the reason > > behind every change. > > > > And in the end it may end up to be used as a course project rather than > > thesis project or project for architecture conferences as people will use > > the commit or the branch which they are most familiar with. > > With so less releases every year, personally it will take a lot of time > to > > relearn and understand the implementation in detail. > > > > But as this fully controlled by you, we can only suggest you. It should > not > > be like people are creating another public gem5 as we have now and use > that. > > > > This issue was raised by Gabe on Nov 27 email and today also, so I hope > we > > take that into account. > > It feels like gem5 is getting towards privatization... > > > > It’s just a opinion, it may be wrong. > > > > On Wed, Dec 11, 2019 at 10:12 PM Gabe Black > wrote: > > > > > Could you please clarify the policy on breaking APIs? It makes sense > for > > > releases to maintain stable APIs, but how does that apply to the > > > development branch? I'm worried that it will be very hard to make > changes > > > that don't change any interfaces, and we definitely don't want to > encourage > > > a style of development where we just add and add and add without ever > > > refactoring or consolidating things. If APIs can continue to change as > > > needed in the development branch and we just need to warn people before > > > they're released, that seems reasonable. > > > > > > In general (and not necessarily tied to this proposal), we should try > very > > > hard not to have silos where people develop incompatible features and > don't > > > add to gem5 in a holistic way. It's easiest to wall off functionality > > > behind ifdefs
Re: [gem5-dev] gem5 19.0.0 : New git branching proposal
Hi Jason,
I agree with Gabe, it seems like gem5 is taking a way to get better but it
will very hard for PhD students to suddenly adapt and review thousand lines
of code with months of yet unseen history and iteration and the reason
behind every change.
And in the end it may end up to be used as a course project rather than
thesis project or project for architecture conferences as people will use
the commit or the branch which they are most familiar with.
With so less releases every year, personally it will take a lot of time to
relearn and understand the implementation in detail.
But as this fully controlled by you, we can only suggest you. It should not
be like people are creating another public gem5 as we have now and use that.
This issue was raised by Gabe on Nov 27 email and today also, so I hope we
take that into account.
It feels like gem5 is getting towards privatization...
It’s just a opinion, it may be wrong.
On Wed, Dec 11, 2019 at 10:12 PM Gabe Black wrote:
> Could you please clarify the policy on breaking APIs? It makes sense for
> releases to maintain stable APIs, but how does that apply to the
> development branch? I'm worried that it will be very hard to make changes
> that don't change any interfaces, and we definitely don't want to encourage
> a style of development where we just add and add and add without ever
> refactoring or consolidating things. If APIs can continue to change as
> needed in the development branch and we just need to warn people before
> they're released, that seems reasonable.
>
> In general (and not necessarily tied to this proposal), we should try very
> hard not to have silos where people develop incompatible features and don't
> add to gem5 in a holistic way. It's easiest to wall off functionality
> behind ifdefs or config options or in separate repositories and then just
> ignore it when implementing new features, but that creates a lot of
> technical debt and complexity which really cripples both gem5 and future
> development and compounds exponentially over time.
>
> Back to the branches, I'm still not a fan. I think it gives people an
> excuse not to make changes ("you want me to refactor 18 months of code for
> that?" (not an actual quote)), on top of other issues. Also there are more
> than two options. You can do your work on top of tree like I do, even when
> adding big new features. It ensures that you don't get too invested in bad
> paths and don't have a mountain of integration work to do when you finally
> decide to bridge back in. It also gives the community an appropriate
> opportunity to provide feedback through review which is not practical when
> dealing with dozens of files and thousands of lines of code with months of
> yet unseen history and iteration.
>
> Gabe
>
> On Wed, Dec 11, 2019 at 5:30 PM Jason Lowe-Power
> wrote:
>
> > Hi all,
> >
> > Here are the specific changes we're proposing. Please give us your
> > feedback! If you disagree with some part of this proposal, let us know
> > why and what you suggest instead.
> >
> > # What's changing now
> >
> > 1) We are going to release gem5 19 "soon" (two blocking issues: 1)
> > this proposal and 2) the website)
> > 2) When we release gem5 19 we are going to create a new branch called
> > "develop" which branches at the point we make the release.
> > 3) We are going to tag master with "19.0.0-beta"
> >
> > After this, all development will move to the develop branch instead of
> > master. This will allow the common case of people using gem5 for
> > research to be the default. When cloning gem5 you will get a "stable"
> > release.
> >
> > ## Changes for developers
> >
> > There will be two changes for developers:
> > 1) You'll have to checkout develop after cloning
> > 2) You'll have to push to "refs/for/develop" instead of "refs/for/master"
> >
> > # Next release
> >
> > When we get to our next release (gem5 20, yay!), we will merge the
> > develop branch into master. Assuming no hotfixes, this will be a
> > simple fast forward.
> >
> > We will have a major release once per year usually in April (after the
> > MICRO deadline but with enough lead time to put together an ISCA
> > tutorial). We will have two minor releases later in the year, one in
> > August and one in December.
> >
> > # Why are we going to releases?
> >
> > It's important for our *users* (remember, we're developing gem5 to be
> > used by other people, not just core developers!) to be able to build
> > off of stable APIs. Therefore, between major releases *we will not
> > change any APIs*. Code that we expect other people will build off of
> > are APIs. This includes, but is not limited to:
> > - Ports
> > - ExecContext
> > - Packet
> > - SimObject, ClockedObject, etc.
> > - Event, EventQueue, etc.
> > - Command line options
> > - And probably many more. We will work on finalizing this over the
> > next couple of months before the gem5-20 release.
> >
> > ## What does going to releases mean for developers?
> >
> > Thus,
Re: [gem5-dev] gem5 19.0.0 : New git branching proposal
It’s a nice plan On Tue, Nov 26, 2019 at 7:10 PM Bobby Bruce wrote: > Dear all, > > As you know, at the end of this quarter we will be releasing gem5-19, the > first official release of gem5. As part of this release we'd like to change > our git branching structure. Therefore, I'm writing to ask for feedback on > what we have planned and whether it can be improved upon. > > We'd like to have a git repo structure similar to that used in gitflow > development: https://nvie.com/posts/a-successful-git-branching-model . > I've > seen this model work well before, as it has some worthwhile abstractors for > public, open source git projects with regular releases. What I'd like to > incorporate from this model is the following: > > - Two permanent branches: master and develop. > - "develop" would function as master does now. This would be the main point > in which changes are applied between gem5 releases. > - Upon a new release of gem5, the develop branch would be merged into > master and a new git tag added to master indicating the release version. > Ergo, the master branch would always contain the latest release of gem5. > - If a quick hotfix is needed, a new "hotfix" branch would be created and > merged into both the develop and master branches upon completion. This > would also require a new tag on the master branch. (I suggest using the > standard "Version [Major].[Minor].[Hotfix]" version numbering system. I.e., > the first version would be V19.0.0, a hotfix to this would make it V19.0.1, > and a minor release would make it V19.1.0). > - The creation of feature branches would be permitted. These branches would > encapsulate the gradual development of large features (i.e., ones carried > out over many commits). When complete a feature branch would be merged into > the develop branch. They'd be no obligation to use feature branches though > we believe they could be of value in certain cases. For example, if a > developer wishes to postpone a developed feature for a given gem5 release > (e.g., something more suited for a major release rather than a minor one), > then they could submit their changes as a feature branch and wait to merge > to the develop branch at a later date. > > I believe this setup would make our development process run smoother and > give gem5 users more stability. Day-to-day development wouldn't change much > as committing to the develop branch would work in the same way as > submitting to master does now. > > If anyone has any thoughts about this, I'd be happy to hear from you. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > ___ > 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] Gem5 Full System Crashes
Hi Stefan Waczynski, Were you able to fix the problem? Best regards, Abhishek On Tue, Jun 4, 2019 at 9:32 AM Stefan Waczynski < stefan.waczynsk...@gmail.com> wrote: > Hi All, > > I looked at my previous message and noticed that I missed possibly the most > "meaningful" (at-least to me) part of the error print-out for all my > crashes with the detailed model. > > In all cases I get (just prior to the LibC backtrace): > gem5.opt: build/X86/mem/packet.hh:1047: T* Packet::getPtr() [with T = > unsigned char]: Assertion `flags.isSet(STATIC_DATA|DYNAMIC_DATA)' failed. > > Which suggests to me that the kernel is not setting up the dynamic/static > memory correctly (but I am unsure of where in the kernel/simulator > interplay this normally gets set and how to rectify it not being set--i.e. > is it my simulator or is it my kernel that are set incorrectly). > > Bjoern, thank you for the information on the ACPI stub error/bug; I would > be very happy to see any relevant parts of that prior FS discussion (as I > am also guessing that my issue must be coming from the TLB/something not > simulated in the AtomicSimpleCPU as the error does not pop up when using > these simpler models). > > Thank you, > Stefan Waczynski > > On Mon, Jun 3, 2019 at 12:01 PM Bjoern A. Zeeb < > bzeeb-li...@lists.zabbadoz.net> wrote: > > > 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 > ___ > 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] cpu-o3: O3 LSQ Generalisation refactor
Hi Gabor,
Your latest change of adding markDelayed() to src/arch/x86/tlb.cc does not
solve the problem "gem5.opt: build/X86/mem/packet.hh:1094: T*
Packet::getPtr() [with T = unsigned char]: Assertion
`flags.isSet(STATIC_DATA|DYNAMIC_DATA)' failed"
Is there any other way, to get gem5 FS x86 with O3CPU working except using
AtomicSimpleCPU to create checkpoint and then use O3CPU?
As Andrew correctly pointed this problem did not arrive before "LSQ rewrite
commit in January:51becd2475748fb5515f261254c48827b3b5c2ba"
Best regards,
Abhishek
On Wed, Mar 20, 2019 at 9:35 AM Gabor Dozsa wrote:
> Hi Andrew,
>
> There is a fairly lengthy commit message for 51becd2 ("O3 LSQ
> Generalisation") which explains briefly the main ideas behind the rewrite.
>
> Regarding the particular assertion, the reason is likely to be that the
> X86 tlb code does not call
> 'translation->markDelayed()' when the translation triggers hardware page
> walks. Adding markDelayed() to src/arch/x86/tlb.cc should fix the issue.
> (You can look at src/arch/arm/tlb.cc for to see how this is done for Arm.)
>
> Cheers,
> - Gabor
>
>
> On 19/03/2019, 19:48, "gem5-dev on behalf of Zigerelli, Andrew D" <
> gem5-dev-boun...@gem5.org on behalf of an...@pitt.edu> wrote:
>
> Dear Giacomo Travaglini, Gabor Dozsa,
>
> Regarding your LSQ rewrite commit in January:
> 51becd2475748fb5515f261254c48827b3b5c2ba
>
>
> Because this is a substantial rewrite, is there any documentation
> related to how things work now?
>
> I'm trying to debug an assert I get with X86 and O3 cpu in lsq_impl.hh.
>
> LSQ::SplitDataRequest::finish(const Fault , const
> RequestPtr ,
> ThreadContext* tc, BaseTLB::Mode mode)
> _fault.push_back(fault);
> assert(req == _requests[numTranslatedFragments] ||
> this->isDelayed());
> I'm interested in the fix, but I'd also like to know how the new LSQ
> works because it's related to my work.
>
> I can bypass by using the gem5 before the rewrite, but I assume this
> is something that should be fixed anyway.
>
>
> Thank you,
>
> Andrew Zigerelli
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
