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" <gem5-dev@gem5.org> wrote: ----- To: "Boris Shingarov" <shinga...@labware.com> From: "Sandipan Das via gem5-dev" <gem5-dev@gem5.org> Date: 02/02/2021 01:51AM Cc: gem5-dev@gem5.org, basava...@nitk.edu.in, "Pratik Rajesh Sampat" <psam...@linux.ibm.com>, "Kajol Jain" <kj...@linux.ibm.com>, "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>, "Sandipan Das" <sandi...@linux.ibm.com> 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&d=DwICAg&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=ShAYB3Pcfsf4iPB8eGfUCvXq0wsOkLoxe8D4iOT4xwk&s=WTGZ46b3Jt8TnFed5JHiUmjGqOkSbWw6zweY636-mxs&e=) 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&d=DwICAg&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=ShAYB3Pcfsf4iPB8eGfUCvXq0wsOkLoxe8D4iOT4xwk&s=r4nvg7zCEouEpWEUu5RzPsRcg0Ru61E2Li3V3axSfeI&e= 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 console interactions, we currently use some hacks which I am sure are not quite upstreamable. I did write a console driver for OPAL firmware that allows the Linux kernel to use an alternative firmware-provided console device but that has not been merged either. Plus there are other quirks in OPAL firmware that will need to go in since gem5 will not support any form of power management (sleep states, etc.). These changes can be found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_skiboot_commits_gem5-2Ddevel&d=DwICAg&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=ShAYB3Pcfsf4iPB8eGfUCvXq0wsOkLoxe8D4iOT4xwk&s=w2B_yOzjPZ01TSLourziToUpREIipgIekHOucZTHVVg&e= For those of us at IBM Linux Technology Center (LTC), this has been a hobby/side project and hence, the biggest challenge for us has been finding spare cycles to work on improving, cleaning up and keeping things up-to-date. We still absolutely intend to get these merged. - 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 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
