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

2021-12-18 Thread Boris Shingarov via gem5-dev 
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 hoping that 
somewhere on the "Contributing" page the standard what the commit message 
should look like would be spelled out.  For example in the Eclipse project we 
say this on the "Contributing" page: "The first line describes the change made. 
It is written in the imperative mood, and should say what happens when the 
patch is applied. ..."  
(https://github.com/eclipse-openj9/openj9/blob/master/CONTRIBUTING.md)  To my 
surprise, gem5's "Contributing" page is silent on this matter -- although (at 
least on the few first pages of the commit log) all other commits but the ones 
in this relation-chain are consistent.

What is the procedure for PRs to the Contributing Guide?


-"Bobby Bruce via gem5-dev"  wrote: -
To: "gem5 Developer List" 
From: "Bobby Bruce via gem5-dev" 
Date: 12/03/2021 09:43PM
Cc: "Melissa Jost" , llhin...@ucdavis.edu, "Joël 
Porquet-Lupine" , "Bobby Bruce" 
Subject: [gem5-dev] LupIO: Friendly IO Devices for gem5 (reviews appreciated!)

Dear all,

Here at UC Davis two undergraduate students, Melissa Jost and Laura Hinman, 
have been working on incorporating LupIO devices into gem5.

For those unaware, LupIO devices were developed by Prof. Joel Porquet-Lupine as 
a set of open-source I/O devices to be used for teaching. They were designed to 
model a complete set of I/O devices that are neither too complex to teach in a 
classroom setting, or too simple to translate to understanding real-world 
devices. Our collection consists of a real-time clock, random number generator, 
terminal device, block device, system controller, timer device, programmable 
interrupt controller, as well as an inter-processor interrupt controller. A 
more detailed outline of LupIO can be found here: 
https://luplab.cs.ucdavis.edu/assets/lupio/wcae21-porquet-lupio-paper.pdf . 
Within gem5, these devices offer the capability to run simulations with a 
complete set of I/O devices that are both easy to understand and manipulate.

Prior to Melissa and Laura's work these devices were only available for use 
with QEMU. They have worked diligently over the past term to incorporate these 
into gem5 for the RISCV ISA. They have incrementally added each device into 
gem5, and into a LupV gem5 Board (LupvBoard) which, when using gem5 alongside 
the correct device drivers in Linux, provides the capability of booting a 
RISC-V Linux system with SMP support.

At present this work exists as a relation-chain in Gerrit: 
https://gem5-review.googlesource.com/c/public/gem5/+/53040. We would appreciate 
feedback on this relation-chain by those interested in this work. We hope we 
can get this chain submitted into the develop branch soon so it can be part of 
the gem5 v21.2 release.

For those interested in setting up and running the LupvBoard, an example 
configuration script has been included at the top of the relation chain: 
https://gem5-review.googlesource.com/c/public/gem5/+/53046.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

2021-12-18 Thread Boris Shingarov via gem5-dev 
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 to hope that what we are witnessing is the start of a common 
phenomenon which will rapidly grow beyond VT and UC Davis.

I don't imagine there is much RISC-V-specific stuff in this relation-chain, so 
it should be easy to make LupIO work with OpenPOWER too, right?

-"Bobby Bruce via gem5-dev"  wrote: -
To: "gem5 Developer List" 
From: "Bobby Bruce via gem5-dev" 
Date: 12/03/2021 09:43PM
Cc: "Melissa Jost" , llhin...@ucdavis.edu, "Joël 
Porquet-Lupine" , "Bobby Bruce" 
Subject: [gem5-dev] LupIO: Friendly IO Devices for gem5 (reviews appreciated!)

Dear all,

Here at UC Davis two undergraduate students, Melissa Jost and Laura Hinman, 
have been working on incorporating LupIO devices into gem5.

For those unaware, LupIO devices were developed by Prof. Joel Porquet-Lupine as 
a set of open-source I/O devices to be used for teaching. They were designed to 
model a complete set of I/O devices that are neither too complex to teach in a 
classroom setting, or too simple to translate to understanding real-world 
devices. Our collection consists of a real-time clock, random number generator, 
terminal device, block device, system controller, timer device, programmable 
interrupt controller, as well as an inter-processor interrupt controller. A 
more detailed outline of LupIO can be found here: 
https://luplab.cs.ucdavis.edu/assets/lupio/wcae21-porquet-lupio-paper.pdf . 
Within gem5, these devices offer the capability to run simulations with a 
complete set of I/O devices that are both easy to understand and manipulate.

