[gem5-users] Re: How to add a new pcie device on GEM5
I second Gabe's suggestion. I think the IDE controller is a good starting point since it mostly models the controller and passes more complicated (device specific) functions to the disks. I mostly templated based on the IDE controller when we started adding a PCI interface for GPU (see WIP here: https://gem5-review.googlesource.com/c/amd/gem5/+/23485). Best, On Mon, Oct 26, 2020 at 5:59 PM Gabe Black via gem5-users < gem5-users@gem5.org> wrote: > The VirtIO device would be a pretty good example, although it does some > unusual things as far as determining how big it's BARs are supposed to be. > The IDE controller is a pretty simple device that's a little more > representative in that way. A lot of the complexity is in the actual disks > themselves, with the controller mostly just directing messages from the > host to a particular disk. > > Gabe > > On Thu, Oct 22, 2020 at 6:37 AM Giacomo Travaglini via gem5-users < > gem5-users@gem5.org> wrote: > >> Hi, >> >> >> >> I’d recommend having a look at the VirtIO device…. >> >> (I don’t know if there are better examples, more experienced people are >> welcome to chime in) >> >> >> >> Giacomo >> >> >> >> *From:* Liyichao via gem5-users >> *Sent:* 22 October 2020 11:51 >> *To:* gem5 users mailing list >> *Cc:* Liyichao >> *Subject:* [gem5-users] How to add a new pcie device on GEM5 >> >> >> >> Hi All: >> >> >> >> Any one has experience on how to add ad new pcie device on GEM5? >> >> >> >> This device can be just a demo device which has only a few basic >> operation like read,write… >> >> >> >> So if I want to add a pcie device,any config I need to realize? >> Or any examples? >> >> >> -- >> >> 李翼超（Charlie） >> >> >> >> 华为技术有限公司 Huawei Technologies Co., Ltd. >> >> [image: Company_logo] >> >> 部门：计算系统与组件开发部 [云与计算BG] >> >> 手 机：15858232899 >> 电子邮件：liyic...@huawei.com >> >> 地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06] >> -- >> >> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 >> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 >> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> >> 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-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, "I think master should be stable"as common case should be to use gem5 and not to dev it. "I think gem5 should be released three times per year." as I assume there would be too much to digest after one year. Best, On Mon, Dec 16, 2019 at 12:21 PM Tao Zhang wrote: > Hi Jason, > > Thanks for the proposal. > > Regarding the branch option for stable release, can we do it by git > tagging? > > I think one-release per year is too long. I prefer three-release per year. > > Thanks, > > -Tao > > > On Mon, Dec 16, 2019 at 11:50 AM 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
Re: [gem5-users] Understanding cda microop
Hi Gabe.
Thank you for the clarification, greatly appreciated . I will make a record
of this, and attempt to implement it as soon as possible.
Best,
On Thu, Sep 12, 2019 at 3:52 PM Gabe Black wrote:
> It's been a while, but I think your interpretation is correct. It looks
> like O3 doesn't check for NO_ACCESS and so will likely go ahead and do the
> access regardless. That will possibly lead to bad things happening, and
> would probably be worth fixing if you're trying to use x86 with O3.
>
> Gabe
>
> On Wed, Sep 11, 2019 at 2:45 PM Pouya Fotouhi
> wrote:
>
>> Hi All,
>>
>> I'm trying to understand how cda microop works. I can see it's defined as
>> "defineMicroStoreOp('Cda', 'Mem = 0;', mem_flags="Request::NO_ACCESS")".
>> And I see in simple and atomic CPUs that we check the data before we
>> execute the instruction in case of requests with NO_ACCESS flag set.
>> My questions are:
>>
>>1. Is my interpretation correct?
>>2. How about O3 CPU?
>>
>>
>> Best,
>> --
>> Pouya Fotouhi
>> PhD Candidate
>> Department of Electrical and Computer Engineering
>> University of California, Davis
>> ___
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Pouya Fotouhi
PhD Candidate
Department of Electrical and Computer Engineering
University of California, Davis
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Understanding cda microop
Hi All,
I'm trying to understand how cda microop works. I can see it's defined as
"defineMicroStoreOp('Cda', 'Mem = 0;', mem_flags="Request::NO_ACCESS")".
And I see in simple and atomic CPUs that we check the data before we
execute the instruction in case of requests with NO_ACCESS flag set.
My questions are:
1. Is my interpretation correct?
2. How about O3 CPU?
Best,
--
Pouya Fotouhi
PhD Candidate
Department of Electrical and Computer Engineering
University of California, Davis
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Indeterministic gem5 behavior
If you use --debug-flags=ExecAll,Decode and narrow down your trace to the Ticks that you know the load is failing with --debug-start and --debug-end you should be able to get that. Best, On Wed, Sep 11, 2019 at 2:15 PM Shehab Elsayed wrote: > Is there a way to get the macroop from the corresponding instruction > pointer? > > > On Wed, Sep 11, 2019 at 5:07 PM Pouya Fotouhi > wrote: > >> Hi Shehab, >> >> Can you please confirm what is the macroop that is issuing that load? I >> suspect it's one of the 128-bit instructions (maybe recently non-temporal >> ones that I added) that are executed as two 64-bit loads, and possibly the >> second one is failing due to the cda check that we do, and that stops the >> load from being committed. >> >> Best, >> >> On Wed, Sep 11, 2019 at 1:16 PM Shehab Elsayed >> wrote: >> >>> So actually load instruction gets executed twice causing the assertion >>> to fail on the second time. >>> >>> 769413949: system.switch_cpus.iew.lsq.thread0: Doing memory access >>> for inst [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2) >>> 769413949: system.switch_cpus.iew.lsq.thread0: Load [sn:15059405] >>> not executed from fault >>> 769413949: system.switch_cpus.iew.lsq.thread0: 1- Setting >>> [sn:15059405] as executed (I added this message to track when LSQ >>> instructions are set as executed) >>> >>> I believe this instruction should then be committed and removed from the >>> LSQ before before executed again, however, this does not happen. Instead it >>> gets executed again before being removed and then comes the assertion >>> failure that it has already executed. >>> >>> I see that it gets sent to commit >>> >>> 769413949: system.switch_cpus.iew: Sending instructions to commit, >>> [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2). >>> >>> but it never actually gets to commit and removed from LSQ. >>> >>> >>> On Mon, Sep 9, 2019 at 3:01 PM Pouya Fotouhi >>> wrote: >>> >>>> You can try dumping Exec trace for the last few million ticks and see >>>> what is going on in your LSQ and why you have load instruction that is not >>>> executed. >>>> >>>> Best, >>>> >>>> On Mon, Sep 9, 2019 at 11:28 AM Shehab Elsayed >>>> wrote: >>>> >>>>> I am not sure that prefetch_nta is the problem. For different runs >>>>> the simulation would fail after different periods after printing the >>>>> prefetch_nta warning message. Also, from what I have seen in >>>>> different posts it seems that this warning has been around for a while. >>>>> >>>>> I tried compiling my hello world program with -march=athlon64 alone >>>>> and together with -O0 and the the same problem happens. >>>>> >>>>> Also, the I am building my benchmark on the disk image directly using >>>>> qemu and the gcc on the image is versio 5.4.0 >>>>> >>>>> >>>>> >>>>> On Sun, Sep 8, 2019 at 4:14 PM Pouya Fotouhi >>>>> wrote: >>>>> >>>>>> Hi Shehab, >>>>>> >>>>>> Good, that's "progress"! >>>>>> My guess off the top of my head is that you used a "more recent" >>>>>> compiler (compared to what other gem5 users tend to use), and thus some >>>>>> instructions are being generated that were not critical to the execution >>>>>> of >>>>>> applications other users had so far (and that's mostly why those >>>>>> instructions are not yet implemented). I think you have two options: >>>>>> >>>>>>1. You can try implementing prefetch_nta, and possibly ignore the >>>>>>non-temporal hint (i.e. implement it as a cacheable prefetch). You can >>>>>>start by looking at the implementation of other prefetch instruction >>>>>> we >>>>>>have in gem5 (basically you can do the same :) ). >>>>>>2. Try compiling your application (I think we are still talking >>>>>>about the hello world, right?), and target an older architecture (you >>>>>> can >>>>>>do as extreme as march=athlon64) with less optimizations involved to >>>>>> avoid >
Re: [gem5-users] Indeterministic gem5 behavior
Hi Shehab, Can you please confirm what is the macroop that is issuing that load? I suspect it's one of the 128-bit instructions (maybe recently non-temporal ones that I added) that are executed as two 64-bit loads, and possibly the second one is failing due to the cda check that we do, and that stops the load from being committed. Best, On Wed, Sep 11, 2019 at 1:16 PM Shehab Elsayed wrote: > So actually load instruction gets executed twice causing the assertion to > fail on the second time. > > 769413949: system.switch_cpus.iew.lsq.thread0: Doing memory access for > inst [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2) > 769413949: system.switch_cpus.iew.lsq.thread0: Load [sn:15059405] not > executed from fault > 769413949: system.switch_cpus.iew.lsq.thread0: 1- Setting > [sn:15059405] as executed (I added this message to track when LSQ > instructions are set as executed) > > I believe this instruction should then be committed and removed from the > LSQ before before executed again, however, this does not happen. Instead it > gets executed again before being removed and then comes the assertion > failure that it has already executed. > > I see that it gets sent to commit > > 769413949: system.switch_cpus.iew: Sending instructions to commit, > [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2). > > but it never actually gets to commit and removed from LSQ. > > > On Mon, Sep 9, 2019 at 3:01 PM Pouya Fotouhi wrote: > >> You can try dumping Exec trace for the last few million ticks and see >> what is going on in your LSQ and why you have load instruction that is not >> executed. >> >> Best, >> >> On Mon, Sep 9, 2019 at 11:28 AM Shehab Elsayed >> wrote: >> >>> I am not sure that prefetch_nta is the problem. For different runs the >>> simulation would fail after different periods after printing the >>> prefetch_nta warning message. Also, from what I have seen in different >>> posts it seems that this warning has been around for a while. >>> >>> I tried compiling my hello world program with -march=athlon64 alone and >>> together with -O0 and the the same problem happens. >>> >>> Also, the I am building my benchmark on the disk image directly using >>> qemu and the gcc on the image is versio 5.4.0 >>> >>> >>> >>> On Sun, Sep 8, 2019 at 4:14 PM Pouya Fotouhi >>> wrote: >>> >>>> Hi Shehab, >>>> >>>> Good, that's "progress"! >>>> My guess off the top of my head is that you used a "more recent" >>>> compiler (compared to what other gem5 users tend to use), and thus some >>>> instructions are being generated that were not critical to the execution of >>>> applications other users had so far (and that's mostly why those >>>> instructions are not yet implemented). I think you have two options: >>>> >>>>1. You can try implementing prefetch_nta, and possibly ignore the >>>>non-temporal hint (i.e. implement it as a cacheable prefetch). You can >>>>start by looking at the implementation of other prefetch instruction we >>>>have in gem5 (basically you can do the same :) ). >>>>2. Try compiling your application (I think we are still talking >>>>about the hello world, right?), and target an older architecture (you >>>> can >>>>do as extreme as march=athlon64) with less optimizations involved to >>>> avoid >>>>these performance-optimizations (reducing cache pollution in this >>>>particular case) that your compiler is trying to apply. >>>> >>>> My suggestion is to go with the first one, since running real >>>> applications compiled for an older architecture with less optimization on a >>>> "newer" system is the equivalent of not using "parts/features" of your >>>> system (e.g. SIMD units, direct prefetch, etc), which would (possibly) >>>> directly impact any study you are working on. >>>> >>>> Best, >>>> >>>> On Sat, Sep 7, 2019 at 8:27 PM Shehab Elsayed >>>> wrote: >>>> >>>>> I am sorry for the late update. I tried running with MESI_Two_Level >>>>> but the simulation ends with this error. >>>>> >>>>> warn: instruction 'prefetch_nta' unimplemented >>>>> >>>>> gem5.opt: build/X86_MESI_Two_Level/cpu/o3/lsq_unit.hh:621: Fault >>>>>
Re: [gem5-users] Indeterministic gem5 behavior
You can try dumping Exec trace for the last few million ticks and see what is going on in your LSQ and why you have load instruction that is not executed. Best, On Mon, Sep 9, 2019 at 11:28 AM Shehab Elsayed wrote: > I am not sure that prefetch_nta is the problem. For different runs the > simulation would fail after different periods after printing the prefetch_ > nta warning message. Also, from what I have seen in different posts it > seems that this warning has been around for a while. > > I tried compiling my hello world program with -march=athlon64 alone and > together with -O0 and the the same problem happens. > > Also, the I am building my benchmark on the disk image directly using qemu > and the gcc on the image is versio 5.4.0 > > > > On Sun, Sep 8, 2019 at 4:14 PM Pouya Fotouhi wrote: > >> Hi Shehab, >> >> Good, that's "progress"! >> My guess off the top of my head is that you used a "more recent" compiler >> (compared to what other gem5 users tend to use), and thus some instructions >> are being generated that were not critical to the execution of applications >> other users had so far (and that's mostly why those instructions are not >> yet implemented). I think you have two options: >> >>1. You can try implementing prefetch_nta, and possibly ignore the >>non-temporal hint (i.e. implement it as a cacheable prefetch). You can >>start by looking at the implementation of other prefetch instruction we >>have in gem5 (basically you can do the same :) ). >>2. Try compiling your application (I think we are still talking about >>the hello world, right?), and target an older architecture (you can do as >>extreme as march=athlon64) with less optimizations involved to avoid these >>performance-optimizations (reducing cache pollution in this >>particular case) that your compiler is trying to apply. >> >> My suggestion is to go with the first one, since running real >> applications compiled for an older architecture with less optimization on a >> "newer" system is the equivalent of not using "parts/features" of your >> system (e.g. SIMD units, direct prefetch, etc), which would (possibly) >> directly impact any study you are working on. >> >> Best, >> >> On Sat, Sep 7, 2019 at 8:27 PM Shehab Elsayed >> wrote: >> >>> I am sorry for the late update. I tried running with MESI_Two_Level but >>> the simulation ends with this error. >>> >>> warn: instruction 'prefetch_nta' unimplemented >>> >>> gem5.opt: build/X86_MESI_Two_Level/cpu/o3/lsq_unit.hh:621: Fault >>> LSQUnit::read(LSQUnit::LSQRequest*, int) [with Impl = >>> O3CPUImpl; Fault = std::shared_ptr; LSQUnit::LSQRequest = L >>> SQ::LSQRequest]: Assertion `!load_inst->isExecuted()' failed. >>> >>> Which I believe has something to do with a recent update since I don't >>> remember seeing it before. And this error happens even for just 2 cores and >>> 2 threads. >>> >>> On Fri, Sep 6, 2019 at 3:16 PM Pouya Fotouhi >>> wrote: >>> >>>> Hi Shehab, >>>> >>>> As Jason pointed out, I won’t be surprised if you are having issues >>>> with classic caches running workloads that rely on locking mechanisms. Your >>>> pthread implementation is possibly using some synchronization variables >>>> which requires cache coherence to maintain its correctness, and classic >>>> caches (at least for now) doesn’t support that. >>>> >>>> Switch to ruby caches (I suggest MESI Two Level to begin with), and >>>> given your kernel version you should be getting stable behavior from gem5. >>>> >>>> Best, >>>> >>>> On Fri, Sep 6, 2019 at 11:47 AM Jason Lowe-Power >>>> wrote: >>>> >>>>> Hi Shehab, >>>>> >>>>> IIRC, there are some issues when using classic caches + x86 + multiple >>>>> cores on full system mode. I suggest using Ruby (MESI_two_level or >>>>> MOESI_hammer) for FS simulations. >>>>> >>>>> Jason >>>>> >>>>> On Fri, Sep 6, 2019 at 11:24 AM Shehab Elsayed >>>>> wrote: >>>>> >>>>>> My latest experiments are with the classical memory system, but I >>>>>> remember trying Ruby and it was not different. I am using kernel 4.8.13 >>>>>> and >>>>>> ubuntu-16.04.1-server-amd64 disk image. I am using Pthreads for
Re: [gem5-users] Indeterministic gem5 behavior
Hi Shehab, Good, that's "progress"! My guess off the top of my head is that you used a "more recent" compiler (compared to what other gem5 users tend to use), and thus some instructions are being generated that were not critical to the execution of applications other users had so far (and that's mostly why those instructions are not yet implemented). I think you have two options: 1. You can try implementing prefetch_nta, and possibly ignore the non-temporal hint (i.e. implement it as a cacheable prefetch). You can start by looking at the implementation of other prefetch instruction we have in gem5 (basically you can do the same :) ). 2. Try compiling your application (I think we are still talking about the hello world, right?), and target an older architecture (you can do as extreme as march=athlon64) with less optimizations involved to avoid these performance-optimizations (reducing cache pollution in this particular case) that your compiler is trying to apply. My suggestion is to go with the first one, since running real applications compiled for an older architecture with less optimization on a "newer" system is the equivalent of not using "parts/features" of your system (e.g. SIMD units, direct prefetch, etc), which would (possibly) directly impact any study you are working on. Best, On Sat, Sep 7, 2019 at 8:27 PM Shehab Elsayed wrote: > I am sorry for the late update. I tried running with MESI_Two_Level but > the simulation ends with this error. > > warn: instruction 'prefetch_nta' unimplemented > > gem5.opt: build/X86_MESI_Two_Level/cpu/o3/lsq_unit.hh:621: Fault > LSQUnit::read(LSQUnit::LSQRequest*, int) [with Impl = > O3CPUImpl; Fault = std::shared_ptr; LSQUnit::LSQRequest = L > SQ::LSQRequest]: Assertion `!load_inst->isExecuted()' failed. > > Which I believe has something to do with a recent update since I don't > remember seeing it before. And this error happens even for just 2 cores and > 2 threads. > > On Fri, Sep 6, 2019 at 3:16 PM Pouya Fotouhi wrote: > >> Hi Shehab, >> >> As Jason pointed out, I won’t be surprised if you are having issues with >> classic caches running workloads that rely on locking mechanisms. Your >> pthread implementation is possibly using some synchronization variables >> which requires cache coherence to maintain its correctness, and classic >> caches (at least for now) doesn’t support that. >> >> Switch to ruby caches (I suggest MESI Two Level to begin with), and given >> your kernel version you should be getting stable behavior from gem5. >> >> Best, >> >> On Fri, Sep 6, 2019 at 11:47 AM Jason Lowe-Power >> wrote: >> >>> Hi Shehab, >>> >>> IIRC, there are some issues when using classic caches + x86 + multiple >>> cores on full system mode. I suggest using Ruby (MESI_two_level or >>> MOESI_hammer) for FS simulations. >>> >>> Jason >>> >>> On Fri, Sep 6, 2019 at 11:24 AM Shehab Elsayed >>> wrote: >>> >>>> My latest experiments are with the classical memory system, but I >>>> remember trying Ruby and it was not different. I am using kernel 4.8.13 and >>>> ubuntu-16.04.1-server-amd64 disk image. I am using Pthreads for my Hello >>>> World program. >>>> >>>> >>>> On Fri, Sep 6, 2019 at 1:13 PM Pouya Fotouhi >>>> wrote: >>>> >>>>> Hi Shehab, >>>>> >>>>> Can you confirm a few details about the configuration you are using? >>>>> Are you using classic caches or Ruby? What is the kernel version and disk >>>>> image you are using? What is the implementation of your "multithreaded >>>>> hello world" (are you using OMP)? >>>>> >>>>> Best, >>>>> >>>>> On Fri, Sep 6, 2019 at 8:58 AM Shehab Elsayed >>>>> wrote: >>>>> >>>>>> First of all, thanks for your replies, Ryan and Jason. >>>>>> >>>>>> I have already pulled the latest changes by Pouya and the problem >>>>>> still persists. >>>>>> >>>>>> As for checkpointing, I was originally doing exactly what Jason >>>>>> mentioned and ran into the same problem. I then switched to not >>>>>> checkpointing just to avoid any problems that might be caused by >>>>>> checkpointing (if any). My plan was to go back to checkpointing >>>>>> after proving that it works without it. >>>>>> >>>>>> However, the problem doesn't seem
Re: [gem5-users] Indeterministic gem5 behavior
Hi Shehab, As Jason pointed out, I won’t be surprised if you are having issues with classic caches running workloads that rely on locking mechanisms. Your pthread implementation is possibly using some synchronization variables which requires cache coherence to maintain its correctness, and classic caches (at least for now) doesn’t support that. Switch to ruby caches (I suggest MESI Two Level to begin with), and given your kernel version you should be getting stable behavior from gem5. Best, On Fri, Sep 6, 2019 at 11:47 AM Jason Lowe-Power wrote: > Hi Shehab, > > IIRC, there are some issues when using classic caches + x86 + multiple > cores on full system mode. I suggest using Ruby (MESI_two_level or > MOESI_hammer) for FS simulations. > > Jason > > On Fri, Sep 6, 2019 at 11:24 AM Shehab Elsayed > wrote: > >> My latest experiments are with the classical memory system, but I >> remember trying Ruby and it was not different. I am using kernel 4.8.13 and >> ubuntu-16.04.1-server-amd64 disk image. I am using Pthreads for my Hello >> World program. >> >> >> On Fri, Sep 6, 2019 at 1:13 PM Pouya Fotouhi >> wrote: >> >>> Hi Shehab, >>> >>> Can you confirm a few details about the configuration you are using? Are >>> you using classic caches or Ruby? What is the kernel version and disk image >>> you are using? What is the implementation of your "multithreaded hello >>> world" (are you using OMP)? >>> >>> Best, >>> >>> On Fri, Sep 6, 2019 at 8:58 AM Shehab Elsayed >>> wrote: >>> >>>> First of all, thanks for your replies, Ryan and Jason. >>>> >>>> I have already pulled the latest changes by Pouya and the problem >>>> still persists. >>>> >>>> As for checkpointing, I was originally doing exactly what Jason >>>> mentioned and ran into the same problem. I then switched to not >>>> checkpointing just to avoid any problems that might be caused by >>>> checkpointing (if any). My plan was to go back to checkpointing after >>>> proving that it works without it. >>>> >>>> However, the problem doesn't seem to be related to KVM as linux boots >>>> reliable every time. The problem happens after the benchmarks starts >>>> execution and it seems to be happening only when running multiple cores >>>> (>=4). My latest experiments with a single core and 8 threads for the >>>> benchmark seem to be working fine. But once I increase the number of >>>> simulated cores problems happen. >>>> >>>> Also, I have posted a link to the repo I am using to run my tests in a >>>> previous message. I have also added 2 debug traces with the Exec flag for a >>>> working and non-working examples. >>>> >>>> >>>> On Fri, Sep 6, 2019 at 11:28 AM Jason Lowe-Power >>>> wrote: >>>> >>>>> Hi Shehab, >>>>> >>>>> One quick note: There is *no way* to have deterministic behavior when >>>>> running with KVM. Since you are using the hardware, the underlying host OS >>>>> will influence the execution path of the workload. >>>>> >>>>> To try to narrow down the bug you're seeing, you can try to take a >>>>> checkpoint after booting with KVM. Then, the execution from the checkpoint >>>>> should be deterministic since it is 100% in gem5. >>>>> >>>>> BTW, I doubt you can run the KVM CPU in a VM since this would require >>>>> your hardware and the VM to support nested virtualization. There *is* >>>>> support for this in the Linux kernel, but I don't think it's been widely >>>>> deployed outside of specific cloud environments. >>>>> >>>>> One other note: Pouya has pushed some changes which implement some x86 >>>>> instructions that were causing issues for him. You can try with the >>>>> current >>>>> gem5 mainline to see if that helps. >>>>> >>>>> Cheers, >>>>> Jason >>>>> >>>>> On Fri, Sep 6, 2019 at 8:22 AM Shehab Elsayed >>>>> wrote: >>>>> >>>>>> That's interesting. Are you using Full System as well? I don't think >>>>>> FS behavior is supposed to be so dependent on the host environment! >>>>>> >>>>>> On Fri, Sep 6, 2019 at 11:16 AM Gambord, Ryan < >>>>>> gambo...@oregonsta
Re: [gem5-users] Full System X86 restoring from checkpoint questions
Hi Abhishek, Do you have your binary (hello_world) on your disk image? To be more precise, was the binary on the disk image when you took the checkpoint? Best, On Fri, Aug 30, 2019 at 8:26 AM Abhishek Singh < abhishek.singh199...@gmail.com> wrote: > Hello Everyone, > > I have created the checkpoint for booting up Linux image. > My command line is > """ > > build/X86/gem5.opt > --outdir=/home/abs218/gem5_dir_local/gem5_bl_fs/common_checkpoint_chkpt > --stats-file=common_checkpoint_chkpt.simout > --dump-config=common_checkpoint_chkpt.ini --redirect-stderr > --stderr-file=common_checkpoint_chkpt.e configs/example/fs.py > --checkpoint-dir=/home/abs218/gem5_dir_local/gem5_bl_fs/common_checkpoint_chkpt > --disk-image=/home/abs218/gem5_dir_local/gem5_bl_fs/intel.img > --kernel=/home/abs218/new_fs/gem5/linux-4.8.13/vmlinux > --script=./common_checkpoint.rcS --caches --l2cache > > > """ > > my common_checkpoint.rcS is > > """ > > #!/bin/sh > > /sbin/m5 checkpoint > > echo "Done :D" > > /sbin/m5 exit > > > """ > > I wanted to use this checkpoint and try to run a hello_world benchmark. > So I modify my common_checkpoint.rcS script to > """ > > #!/bin/sh > > ./hello_world > > echo "Done :D" > > /sbin/m5 exit > > """ > And my gem5 command line is > """ > ./build/X86/gem5.opt > --outdir=/home/abs218/gem5_dir_local/gem5_bl_fs/common_checkpoint_chkpt > --stats-file=common_checkpoint_chkpt_restore.simout > --dump-config=common_checkpoint_chkpt_restore.ini configs/example/fs.py > --checkpoint-restore=1 > --checkpoint-dir=/home/abs218/gem5_dir_local/gem5_bl_fs/common_checkpoint_chkpt > --restore-with-cpu=AtomicSimpleCPU --cpu-type=DerivO3CPU --caches --l2cache > --disk-image=/home/abs218/gem5_dir_local/gem5_bl_fs/intel.img > --kernel=/home/abs218/new_fs/gem5/linux-4.8.13/vmlinux > --script=./common_checkpoint.rcS > """ > But my "system.pc.com_1.device" output after restoring is > "" > > Done :D > "" > That is, it did not run the hello_world program! > > I have made no changes to gem5, the commit I am using is " > 2a98a994df296f818b05da90ba073d879562da04" > > > My question is: > Is it not possible to create a common checkpoint and then run the > benchmark using that checkpoint? > Are my steps incorrect to create or restore from the checkpoint? > > > > > Best regards, > > Abhishek > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] CPUID function 0_7 - CacheParams
Great, thanks for the explanations and info! On Wed, Aug 14, 2019 at 4:32 PM Gabe Black wrote: > We might have some support for xsave but I wasn't able to find it. We do > decode it, but I'm pretty sure we return a WarnUnimplemented instruction. I > was confusing XSAVE with FXSAVE before, where FXSAVE is part of SSE and > which we do at least partially support. I don't think we have support for > XSAVE which is another thing which saves a bunch of processor state as > selected with a mask and I think an XCR0 register (which we also don't > support) with variable sizes, etc, etc. Someone could add support for that, > but it sounds like a lot of work. > > Gabe > > On Wed, Aug 14, 2019 at 3:55 PM Pouya Fotouhi > wrote: > >> I'm still digesting some of your points, but in general, something I >> noticed in "newer" kernels is the "hard-coded" assumption for some of these >> (specially security related) features (take SMAP as an example). So, to my >> understanding, if our CPUID simply says "I don't know", in some cases >> kernel interprets that as a yes rather than a no! So, again to my limited >> knowledge, I think it'd best to respond negative until we have support for >> these features. >> >> Regarding xsave, if you recall discussions we had about change 19892 >> <https://gem5-review.googlesource.com/c/public/gem5/+/19892>, our CPUID >> returns 0x04000209 for 0_1. The most significant set bit we have is bit 26, >> which tells the kernel we do have support for xsave and then kernel tries >> to set bit 18 on CR4. Correct me if I'm wrong, but my understanding was >> that we have "some" support for xsave in gem5. Although looking at my >> kernel logs, kernel seem to disable it after some tests during SMP boot >> process (probably our support is not enough for kernel and it masks it off). >> >> Best, >> >> On Wed, Aug 14, 2019 at 3:28 PM Gabe Black wrote: >> >>> Actually it looks like somebody added a new function while skipping over >>> the ones below. That's how the unimplemented functions slipped through. I'm >>> not going to try to implement those for now, but I don't want to discourage >>> anyone that wants to do something with them. >>> >>> I'm also looking into why the kernel thinks we support xsave (which >>> seems to be fairly complicated) when we do not. I think there's just an >>> extra bit set in CPUID I need to turn off. >>> >>> Gabe >>> >>> On Wed, Aug 14, 2019 at 3:01 PM Gabe Black wrote: >>> >>>> I was actually just looking this since I noticed that one of the x86 >>>> kernels I have lying around was crashing with an undefined opcode >>>> exception. I see that the doCpuid function will just bail out for some of >>>> the functions which are below the largest it supports (so it can support >>>> the extended functions). The CPUID instruction will just leave EAX, EBX, >>>> ECX and EDX unmodified in this case since it isn't supposed to raise any >>>> type of fault. The kernel will try to interpret those fields as an actual >>>> answer since we told it those functions were supported, and depending on >>>> what executed before it do something arbitrary. We should definitely stop >>>> doing that for starters. I think this is something I partially implemented >>>> since it was blocking boot a long time ago, and then never went back and >>>> filled out. For some of these functions we may not have good answers, for >>>> instance where reporting cache sizes. I'm not sure what to do in that case. >>>> We may need to look at those fields one by one and try to come up with >>>> safe, fairly inert answers. If we can return something that says "I don't >>>> know", that would be best. >>>> >>>> The specific case I'm looking at is function 0xd though, which we would >>>> have told the kernel we don't support. That's also passing through its >>>> values which is also giving bad answers. >>>> >>>> I'll put up some CLs which fill out function constants we don't yet >>>> have, return 0 when we don't get an answer from doCpuid, and start looking >>>> at what the unimplemented functions should return. We can build on that to >>>> add in functions that are missing so the kernel at least stops tripping >>>> over itself when it gets nonsensical answers from CPUID. >>>> >>>> Gabe >>>> >>>> On Wed, Aug 14, 2019 at 2:01 PM Pouya
Re: [gem5-users] CPUID function 0_7 - CacheParams
I'm still digesting some of your points, but in general, something I noticed in "newer" kernels is the "hard-coded" assumption for some of these (specially security related) features (take SMAP as an example). So, to my understanding, if our CPUID simply says "I don't know", in some cases kernel interprets that as a yes rather than a no! So, again to my limited knowledge, I think it'd best to respond negative until we have support for these features. Regarding xsave, if you recall discussions we had about change 19892 <https://gem5-review.googlesource.com/c/public/gem5/+/19892>, our CPUID returns 0x04000209 for 0_1. The most significant set bit we have is bit 26, which tells the kernel we do have support for xsave and then kernel tries to set bit 18 on CR4. Correct me if I'm wrong, but my understanding was that we have "some" support for xsave in gem5. Although looking at my kernel logs, kernel seem to disable it after some tests during SMP boot process (probably our support is not enough for kernel and it masks it off). Best, On Wed, Aug 14, 2019 at 3:28 PM Gabe Black wrote: > Actually it looks like somebody added a new function while skipping over > the ones below. That's how the unimplemented functions slipped through. I'm > not going to try to implement those for now, but I don't want to discourage > anyone that wants to do something with them. > > I'm also looking into why the kernel thinks we support xsave (which seems > to be fairly complicated) when we do not. I think there's just an extra bit > set in CPUID I need to turn off. > > Gabe > > On Wed, Aug 14, 2019 at 3:01 PM Gabe Black wrote: > >> I was actually just looking this since I noticed that one of the x86 >> kernels I have lying around was crashing with an undefined opcode >> exception. I see that the doCpuid function will just bail out for some of >> the functions which are below the largest it supports (so it can support >> the extended functions). The CPUID instruction will just leave EAX, EBX, >> ECX and EDX unmodified in this case since it isn't supposed to raise any >> type of fault. The kernel will try to interpret those fields as an actual >> answer since we told it those functions were supported, and depending on >> what executed before it do something arbitrary. We should definitely stop >> doing that for starters. I think this is something I partially implemented >> since it was blocking boot a long time ago, and then never went back and >> filled out. For some of these functions we may not have good answers, for >> instance where reporting cache sizes. I'm not sure what to do in that case. >> We may need to look at those fields one by one and try to come up with >> safe, fairly inert answers. If we can return something that says "I don't >> know", that would be best. >> >> The specific case I'm looking at is function 0xd though, which we would >> have told the kernel we don't support. That's also passing through its >> values which is also giving bad answers. >> >> I'll put up some CLs which fill out function constants we don't yet have, >> return 0 when we don't get an answer from doCpuid, and start looking at >> what the unimplemented functions should return. We can build on that to add >> in functions that are missing so the kernel at least stops tripping over >> itself when it gets nonsensical answers from CPUID. >> >> Gabe >> >> On Wed, Aug 14, 2019 at 2:01 PM Pouya Fotouhi >> wrote: >> >>> Hi All, >>> >>> During kernel boot up with the timing/atomic/O3 CPU modes I get the >>> following kernel oops at native_flush_tlb_global. Looking closer at the >>> issue, Exec traces show: >>> >>> 2014093750: system.cpu A0 T0 : @native_flush_tlb_global+96: mov >>> eax, 0x2 >>> 2014093750: system.cpu A0 T0 : @native_flush_tlb_global+96.0 : >>> MOV_R_I : limm eax, 0x2 : IntAlu : D=0x0002 >>> flags=(IsInteger|IsMicroop|IsLastMicroop|IsFirstMicroop) >>> 2014094250: system.cpu A0 T0 : @native_flush_tlb_global+101: ud2 >>> 2014094250: system.cpu A0 T0 : @native_flush_tlb_global+101.0 : UD2 : >>> fault Invalid-Opcode : No_OpClass : >>> flags=(IsMicroop|IsLastMicroop|IsFirstMicroop) >>> 2014094500: system.cpu A0 T0 : @native_flush_tlb_global+101.32768 : >>> Microcode_ROM : slli t4, t1, 0x4 : IntAlu : D=0x0060 >>> flags=(IsInteger|IsMicroop|IsDelayedCommit) >>> >>> Looking at the decode of the "undefined" instruction raising the fault: >>> 2014094250: system.cpu: Decode: Decoded fault instruction: >>&
[gem5-users] CPUID function 0_7 - CacheParams
Hi All,
During kernel boot up with the timing/atomic/O3 CPU modes I get the
following kernel oops at native_flush_tlb_global. Looking closer at the
issue, Exec traces show:
2014093750: system.cpu A0 T0 : @native_flush_tlb_global+96: mov
eax, 0x2
2014093750: system.cpu A0 T0 : @native_flush_tlb_global+96.0 : MOV_R_I :
limm eax, 0x2 : IntAlu : D=0x0002
flags=(IsInteger|IsMicroop|IsLastMicroop|IsFirstMicroop)
2014094250: system.cpu A0 T0 : @native_flush_tlb_global+101: ud2
2014094250: system.cpu A0 T0 : @native_flush_tlb_global+101.0 : UD2 :
fault Invalid-Opcode : No_OpClass :
flags=(IsMicroop|IsLastMicroop|IsFirstMicroop)
2014094500: system.cpu A0 T0 : @native_flush_tlb_global+101.32768 :
Microcode_ROM : slli t4, t1, 0x4 : IntAlu : D=0x0060
flags=(IsInteger|IsMicroop|IsDelayedCommit)
Looking at the decode of the "undefined" instruction raising the fault:
2014094250: system.cpu: Decode: Decoded fault instruction:
{
leg = 0x10,
rex = 0,
vex/xop = 0,
op = {
type = three byte 0f38,
op = 0x82,
},
modRM = 0,
sib = 0,
immediate = 0,
displacement = 0
dispSize = 0}
Which apparently is invpcid, and dump of native_flush_tlb_global confirms:
0x81033a68 <+96>:mov$0x2,%eax
0x81033a6d <+101>: invpcid (%rcx),%rax
0x81033a72 <+106>: add$0x18,%rsp
We do not implement this instruction, and It seems like this functionality
is reported in function 0_7 of CPUID (which we do not implement).
I also have a different, yet related, issue with SMAP and FSGSBASE bits
(bits 20 and 16 in CR4), where kernel tries to set those resulting in a
fault which our CPUs can't handle and kernel panics upon them. These
functionalities are also reported by function 0_7 in CPUID which we do not
implement
I was wondering if it would be safe to simply return 0s for function 0_7? I
checked, and I couldn't find anything violating the functionalities we
support in gem5. However, I would appreciate if someone more familiar with
our support for x86 can double check
https://www.sandpile.org/x86/cpuid.htm#level__0007h and verify that
returning 0s would be fine here.
For the corner case my kernel was hitting, I tested and returning 0s would
get me past both these issues. Upon confirmation from someone in the
community, I can proceed and submit the change.
Best,
--
Pouya Fotouhi
PhD Candidate
Department of Electrical and Computer Engineering
University of California, Davis
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] X86-FS: Booting Kernel with Timing Simple CPU
|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32941 : Microcode_ROM : wrsel %ctrl128, t11w, : IntAlu : D=0x flags=(IsInteger|IsSerializing|IsSerializeAfter|IsNonSpeculative|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32942 : Microcode_ROM : limm t6, 0x14100 : IntAlu : D=0x00014100 flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32943 : Microcode_ROM : or t10, t10, t6 : IntAlu : D=0x000141ad flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32944 : Microcode_ROM : srli t5, t4, 0x28 : IntAlu : D=0x0081a08e flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32945 : Microcode_ROM : srli t7, t10, 0x9 : IntAlu : D=0x00a0 flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32946 : Microcode_ROM : xor t5, t7, t5 : IntAlu : D=0x0081a02e flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32947 : Microcode_ROM : andi t5, t5, 0x1 : IntAlu : D=0x flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32948 : Microcode_ROM : slli t5, t5, 0x9 : IntAlu : D=0x flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32949 : Microcode_ROM : or t6, t5, t6 : IntAlu : D=0x00014100 flags=(IsInteger|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32950 : Microcode_ROM : wrflags %cc0, t6b, t10b : IntAlu : D=0x0028 flags=(IsInteger|IsCC|IsSerializing|IsSerializeAfter|IsNonSpeculative|IsMicroop|IsDelayedCommit) @native_write_cr4+4.32951 : Microcode_ROM : eret 0 : No_OpClass : flags=(IsMicroop|IsLastMicroop) Best, -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Interrupt assignment in X86 FS
Hi Gabe, Thank you for your detailed response, really appreciate it! The interrupt controller I'm trying to implement (at least to begin with) is a simple one, and hopefully with the information you provided I would have a better understanding of the code (specially what needs to be implemented, if any, in SMBios table from interrupt assignments in MP tables). On a separate - yet very much related - question, do you know if the interrupt controller we setup for the IDE controller is being used at all? Best, On Sat, Jul 20, 2019 at 10:52 PM Gabe Black wrote: > Hi Pouya. I'm travelling right now so I don't have a lot of > time/opportunity to reply to email, but I'll give it a shot. I think the > code you're looking at is code which creates SimObjects which represent an > in memory table that the x86 BIOS/EFI would normally set up. That is from > the Intel MP specification which is really old and is how the OS on a > system with multiple CPUs and a more complex interrupt scheme than ye olde > PCs would figure out what the machine looked like. Other mechanisms like > ACPI have superseded it, but are generally a lot more complicated and not > as supported in gem5. I think some basic info is still in the ACPI tables > gem5 does set up, and in the SMBIOS tables which are newer than the MP > specification and older than ACPI, so you might need to modify those too. > That is just telling the OS what things look like, and you will likely need > to add something there if you add in extra interrupts. > > As far as how the interrupts are actually wired up, real PCI devices can > share interrupts. I think the original PCI bus supported 4 interrupts > called A, B, C, and D, and if you had more than 4 devices they would > necessarily have to cooperate and share at least at the driver level. I > forget if the hardware specification would make interrupt sharing work > without any special attention from the devices themselves. Later types of > PCI busses like PCI express expanded on that scheme, for instance by adding > message based interrupts. Lets just pretend those don't exist for now. > > Then there is x86's interrupt architecture. There are the legacy PICs, or > programmable interrupt controllers. Those are the IRQs 0-15 from the > original PCs. Theses were later expanded on, including in the MP > specification I mentioned before, to include APICs, advanced programmable > interrupt controllers, which have had several generations. Those split > things into an interrupt controller that lives in each core, the local > APIC, and an APIC that lives out in the system which the devices attach to > called the IO APIC. > > In gem5, the interrupt hardware is split into an interrupt controller > which lives in each core, and then some other part that varies by > architecture. The interrupt controller in x86 is the local APIC, and the > "south bridge" I think has the IO APIC implemented as a device. On other > architectures there is a platform object which more abstractly asserts or > deasserts interrupts for a device, and that gets communicated to a CPU > bound interrupt controller. On x86 I opted to make it work more like > hardware with wires which can go up or down based on what the hardware is > designed to do, and then the interrupt controller can determine what that > means based on how it's configured. Otherwise the values in those > configuration registers would just be ignored, and the system may not > behave as the driver/OS wants it to. For instance, is that a level > triggered interrupt which should keep reasserting itself? Is it edge > triggered and should only happen once? Can it be either? It's not safe to > try to guess ahead of time what the intention was. > > Interrupts in x86 are quite complicated, and setting everything up > requires at least a basic understanding of a lot of different pieces. I > can't possibly describe the whole thing in an email, but a lot of the > standards and datasheets for the original chips even the fanciest newest > CPUs pretend to have are available online. Wikipedia actually has a lot of > good info. Fortunately, if you don't try to use the fancy stuff and just > want a simple interrupt, you can gloss over a lot of things and get > something to work. Good luck! > > Gabe > > On Fri, Jul 19, 2019 at 2:59 PM Pouya Fotouhi > wrote: > >> Hi everyone, >> >> I'm trying to add a pci device, and I need to assign an interrupt line to >> the controller I created. Looking at the setup for the ide controller >> (configured as dev 4 on pci bus), we have "source_bus_irq = 0 + (4 << 2)" >> and "dest_io_apic_intin = 16" in X86IntelMPIOIntAssignment. >> >> I tried going over the code to figure out the interrupt PIN assi
[gem5-users] Interrupt assignment in X86 FS
Hi everyone, I'm trying to add a pci device, and I need to assign an interrupt line to the controller I created. Looking at the setup for the ide controller (configured as dev 4 on pci bus), we have "source_bus_irq = 0 + (4 << 2)" and "dest_io_apic_intin = 16" in X86IntelMPIOIntAssignment. I tried going over the code to figure out the interrupt PIN assignments (for both source and destination), but found it more complicated that I thought. Can anyone comment/explain on how this setup is done? Are we simply shifting the source id? Can two PCI devices share the same destination PIN given there are no logical interference? Your feedback would be appreciated! Best, -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 X86 Full System fails with DerivO3CPU
&)::{lambda(pybind11::detail::function_call&)#3}::operator()(pybind11::detail::function_call&)
>>> const (call=..., __closure=0x0) at
>>> ext/pybind11/include/pybind11/pybind11.h:153
>>>
>>> #30 void pybind11::cpp_function::initialize>> (*&)(unsigned long), GlobalSimLoopExitEvent*, unsigned long,
>>> pybind11::name, pybind11::scope, pybind11::sibling,
>>> pybind11::arg_v>(GlobalSimLoopExitEvent* (*&)(unsigned long),
>>> GlobalSimLoopExitEvent* (*)(unsigned long), pybind11::name const&,
>>> pybind11::scope const&, pybind11::sibling const&, pybind11::arg_v
>>> const&)::{lambda(pybind11::detail::function_call&)#3}::_FUN(pybind11::detail::function_call&)
>>> () at ext/pybind11/include/pybind11/pybind11.h:131
>>>
>>> #31 0x55ae5bf4 in pybind11::cpp_function::dispatcher
>>> (self=, args_in=0x72c14250, kwargs_in=0x72aed7f8) at
>>> ext/pybind11/include/pybind11/pybind11.h:629
>>>
>>> #32 0x77905697 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #33 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #34 0x77904db6 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #35 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #36 0x77904db6 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #37 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #38 0x77904db6 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #39 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #40 0x778ff029 in PyEval_EvalCode () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #41 0x77905c80 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #42 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #43 0x77904db6 in PyEval_EvalFrameEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #44 0x77a37278 in PyEval_EvalCodeEx () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #45 0x778ff029 in PyEval_EvalCode () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #46 0x779a2546 in PyRun_StringFlags () from
>>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
>>>
>>> #47 0x56479893 in m5Main (argc=, _argv=>> out>) at build/X86/sim/init.cc:303
>>>
>>> #48 0x559ba738 in main (argc=8, argv=0x7fffe358) at
>>> build/X86/sim/main.cc:69
>>>
>>>
>>>
>>> So if anyone in the community has been using x86 gem5 FS with O3CPU, let
>>> me know if there was a problem in image or kernel or a way I can find
>>> solution to this problem. Also, I think its high time we have to share a
>>> startup latest image(Ubuntu) and kernel for x86.
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Abhishek
>>> ___
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> ___
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Pouya Fotouhi
PhD Candidate
Department of Electrical and Computer Engineering
University of California, Davis
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Stopping the debugger at a given tick
Hi Radha, Just to add on top of what Jason mentioned, you may use "--debug-end" similar to how you use "--debug-start". In general, the help of your build (e.g. gem5.opt --help) should provide more info for you. Best, On Fri, Jul 12, 2019 at 9:35 AM Jason Lowe-Power wrote: > Hi Radha, > > No, there are not options to stop the debug printing. However, you *can* > stop the simulation at a particular tick. SImilarly, there are not options > to start/stop printing debug info at a particular PC. However, you can > break out of the simulation loop after a certain number of instructions. > From there, you may be able to control the debug traces from Python. I > don't remember exactly how to do this, or if it's possible. > > Cheers, > Jason > > On Fri, Jul 12, 2019 at 3:35 AM Venkatagiri, Radha > wrote: > >> Hi, >> >> I am running a large application and the trace files can get really >> large. I see that there is a --debug-start flag where I can specify a tick >> to start printing the debug statements. Is there an option to STOP printing >> the debug statements after a given tick? Also, are there flags to start and >> stop the debugger which can take the the program counter (PC) of the >> instruction as an argument? I.e., start printing the debug statements >> at/after a particular instruction is executed? >> >> Thanks, >> Radha Venkatagiri. >> ___ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Victim Cache in Ruby
MOESI protocol (MOESI_AMD_Base) models L3 caches as victim caches. Depending on the configuration you want to use, you may be able to use it. Best, On Fri, May 17, 2019 at 11:18 AM S M Farabi Mahmud wrote: > I was planning to make a Victim Cache using the ruby memory system. How to > proceed with that? > > I have seen emails where regular victim cache is mentioned. I need Victim > Cache which also supports ruby. > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Full-system experiments with MOESI AMD Base Protocol
Hi Everyone, I'm wondering if anyone has used the MOESI AMD Base protocol to run full-system experiments? For the DMA controller, I used the implementation from GCN3 staging branch <https://gem5.googlesource.com/amd/gem5/+/agutierr/master-gcn3-staging> but my experiments encounter live-locks during the bootup. Best, -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] How to use multiple channels in gem5
Hi, I suspect Nitish is using Ruby since Ruby "ignores" the number of channels. (look at configs/ruby/Ruby.py and configs/common/MemConfig.py) To have this done with Ruby, you may want to create an Xbar with multiple "memory channels" connected to it and then connect the Xbar to the directory's memory port. Best, On Wed, Mar 13, 2019 at 5:22 PM Venkata Yaswanth Raparti < yaswa...@rams.colostate.edu> wrote: > Hi, > > Have you tried with different applications? Sometimes it could be that the > application doesnt need many channels. > > On Wed, Mar 13, 2019, 2:55 PM Nitish Srivastava wrote: > >> Hi, >> >> I am trying to use HBM_1000_4H_1x64 DRAM model with 8 channels. I do this >> by passing "--mem-type=HBM_1000_4H_1x64 --mem-channels=8" parameters while >> running gem5 simulation. However, I am not getting any performance >> improvement by increasing the number of channels. Do I need to do something >> else to make use of these channels? Some kind of address mapping scheme for >> the stored data? >> >> Please let me know if you have suggestions. Any help will be appreciated. >> >> Thanks, >> Nitish >> >> >> >> ___ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Issue in MESI Three Level Protocol
Sukarn,
This is indeed a protocol issue in terms of correctness. This has already
been fixed (Change-Id: I1e7b2c05439d08579c68d8eb444e0f332e75e07f on
gerrit), reviewed and added to main repository.
Best,
*Pouya Fotouhi*
Graduate Student
Department of Electrical and Computer Engineering
University of Delaware
Newark, DE 19716
On Wed, Jan 30, 2019 at 6:23 AM Sukarn Agarwal wrote:
> Hi,
>
>
> Similar to this issue, there is also a confusion (may be i am wrong,
> please correct me on this) in the transition:
>
>
> transition({IS, S_IL0, M_IL0, E_IL0, MM_IL0}, {Inv, Fwd_GETX, Fwd_GETS}) {
> z2_stallAndWaitL2Queue;
> }
>
>
>
> The Inv event with state IS will make the deadlock situation in some of
> the parsec benchmarks. The actions for state IS on event: Inv may be like
> this:
> fi_sendInvAck;
> l_popL2RequestQueue;
>
> Thanks and Regards,
> Sukarn Agarwal
> IIT Guwahati
>
> --
> *From:* gem5-users on behalf of Shirshendu
> Das
> *Sent:* Wednesday, January 30, 2019 1:58:04 PM
> *To:* gem5-users@gem5.org
> *Subject:* [gem5-users] Issue in MESI Three Level Protocol
>
> Dear All,
> I was trying to understand the SLICC code for *MESI_Three_Level*
> protocol. During the process, I have found an issue in the protocol. Please
> correct me if I am wrong.
>
>*Caches in three level protocol:* L0 (Private), L1 (Private) and L2
> (shared).
>*The issue:* The issue is between L1 and L0. When a forwarded GETS
> request arrives at L1 (say L1-x) from any other L1 (say L1-y) via L2, the
> block is evicted from the local L0 (L0-x) before forwarding it to the
> requesting L1 (L1-y). In my understanding, a shared block should not get
> evicted from L0-x before forwarding the block to L1-y under forwarded GETS
> request.
>
>The following code is from *MESI_Three_Level_L1.sm*. In this code, in
> case of *in_msg.Type == **CoherenceRequestType:GETS,* if the block is in
> L0 then *trigger(Event:L0_Invalidate_Else, in_msg.addr,.)* is called
> to invalidate the block from L0.
>
> in_port(requestNetwork_in, RequestMsg, requestFromL2, rank = 2) {
>..
>if (in_msg.Type == CoherenceRequestType:INV) {
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) {
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Inv, in_msg.addr, cache_entry, tbe);
> }
> } else if (in_msg.Type == CoherenceRequestType:GETX ||
>in_msg.Type == CoherenceRequestType:UPGRADE) {
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) { // If the block is in L0 then remove
> it.
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Fwd_GETX, in_msg.addr, cache_entry, tbe);
> //This line is forwarding block directly from L1.
> }
> *} else if (in_msg.Type == CoherenceRequestType:GETS) {*
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) { *// If the block is in L0 then
> invalidate it.*
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Fwd_GETS, in_msg.addr, cache_entry, tbe);
> //This line is forwarding block directly from L1.
>.
>
> The *MESI_Three_Level_L0.sm* has transitions for f*wd_GETS* and
> *fwd_GETX,* but from my understanding, such transitions will never occur
> in L0 as L1 is not sending appropriate CoherenceRequest to L0. The *Actions
> *written in *MESI_Three_Level_L1.sm *are not forwarding any
> *CoherenceClass:GETS* message to L0. The *Actions* written in L1 (
> *MESI_Three_Level_L1.sm*) are only sending *CoherenceClass:INV* request
> to L0 (*MESI_Three_Level_L0.sm*).
>
> Thanks and Regards,
> Dr. Shirshendu Das
> Assistant Professor,
> Department of CSE,
> Indian Institute of Technology Ropar, Punjab, India
> http://cse.iitrpr.ac.in/shirshendu/shirshendu.html
> Ph: 9435277250
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Issue in MESI Three Level Protocol
Dr. Das,
I've been recently looking at MESI_Three_Level, and I am trying to fix some
of the issues it currently has.
The issue you mentioned, is more of a "performance issue" (a significant
one as L0s have zero support for sharing in practice) but does not impact
the correctness of the protocol.
I'll be submitting a patch to gerrit to fix this issue in the next few
days. Hopefully we'll have it reviewed and added to the public mirror soon.
Best,
*Pouya Fotouhi*
Graduate Student
Department of Electrical and Computer Engineering
University of Delaware
Newark, DE 19716
On Wed, Jan 30, 2019 at 12:28 AM Shirshendu Das
wrote:
> Dear All,
> I was trying to understand the SLICC code for *MESI_Three_Level*
> protocol. During the process, I have found an issue in the protocol. Please
> correct me if I am wrong.
>
>*Caches in three level protocol:* L0 (Private), L1 (Private) and L2
> (shared).
>*The issue:* The issue is between L1 and L0. When a forwarded GETS
> request arrives at L1 (say L1-x) from any other L1 (say L1-y) via L2, the
> block is evicted from the local L0 (L0-x) before forwarding it to the
> requesting L1 (L1-y). In my understanding, a shared block should not get
> evicted from L0-x before forwarding the block to L1-y under forwarded GETS
> request.
>
>The following code is from *MESI_Three_Level_L1.sm*. In this code, in
> case of *in_msg.Type == **CoherenceRequestType:GETS,* if the block is in
> L0 then *trigger(Event:L0_Invalidate_Else, in_msg.addr,.)* is called
> to invalidate the block from L0.
>
> in_port(requestNetwork_in, RequestMsg, requestFromL2, rank = 2) {
>..
>if (in_msg.Type == CoherenceRequestType:INV) {
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) {
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Inv, in_msg.addr, cache_entry, tbe);
> }
> } else if (in_msg.Type == CoherenceRequestType:GETX ||
>in_msg.Type == CoherenceRequestType:UPGRADE) {
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) { // If the block is in L0 then remove
> it.
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Fwd_GETX, in_msg.addr, cache_entry, tbe);
> //This line is forwarding block directly from L1.
> }
> *} else if (in_msg.Type == CoherenceRequestType:GETS) {*
> if (is_valid(cache_entry) &&
> inL0Cache(cache_entry.CacheState)) { *// If the block is in L0 then
> invalidate it.*
> trigger(Event:L0_Invalidate_Else, in_msg.addr,
> cache_entry, tbe);
> } else {
> trigger(Event:Fwd_GETS, in_msg.addr, cache_entry, tbe);
> //This line is forwarding block directly from L1.
>.
>
> The *MESI_Three_Level_L0.sm* has transitions for f*wd_GETS* and
> *fwd_GETX,* but from my understanding, such transitions will never occur
> in L0 as L1 is not sending appropriate CoherenceRequest to L0. The *Actions
> *written in *MESI_Three_Level_L1.sm *are not forwarding any
> *CoherenceClass:GETS* message to L0. The *Actions* written in L1 (
> *MESI_Three_Level_L1.sm*) are only sending *CoherenceClass:INV* request
> to L0 (*MESI_Three_Level_L0.sm*).
>
> Thanks and Regards,
> Dr. Shirshendu Das
> Assistant Professor,
> Department of CSE,
> Indian Institute of Technology Ropar, Punjab, India
> http://cse.iitrpr.ac.in/shirshendu/shirshendu.html
> Ph: 9435277250
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Finding which part of the code is being accessed
Farzad, I think you are on the right track (about the approach you are taking using gdb), but I think the problem you are having in order to get the PC value comes from the scope you are trying to access PC. After reaching the breakpoint, I would skip a few more lines of code carefully to get back to the scope of (in terms of class hierarchy) CPU. There you can get PC much easier since it's being accessed within the same class. *P.S.* I would also use cgdb (at least, or ddd if you really wanna hack into it) rather than gdb, since you can easily keep an eye on the source code at the same time. Best, *Pouya Fotouhi* Graduate Student Department of Electrical and Computer Engineering University of Delaware Newark, DE 19716 On Tue, Apr 11, 2017 at 10:13 PM, Farshchi, Farzad <farsh...@ku.edu> wrote: > Hello, > > I need to find out the virtual address of the instruction which is being > executed (i.e. program counter) when a (data) memory access to a particular > virtual page (ex. 0x000aa) takes place. The instruction address does not > have to be very precise. Using the instruction address I am going to find > out which part of the code is being executed at that moment. I am using ARM > with O3 model in FS mode. > > I am thinking of stopping gem5 using a conditional breakpoint on the > virtual page number in GDB and then, look up the PC. I know where to put > the breakpoint (TLB::translateFs). But I have trouble finding the PC in O3 > CPU. > > Thank, > Farzad > > > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
