[gem5-dev] Commit message guidelines (was: LupIO: Friendly IO Devices for gem5)

I was reading through this relation-chain and the only thing that looked not quite right is the inconsistent commit message style: some of these commits have it in indicative mood, sometimes in imperative, sometimes plural and sometimes singular. Frankly this is rather distracting. I was

[gem5-dev] Re: LupIO: Friendly IO Devices for gem5 (reviews appreciated!)

This is very interesting especially in view of what Prof. Wu Feng said in this year's OpenPOWER conference about "vertically integrated" teaching: https://www.youtube.com/watch?v=nfOzppTBiQE His curriculum is also based on gem5 (although for the ISA he uses OpenPOWER, not RISC-V). I would like

[gem5-dev] Re: Kokoro bit

Yes, the POWER 64-bit SE is upstreamed now.  I agree with your characterization of it as "fantastic news".I am now in the middle of a large-scale test before I can declare that we ("we" = the JIT-compiler group at LabWare) are happy with the state of POWER on gem5 for the coming release.  This

[gem5-dev] Kokoro bit

Gabe, Following the discussion in https://gem5-review.googlesource.com/c/public/gem5/+/40883 >>> You and I did discuss this in 37295, where you explained that the >>> maintainer-bit and running-of-regressions is separate on purpose, as >>> "using kokoro resources is subject to abuse, the ability

[gem5-dev] Re: Upstreaming power-gem5

Perfect.In accord with the latest email from Jason, I created GEM5-959:https://gem5.atlassian.net/browse/GEM5-959but I left the "Assignee" field blank as I will leave the choice to you whether you prefer to have your or my name in that field.-"Sandipan Das via gem5-dev"

[gem5-dev] Re: Upstreaming power-gem5

Hi Sandipan,I notice some of the commits (which were, if not blocking reviewing other commits, but at least making comprehension of the whole body of commits harder for me) are ready for merge, for examplehttps://gem5-review.googlesource.com/c/public/gem5/+/42943Do you want to start merging (what

[gem5-dev] Re: Upstreaming power-gem5

> The current sequence breaks 32-bit support in> the beginning and then restores it back towards the end.> Wondering if that could be a problem with the CI?I would be surprised if there is even any POWER-specific CI at all.The one POWER binary we had (in test-progs), was removed at c1ebdf66f. 

[gem5-dev] Re: Upstreaming power-gem5

> I think I had come across that problem too but I am sure > that one of my patches will fix that. Probably this one Yes -- that's what I meant by "commits related to 3dd04381". So, let's start with this small area. > Yes, I can submit it via gerrit. > As a kernel developer, I am more used to

[gem5-dev] Re: Upstreaming power-gem5

Hi Sandipan, > This makes it possible > to run both 32-bit and 64-bit big and little endian PowerPC binaries > in SE mode. If its okay with you, we can start by working on trying to > get these changes reviewed and merged first. Yes, yes! This aligns very well with both what sequence I think is

[gem5-dev] Upstreaming power-gem5

Dear Basavaraj, Sandipan and other contributors to power-gem5:I am currently the maintainer of arch-power in gem5 and I am interested in upstreaming power-gem5 to the mainline gem5.  My understanding from your OpenPOWER Summit presentation is that you intend to upstream it.  So I am curious where

[gem5-dev] Re: A call for maintainers

I'll happily take arch-mips and arch-power.I was hoping that the author of the power64 fork would merge that work upstream and take over arch-power, but it looks like there is no activity on that project.  At the same time, Power is becoming the dominant architecture here in my group, so it is

[gem5-dev] Re: Possible race condition (Remote GDB)

to exit. This is how the continue command breaks out of the loop so the simulation can progress. Gabe On Thu, Aug 6, 2020 at 5:25 PM Boris Shingarov via gem5-dev wrote: It gets worse: I am beginning to suspect that this race is what ultimately causes the "xml for the wrong xlen&qu

[gem5-dev] Re: Possible race condition (Remote GDB)

It gets worse: I am beginning to suspect that this race is what ultimately causes the "xml for the wrong xlen" mystery (if the timing is unlucky, the CSPR isn't set yet). -----"Boris Shingarov via gem5-dev" wrote: - To: gem5-dev@gem5.org From: "Boris Shingarov v

[gem5-dev] Possible race condition (Remote GDB)

It looks to me that there is a race condition inherent in the design of DataEvent. The effect is that, even when CPU.wait_for_gdb attr is set and after the the RSP socket has connected, the relative timing of gdb's vs gem5's execution may or may not lead to gdb's resece being ignored. It's