Prior to Melissa and Laura's work these devices were only available for use 
with QEMU. They have worked diligently over the past term to incorporate these 
into gem5 for the RISCV ISA. They have incrementally added each device into 
gem5, and into a LupV gem5 Board (LupvBoard) which, when using gem5 alongside 
the correct device drivers in Linux, provides the capability of booting a 
RISC-V Linux system with SMP support.

At present this work exists as a relation-chain in Gerrit: 
https://gem5-review.googlesource.com/c/public/gem5/+/53040. We would appreciate 
feedback on this relation-chain by those interested in this work. We hope we 
can get this chain submitted into the develop branch soon so it can be part of 
the gem5 v21.2 release.

For those interested in setting up and running the LupvBoard, an example 
configuration script has been included at the top of the relation chain: 
https://gem5-review.googlesource.com/c/public/gem5/+/53046.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Kokoro bit

2021-07-05 Thread Boris Shingarov via gem5-dev 
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 actually means more things than "just" this series of patches.  The thing that LabWare cares about, is that the compiler community can start reproducing our experiments without the need to mess with 3rd-party patches to gem5.  And POWER-64 is one part of it, the other part is the improved guest-debugging.  So, I am re-testing now that these play together.  After that, we are open to intriguing new worlds, from synthesizing a superoptimizer from the mdwn pseudocode, to multi-way co-verification (mdwn/gem5/valgrind), to translating mdwn to Coq definitions.-"lkcl"  wrote: -To: "Boris Shingarov" From: "lkcl" Date: 07/04/2021 03:25PMCc: "Gabe Black" , "Jason Lowe-Power via gem5-dev" , "Sandipan Das" Subject: Re: Kokoro bithttps://urldefense.proofpoint.com/v2/url?u=https-3A__gem5-2Dreview.googlesource.com_c_public_gem5_-2B_40906_7=DwIBaQ=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=t7AgTiyWbVbY_S7RymZ-4qak05WVjImfP54H5HPEq1A=5mnKd36afIaUm7_mxCFLpYkgMgyyfgpFyuJ1KDAToyw= are all these done? i just checked and the entire list now says "merged"if so that's fantastic news.  are there any more i need to keep an eye on?l.___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Kokoro bit

2021-06-24 Thread Boris Shingarov via gem5-dev 
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 to set that
>>> bit is given to a fairly small number of people".

>> Yes, but since you are a maintainer you have a level of trust greater
>> than a random anonymous person that just signed up for a gerrit
>> account :-). I can set that bit now if you can't, but we should look
>> into making it so you can.

> Thia probably makes sense as there is lots of work ahead on POWER.
> I'll merge and close 40883 now, therefore we should move this
> discussion to email or something.

I think it's about time to start being active about it, this is creating
unneeded load on you and getting in the way of work.  For example
https://gem5-review.googlesource.com/c/public/gem5/+/40896
is still sitting static since I reviewed it on June 3.

I tried reading various pieces on Gerrit to try and understand what's
going on, but because I am not any kind of admin there is really not
much that's visible to me (especially in the area of interfacing to
kokoro).  I am not sure who the correct person to talk to is -- maybe
Jason?

Best,
Boris
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Upstreaming power-gem5

2021-04-21 Thread Boris Shingarov via gem5-dev 
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"  wrote: -To: "Boris Shingarov" From: "Sandipan Das via gem5-dev" Date: 04/19/2021 09:09AMCc: "gem5 Developer List" , "Sandipan Das" Subject: [gem5-dev] Re: Upstreaming power-gem5Hi Boris,On 14/04/21 11:43 pm, Boris Shingarov wrote:> 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 example> https://urldefense.proofpoint.com/v2/url?u=https-3A__gem5-2Dreview.googlesource.com_c_public_gem5_-2B_42943=DwICAg=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=DI6zOlzR8c3l8AQxCfEXIndX4KH7YKA_u6nYj1gSFxU=-UyG89zz-zPUQzlLrjPlIVIQyFDe4w16PRIMrTvPCsw=  > > > Do you want to start merging (what Gerrit calls "submit") them?> Sure. Sorry I could not respond earlier as I was on vacation but going forward,I'll keep that in mind. Thanks for merging a few of the initial patches.- Sandipan___gem5-dev mailing list -- gem5-dev@gem5.orgTo unsubscribe send an email to gem5-dev-le...@gem5.org%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Upstreaming power-gem5

2021-04-14 Thread Boris Shingarov via gem5-dev 
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 Gerrit calls "submit") them?Boris___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Upstreaming power-gem5

2021-02-04 Thread Boris Shingarov via gem5-dev 
> 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.  I've been waiting on 86222736e (which just got in) before submittinghttps://gem5-review.googlesource.com/c/public/gem5/+/40635 ,could you please code-review that?  Then, we are ready to merge your e52dbcb.> The current sequence breaks 32-bit support in> the beginning and then restores it back towards the end.Up to you really.  My guess is that when you look at how much `develop` has diverged in the past months, you will find keeping the sequence less of a thing.-"Sandipan Das"  wrote: -To: "Boris Shingarov" From: "Sandipan Das" Date: 02/04/2021 06:23AMCc: basava...@nitk.edu.in, "Pratik Rajesh Sampat" , "Kajol Jain" , "Gautham R. Shenoy" , "gem5 Developer List" Subject: Re: [gem5-dev] Re: Upstreaming power-gem5Hello Boris,On 04/02/21 12:43 am, Boris Shingarov wrote:>> 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.> Sure.>> Yes, I can submit it via gerrit.>> As a kernel developer, I am more used to mailing list based reviews>> but feel free to let me know what works best for you.> > Gerrit is the procedure currently used by the gem5 community.  Even though I personally find it non-ideal, it is kind of a given for the foreseeable future, and I think the optimal scenario (within the realistic choices) would be if you started upstreaming using that procedure.  The other alternative, of which I was afraid before I initially wrote to you, would have been if you had abandoned the project or had no time/energy to do the rebasing / pushing / working with the review, in that case I was thinking about just taking your patches and putting them on Gerrit myself but I can see a whole number of reasons to avoid this.> > Sure, I'll submit the changes via Gerrit.Aside from rebasing on top of the develop branch, I think it willbe easier for us if I bring all the 32-bit cleanups and fixes tothe beginning of the series and then introduce 64-bit mode followedby new instructions. The current sequence breaks 32-bit support inthe beginning and then restores it back towards the end. Wonderingif that could be a problem with the CI?- Sandipan___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Upstreaming power-gem5

2021-02-03 Thread Boris Shingarov via gem5-dev 
> 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 mailing list based reviews
> but feel free to let me know what works best for you.

Gerrit is the procedure currently used by the gem5 community.  Even though I 
personally find it non-ideal, it is kind of a given for the foreseeable future, 
and I think the optimal scenario (within the realistic choices) would be if you 
started upstreaming using that procedure.  The other alternative, of which I 
was afraid before I initially wrote to you, would have been if you had 
abandoned the project or had no time/energy to do the rebasing / pushing / 
working with the review, in that case I was thinking about just taking your 
patches and putting them on Gerrit myself but I can see a whole number of 
reasons to avoid this.


-"Sandipan Das"  wrote: -
To: "Boris Shingarov" 
From: "Sandipan Das" 
Date: 02/03/2021 01:30PM
Cc: basava...@nitk.edu.in, "Pratik Rajesh Sampat" , 
"Kajol Jain" , "Gautham R. Shenoy" 
, "gem5 Developer List" 
Subject: Re: [gem5-dev] Re: Upstreaming power-gem5

Hello Boris,

On 03/02/21 2:34 am, Boris Shingarov wrote:
> 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 the most 
> realistic technically, and with my project's priorities.
> 

Great!

>> You can find them here: [develop-power]
> 
> Some of these commits just scream as the perfect first candidates, for 
> example 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_gem5_commit_3dd0438159d67fe2b5bcc777b43046fdca90f6b9=DwICaQ=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU=qRcEv2oabPve_Q2GdbmZOqMVBxL32Co3y4ROuJevXDA=
>  and related.  Because right now the Decoder is in a really sad state, 
> crashing even on simple, perfectly valid programs (and that's even within BE, 
> 32-bit SE), see for example 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gem5.atlassian.net_browse_GEM5-2D819=DwICaQ=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU=ST81CURwY4zbSASQ6L3PKNAA0FC7ia8-GQTVzzunqEs=.
>   So, how about we start from that one?  How would you like to proceed -- do 
> you want to submit on Gerrit using the regular process a
 nd I will review it?
> 

I think I had come across that problem too but I am sure
that one of my patches will fix that. Probably this one:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_gem5_commit_3b0203e63d892c94fd0e67cfe79f5e6662504c4a=DwICaQ=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU=GAbuvqL0DsFG6QcbNsVo4liY1x1U2DR8YE0ekWQDYE8=

>> this has been a hobby/side project and hence, the biggest
>> challenge for us has been finding spare cycles
> 
> At my day job at LabWare, I write JIT compilers, and the development 
> technology is centered around simulation -- so I can't draw a bright line 
> where gem5 stops being a "side" project and becomes part of the "main" 
> project because the latter depends on it.  But it does mean that I naturally 
> have more timeslices for some aspects of gem5 than for other aspects.
>>> So, in order for external UARTs like 8250 to be
>> used for console interactions, we currently use some hacks
>> which I am sure are not quite upstreamable
> 
> Yeah, we are in the same boat here.
> I, too, have a long queue of hacks to gem5 which I did just to enable some 
> experiments with the JIT compiler; they've been waiting *years* that I rework 
> them into "real" patches to go upstream -- but that stage of work is very 
> slow and painful labour.
> 

Sounds interesting. I have minimal experience with JIT
compilers having worked on the Linux kernel's in-built
eBPF JIT compilers. Have peeked into Qemu's TCG too.

On that note, are there any plans to add a JIT engine
to gem5? Since gem5 supports checkpoints, uninteresting
parts of a program can be run in JITed mode to speed
things up.

>> The FS mode changes depend on 64-bit support but aside from that,
>> it also needs a fair amount
> 
> What scares me every time I think about FS, is that it will need coordinating 
> across projects/communities (Kernel, OPAL, ...) where I don't have a lot of 
> background in.  Well, let's worry about FS when the time comes.
> 

The folks that I work with here at IBM LTC can assist us
with that. Besides, like we agreed, lets start with SE
mode.


- Sandipan

[gem5-dev] Re: Upstreaming power-gem5

2021-02-02 Thread Boris Shingarov via gem5-dev 
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 the most 
realistic technically, and with my project's priorities.

> You can find them here: [develop-power]

Some of these commits just scream as the perfect first candidates, for example 
https://github.com/sandip4n/gem5/commit/3dd0438159d67fe2b5bcc777b43046fdca90f6b9
 and related.  Because right now the Decoder is in a really sad state, crashing 
even on simple, perfectly valid programs (and that's even within BE, 32-bit 
SE), see for example https://gem5.atlassian.net/browse/GEM5-819.  So, how about 
we start from that one?  How would you like to proceed -- do you want to submit 
on Gerrit using the regular process and I will review it?

> this has been a hobby/side project and hence, the biggest
> challenge for us has been finding spare cycles

At my day job at LabWare, I write JIT compilers, and the development technology 
is centered around simulation -- so I can't draw a bright line where gem5 stops 
being a "side" project and becomes part of the "main" project because the 
latter depends on it.  But it does mean that I naturally have more timeslices 
for some aspects of gem5 than for other aspects.

> So, in order for external UARTs like 8250 to be
> used for console interactions, we currently use some hacks
> which I am sure are not quite upstreamable

Yeah, we are in the same boat here.
I, too, have a long queue of hacks to gem5 which I did just to enable some 
experiments with the JIT compiler; they've been waiting *years* that I rework 
them into "real" patches to go upstream -- but that stage of work is very slow 
and painful labour.

> The FS mode changes depend on 64-bit support but aside from that,
> it also needs a fair amount

What scares me every time I think about FS, is that it will need coordinating 
across projects/communities (Kernel, OPAL, ...) where I don't have a lot of 
background in.  Well, let's worry about FS when the time comes.

Best,
Boris

-"Sandipan Das via gem5-dev"  wrote: -
To: "Boris Shingarov" 
From: "Sandipan Das via gem5-dev" 
Date: 02/02/2021 01:51AM
Cc: gem5-dev@gem5.org, basava...@nitk.edu.in, "Pratik Rajesh Sampat" 
, "Kajol Jain" , "Gautham R. 
Shenoy" , "Sandipan Das" 
Subject: [gem5-dev] Re: Upstreaming power-gem5

Hello Boris,

On 02/02/21 12:16 am, Boris Shingarov wrote:
> 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 

Glad to hear that!

> OpenPOWER Summit presentation is that you intend to upstream it.  So I am 
> curious where we are with that.  What I am trying to avoid is duplication of 
> discovery of things that perhaps you already discovered.  E.g., maybe you 
> bumped 
> into some insurmountable difficulty which makes continuing not worth it -- in 
> that case I don't want to spend 6 months just to step on the same rake.  
> Therefore: could you shed some light on the project's current status?
> 

The branch 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_power-2Dgem5_gem5_tree_gem5-2Dexperimental=DwICAg=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=ShAYB3Pcfsf4iPB8eGfUCvXq0wsOkLoxe8D4iOT4xwk=WTGZ46b3Jt8TnFed5JHiUmjGqOkSbWw6zweY636-mxs=)
where we have all of the changes that make FS mode support possible for
the Power ISA is fairly out-of-date, at least by a couple of years now.
Since there are quite a few patches, we would like them to be reviewed
and merged in phases.

We began by adding 64-bit instruction support and I do try to rebase
and maintain this specific subset of patches. 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. You can find them here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_gem5_tree_develop-2Dpower=DwICAg=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4=ShAYB3Pcfsf4iPB8eGfUCvXq0wsOkLoxe8D4iOT4xwk=r4nvg7zCEouEpWEUu5RzPsRcg0Ru61E2Li3V3axSfeI=

The FS mode changes depend on 64-bit support but aside from that, it
also needs a fair amount of cleanup in order to meet the patch submission
requirements. We can again split this into multiple phases based on the
sequence in which MMU, interrupts and OPAL firmware + Linux kernel support
get added. That being said, there are bits like external interrupt support
that requires us to add a supported interrupt controller, such as XICS
or XIVE, which are still missing. So, in order for external UARTs like
8250 to be used for

[gem5-dev] Upstreaming power-gem5

2021-02-01 Thread Boris Shingarov via gem5-dev 
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 we are with that.  What I am trying to avoid is duplication of discovery of things that perhaps you already discovered.  E.g., maybe you bumped into some insurmountable difficulty which makes continuing not worth it -- in that case I don't want to spend 6 months just to step on the same rake.  Therefore: could you shed some light on the project's current status?Best,Boris___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: A call for maintainers

2020-10-21 Thread Boris Shingarov via gem5-dev 
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 pretty much guaranteed that the amount of time we will be devoting to it, is only going to increase.-"Jason Lowe-Power via gem5-dev"  wrote: -To: "gem5 Developer List" From: "Jason Lowe-Power via gem5-dev" Date: 10/16/2020 06:27PMCc: "Jason Lowe-Power" Subject: [gem5-dev] A call for maintainersHi everyone!As you all are aware, we're pushing to increase the stability of gem5. However, at the same time, we're seeing a significant increase in the rate of gem5 changes. Between gem5-20.0 and gem5-20.1 we had over 650 commits! And, that doesn't count the many changes on gerrit that never got reviewed :(.We need help reviewing! One of the steps we're taking to help with this is to assign specific maintainers to review every patch (automatically).There is a change on gerrit to do this: https://gem5-review.googlesource.com/c/public/gem5/+/34737 Please let us know if there are any comments.In that commit is a new file which specifies the maintainers in a machine-readable format. Now, for the ask: We're looking for volunteers for all of the components that are missing maintainers! Being a maintainer comes with the responsibility of reviewing patches in a timely fashion, but it also means that you can influence the changes in gem5!See https://gem5-review.googlesource.com/c/public/gem5/+/34737/17/util/gerrit_bot/MAINTAINERS.jsonSpecifically, if you would like to become the maintainer for any of the following sub-components, simply reply to this email! Additionally, if you have suggestions for other ways to break down these components, feel free to comment on the changeset linked above.- arch-mips- arch-power- base- cpu- cpu-minor- cpu-o3- cpu-simple- dev- ext- misc- stats- systemHave a great weekend!Cheers,Jason
___gem5-dev mailing list -- gem5-dev@gem5.orgTo unsubscribe send an email to gem5-dev-le...@gem5.org%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

2020-08-07 Thread Boris Shingarov via gem5-dev 
> I don't see any race condition here. If gem5 has been told to wait, it  
> waits. If gdb has connected to it and hasn't told it to keep running, it  
> blocks.

But it doesn't work.  Try the following experiment: in the gdb source introduce 
a time-delay somewhere after connecting to the TCP port but before sending the 
very first bytes; for example like this:

diff --git a/gdb/remote.c b/gdb/remote.c
index 59075cb09f..60a5e80481 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -4562,6 +4562,8 @@ remote_target::start_remote (int from_tty, int extended_p)
   struct packet_config *noack_config;
   char *wait_status = NULL;
 
+usleep(300);
+
   /* Signal other parts that we're going through the initial setup,
  and so things may not be stable yet.  E.g., we don't try to
  install tracepoints until we've relocated symbols.  Also, a
...

Without the usleep, gem5 blocks.  With the usleep, gem5 doesn't block.
Just for fun I tried with GNU gdbserver and with Xilinx XMD just now, and both 
block in both cases.


-"Gabe Black via gem5-dev"  wrote: -
To: "gem5 Developer List" 
From: "Gabe Black via gem5-dev" 
Date: 08/07/2020 04:34AM
Cc: "Boris Shingarov" , "Gabe Black" 

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

I think this code was originally written by Nate who is no longer with us. 
Looking at it, what I *think* it's doing starts in listen(). That sets up a 
poll queue event which listens for connection from gdb. When that gets 
triggered, that (slightly indirectly) calls connect which will check if 
somebody is already attached, and if not call the attach function. That will 
set up a poll queue event which waits for data to show up on the new 
connection. Once that happens, the incomingData method is called, and that sets 
up an event which will trigger at the next instruction boundary so that the 
remote GDB stub is operating synchronously with the rest of gem5 I think, and 
also so that it's not trying to look at state half way through an instruction. 
When that trap event fires, it calls the trap() method.

So at this point we know that there was a connect, we got sent data through it, 
and we're at an instruction boundary, if we're entering the debug loop because 
gdb connected to us.

If we're entering the gdb loop for some other reason (in the comment there it 
mentions the kernel's debug stub running in the guest triggering a breakpoint) 
then that's what I think that "if" is for. If we aren't active (because we 
didn't call attach() yet, ie no gdb has connected to us), then record that we 
are in fact active. If we were already active, ie gdb was already talking to 
us, tell it we got a trap and it can send us commands.

Regardless, then we try to read commands from gdb and execute them one by one. 
Getting commands is started by the recv(data) call in that function which 
eventually trickles down to a call to read() on the socket to retrieve a byte. 
If that blocks, then gdb hasn't told us what to do yet.

In the case where the CPU has been told to wait for GDB, gem5 just blocks after 
the GDB stub has been created until something connects to it.

I don't see any race condition here. If gem5 has been told to wait, it waits. 
If gdb has connected to it and hasn't told it to keep running, it blocks.

If, on the other hand, somebody throws a BadClient exception, for instance 
because the data from gdb is malformed, then gdb will be disconnected and the 
command loop will exit. This prevents a rogue connection or a misbehaving 
client from jamming up the gdb server and locking the simulation from 
progressing. The client can attempt to reattach to continue debugging which 
would act like a connection reboot, flushing away the broken connection and 
starting over. Also commands which return false tell the command loop 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" 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 via gem5-dev" 
 Date: 08/06/2020 08:14PM
 Cc: "Boris Shingarov" 
 Subject: [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 presence being ignored.  It's like "hey gdb,I know you 
already connected, but if you aren't quick enough that the qSupported reaches 
the queue within N ms after connecting, I am going ahead without you; (and n

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

2020-08-06 Thread Boris Shingarov via gem5-dev 
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 via gem5-dev" 
Date: 08/06/2020 08:14PM
Cc: "Boris Shingarov" 
Subject: [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 presence being ignored.  It's like "hey gdb,I know you 
already connected, but if you aren't quick enough that the qSupported reaches 
the queue within N ms after connecting, I am going ahead without you; (and no I 
am not telling you what N is)".

It looks like one fundamental issue here is the historical packet-oriented 
nature of RSP.  But it also looks like remote_gdb.cc:434,

if (!active) {
active = true;
} else {
// Tell remote host that an exception has occurred.
send(csprintf("S%02x", type).c_str());
}

plays a central role.
Can someone comment on how this is intended to work?  I must admit the comment 
above that code doesn't make sense to me.
 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

2020-08-06 Thread Boris Shingarov via gem5-dev 
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 like "hey gdb,I know you 
already connected, but if you aren't quick enough that the qSupported reaches 
the queue within N ms after connecting, I am going ahead without you; (and no I 
am not telling you what N is)".

It looks like one fundamental issue here is the historical packet-oriented 
nature of RSP.  But it also looks like remote_gdb.cc:434,

if (!active) {
active = true;
} else {
// Tell remote host that an exception has occurred.
send(csprintf("S%02x", type).c_str());
}

plays a central role.
Can someone comment on how this is intended to work?  I must admit the comment 
above that code doesn't make sense to me.
 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s