| Message ID | cover.1539023064.git.alistair.francis@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Misc RISC-V patches | expand |
On Mon, 08 Oct 2018 11:25:07 PDT (-0700), Alistair.Francis@wdc.com wrote: > These are some patches that I have cherry picked from Michael's RISC-V > tree that are ready to be applied. > Unless anyone has any comments against these I'll send a PR later this > week. > > Michael Clark (5): > RISC-V: Allow setting and clearing multiple irqs > RISC-V: Move non-ops from op_helper to cpu_helper > RISC-V: Update CSR and interrupt definitions > RISC-V: Add missing free for plic_hart_config > RISC-V: Don't add NULL bootargs to device-tree > > hw/riscv/sifive_clint.c | 8 +- > hw/riscv/sifive_plic.c | 4 +- > hw/riscv/sifive_u.c | 4 +- > hw/riscv/spike.c | 6 +- > hw/riscv/virt.c | 6 +- > target/riscv/Makefile.objs | 2 +- > target/riscv/cpu.c | 6 +- > target/riscv/cpu.h | 22 +- > target/riscv/cpu_bits.h | 683 +++++++++++++----------- > target/riscv/{helper.c => cpu_helper.c} | 35 +- > target/riscv/op_helper.c | 34 +- > 11 files changed, 438 insertions(+), 372 deletions(-) > rename target/riscv/{helper.c => cpu_helper.c} (95%) I tried pinging Michael but he hasn't responded. As far as I'm concerned, as long as you've tested these then they seem fine -- they look pretty safe. If you're not set up to make QEMU PRs then I can do so, as we should really get the ball rolling on our big patch backlog.
On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: > we should really > get the ball rolling on our big patch backlog. Yes, please do. Softfreeze is not all that far away and I would strongly prefer not to get an enormous sized pull request at the last minute. The ideal pattern is that code changes come in at a steady rate across the whole of the 'open' part of the development cycle. thanks -- PMM
On 10/10/2018 11:10 AM, Peter Maydell wrote: > On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: >> we should really >> get the ball rolling on our big patch backlog. > > Yes, please do. Softfreeze is not all that far away and I > would strongly prefer not to get an enormous sized pull > request at the last minute. The ideal pattern is that > code changes come in at a steady rate across the whole > of the 'open' part of the development cycle. Understandable. I'll send a PR in the next few days. I'm hoping I can bundle it with my PCIe patches which are just waiting on some discussion. Alistair > > thanks > -- PMM >
On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.maydell@linaro.org wrote: > On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: >> we should really >> get the ball rolling on our big patch backlog. > > Yes, please do. Softfreeze is not all that far away and I > would strongly prefer not to get an enormous sized pull > request at the last minute. The ideal pattern is that > code changes come in at a steady rate across the whole > of the 'open' part of the development cycle. Ya, sorry, we've been a bit out of it. If I understand correctly, the soft freeze is the 30th? If so it's really time to get started, and it looks like Michael is busy so I'll have to go figure this out.
On 10 October 2018 at 19:22, Palmer Dabbelt <palmer@sifive.com> wrote: > On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.maydell@linaro.org wrote: >> >> On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: >>> >>> we should really >>> get the ball rolling on our big patch backlog. >> >> >> Yes, please do. Softfreeze is not all that far away and I >> would strongly prefer not to get an enormous sized pull >> request at the last minute. The ideal pattern is that >> code changes come in at a steady rate across the whole >> of the 'open' part of the development cycle. > > > Ya, sorry, we've been a bit out of it. If I understand correctly, the soft > freeze is the 30th? If so it's really time to get started, and it looks > like Michael is busy so I'll have to go figure this out. Alistair's done the last couple of riscv pullrequests, so it might be simpler if he keeps doing that, but I'll let you sort that out between yourselves. thanks -- PMM
Hi All, On Thu, Oct 11, 2018 at 7:22 AM Palmer Dabbelt <palmer@sifive.com> wrote: > On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.maydell@linaro.org wrote: > > On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: > >> we should really > >> get the ball rolling on our big patch backlog. > > > > Yes, please do. Softfreeze is not all that far away and I > > would strongly prefer not to get an enormous sized pull > > request at the last minute. The ideal pattern is that > > code changes come in at a steady rate across the whole > > of the 'open' part of the development cycle. > > Ya, sorry, we've been a bit out of it. If I understand correctly, the > soft > freeze is the 30th? If so it's really time to get started, and it looks > like > Michael is busy so I'll have to go figure this out. > Yes. I should think twice about the Signed-off-by: on my commits. I need to run a regression on this out-of-order subset. I currently only run tests on the top of the riscv-qemu tree in-order, and when I rebase against master. If the commits need any significant effort to rebase because they are taken in some random order then the testing will be invalidated. i.e. I haven't checked the dependencies for these commits. I am happy to review whoever posts the contents of the tree. I can test apply the PRs against the riscv-qemu tree and if they give us lumps, we'll reject, including my own changes (if rebased). Alastair, I suggest you confer with Debian and Fedora folk. Don't break the Linux distros... I'm petrified that we might break Debian. Palmer, I disagree with idea, I would like to maintain the soft-fork until we have the CI running our regression test suite (currently manual) Peter, I have to pull in your remote wholesale. I don't cherry-pick from your tree. I think this is truly dumb. This might serve the needs of some folk running Linux but we have emulation fidelity fixes for the RISC-V community as a whole. Alastair is the only person not submitting his patches via the (sub)maintainer tree. BTW Who is the RISC-V port maintainer? Puzzled. Here is the pull queue. But I'm not ready to make a PR until we have the CI running the regression. I certainly don't want rebases of random commits to the riscv-qemu tree coming in when we pull. - https://github.com/riscv/riscv-qemu/tree/qemu-for-upstream That said, they have sign-off. There are plenty of other "RISC-V" maintainers. Do what you think is wise. Most important thing here is the Debian builders and other RISC-V virtual machines in production. Having the Debian folk or some other helpful tester running the entire tree. Pulling it in one go means we don't have a bisection problem interspersed with a whole lot of other random patches. You may not have all of the interrupt related changes that require extensive parallel burn-in tests (GCC bootstrap). i.e. we do significantly more than "make check" when we pull changes into our tree. Thanks and Regards, Michael.
On Thu, 11 Oct 2018 02:34:16 PDT (-0700), peter.maydell@linaro.org wrote: > On 10 October 2018 at 19:22, Palmer Dabbelt <palmer@sifive.com> wrote: >> On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.maydell@linaro.org wrote: >>> >>> On 10 October 2018 at 18:49, Palmer Dabbelt <palmer@sifive.com> wrote: >>>> >>>> we should really >>>> get the ball rolling on our big patch backlog. >>> >>> >>> Yes, please do. Softfreeze is not all that far away and I >>> would strongly prefer not to get an enormous sized pull >>> request at the last minute. The ideal pattern is that >>> code changes come in at a steady rate across the whole >>> of the 'open' part of the development cycle. >> >> >> Ya, sorry, we've been a bit out of it. If I understand correctly, the soft >> freeze is the 30th? If so it's really time to get started, and it looks >> like Michael is busy so I'll have to go figure this out. > > Alistair's done the last couple of riscv pullrequests, so it might > be simpler if he keeps doing that, but I'll let you sort that out > between yourselves. Ah, great. I'm always happy to have other people do things, I just feel kind of bad: I'm a maintainer and I'm putting the burden on someone else to submit a PR. If Alistair is happy submitting PRs than I'm happy to have him do it :).
On 11 October 2018 at 21:52, Michael Clark <mjc@sifive.com> wrote: > Peter, I have to pull in your remote wholesale. I don't cherry-pick from > your tree. I think this is truly dumb. This might serve the needs of some > folk running Linux but we have emulation fidelity fixes for the RISC-V > community as a whole. Alastair is the only person not submitting his patches > via the (sub)maintainer tree. BTW Who is the RISC-V port maintainer? > Puzzled. I don't particularly mind who among you RISC-V folk does the QEMU submaintainer work. But I would like to see somebody doing it, and sitting on all your patches indefinitely in an out-of-tree fork is not doing that job. There is no obligation to work with upstream on a RISC-V QEMU, of course. But your last pull request was back in May, so it's not surprising if other people offer to step into that gap. If you have emulation fidelity fixes, then the best approach is to work on getting them upstream. If you have downstream consumers for whom you want to maintain a validated definitely-works tree, that's great. How you manage that downstream tree (when you rebase it, what you put in it, whether you make it have formal "releases", etc) is up to you. I would suggest that trying to make it be the same thing as your development tree for pushing work upstream is not likely to serve either purpose well, though. The expected patch flow for QEMU is: * original patch author posts patch to qemu-devel (this applies also if the author happens to be the submaintainer) * patch gets reviewed on this mailing list, by you or anybody else * patches relevant to risc-v get collected up by the submaintainer * submaintainer submits those patches via pull request (with a frequency usually about every two weeks, more often if volume of patches merits it) > Here is the pull queue. But I'm not ready to make a PR until we have the CI > running the regression. This phrasing suggests you might be thinking about making a large batch pull request all at once close to the freeze deadline. That would be a bad idea -- it did not work well last release either. Patches are best dribbled into upstream at a steady pace as they are written. (Note also that pull requests should not contain patches which have not already been posted to qemu-devel and reviewed here.) thanks -- PMM
On Fri, 12 Oct 2018 02:34:12 PDT (-0700), peter.maydell@linaro.org wrote: > On 11 October 2018 at 21:52, Michael Clark <mjc@sifive.com> wrote: >> Peter, I have to pull in your remote wholesale. I don't cherry-pick from >> your tree. I think this is truly dumb. This might serve the needs of some >> folk running Linux but we have emulation fidelity fixes for the RISC-V >> community as a whole. Alastair is the only person not submitting his patches >> via the (sub)maintainer tree. BTW Who is the RISC-V port maintainer? >> Puzzled. > > I don't particularly mind who among you RISC-V folk does the QEMU > submaintainer work. But I would like to see somebody doing it, > and sitting on all your patches indefinitely in an out-of-tree > fork is not doing that job. There is no obligation to work > with upstream on a RISC-V QEMU, of course. But your last > pull request was back in May, so it's not surprising if > other people offer to step into that gap. > > If you have emulation fidelity fixes, then the best approach > is to work on getting them upstream. I agree. I think the best bet here is to just start picking through the patches and submitting those that we have high confidence in -- there's a handful of known bugs that have been fixed in Michael's tree. > If you have downstream consumers for whom you want to maintain > a validated definitely-works tree, that's great. How you > manage that downstream tree (when you rebase it, what you > put in it, whether you make it have formal "releases", etc) > is up to you. I would suggest that trying to make it be the > same thing as your development tree for pushing work upstream > is not likely to serve either purpose well, though. > > The expected patch flow for QEMU is: > * original patch author posts patch to qemu-devel > (this applies also if the author happens to be the > submaintainer) > * patch gets reviewed on this mailing list, by you or > anybody else > * patches relevant to risc-v get collected up by the > submaintainer > * submaintainer submits those patches via pull request > (with a frequency usually about every two weeks, more > often if volume of patches merits it) This makes sense. It's almost exactly the Linux flow, which I'm used to and I have down to a fairly mechanical process. I think the real issue here is that we don't have anyone who has officially committed to doing this, so I'm just going to pull the trigger and say I'm doing so. My Linux PR flow is to tag a PR on Mondays, send it out to the list for comments, and then if it passes muster to submit an official PR on Wednesdays. It's been working smoothly (we've yet to have to kill a PR), so I think I'll do the same thing for QEMU except I'll do Tuesday/Thursday. I talked to Michael on the phone late last week and he seemed OK with this. >> Here is the pull queue. But I'm not ready to make a PR until we have the CI >> running the regression. > > This phrasing suggests you might be thinking about making a > large batch pull request all at once close to the > freeze deadline. That would be a bad idea -- it did not > work well last release either. Patches are best dribbled > into upstream at a steady pace as they are written. > (Note also that pull requests should not contain patches > which have not already been posted to qemu-devel and > reviewed here.) > > thanks > -- PMM
On 15 October 2018 at 21:28, Palmer Dabbelt <palmer@sifive.com> wrote: > On Fri, 12 Oct 2018 02:34:12 PDT (-0700), peter.maydell@linaro.org wrote: >> The expected patch flow for QEMU is: >> * original patch author posts patch to qemu-devel >> (this applies also if the author happens to be the >> submaintainer) >> * patch gets reviewed on this mailing list, by you or >> anybody else >> * patches relevant to risc-v get collected up by the >> submaintainer >> * submaintainer submits those patches via pull request >> (with a frequency usually about every two weeks, more >> often if volume of patches merits it) > > > This makes sense. It's almost exactly the Linux flow, which I'm used to and > I have down to a fairly mechanical process. I think the real issue here is > that we don't have anyone who has officially committed to doing this, so I'm > just going to pull the trigger and say I'm doing so. Thanks for picking this up. > My Linux PR flow is to tag a PR on Mondays, send it out to the list for > comments, and then if it passes muster to submit an official PR on > Wednesdays. It's been working smoothly (we've yet to have to kill a PR), so > I think I'll do the same thing for QEMU except I'll do Tuesday/Thursday. For QEMU we do patches first, pull requests for reviewed stuff. If you send a pull request out to the list the assumption is that it's a request to apply it to master immediately. thanks -- PMM
On Tue, 16 Oct 2018 01:05:11 PDT (-0700), peter.maydell@linaro.org wrote: > On 15 October 2018 at 21:28, Palmer Dabbelt <palmer@sifive.com> wrote: >> On Fri, 12 Oct 2018 02:34:12 PDT (-0700), peter.maydell@linaro.org wrote: >>> The expected patch flow for QEMU is: >>> * original patch author posts patch to qemu-devel >>> (this applies also if the author happens to be the >>> submaintainer) >>> * patch gets reviewed on this mailing list, by you or >>> anybody else >>> * patches relevant to risc-v get collected up by the >>> submaintainer >>> * submaintainer submits those patches via pull request >>> (with a frequency usually about every two weeks, more >>> often if volume of patches merits it) >> >> >> This makes sense. It's almost exactly the Linux flow, which I'm used to and >> I have down to a fairly mechanical process. I think the real issue here is >> that we don't have anyone who has officially committed to doing this, so I'm >> just going to pull the trigger and say I'm doing so. > > Thanks for picking this up. > >> My Linux PR flow is to tag a PR on Mondays, send it out to the list for >> comments, and then if it passes muster to submit an official PR on >> Wednesdays. It's been working smoothly (we've yet to have to kill a PR), so >> I think I'll do the same thing for QEMU except I'll do Tuesday/Thursday. > > For QEMU we do patches first, pull requests for reviewed stuff. > If you send a pull request out to the list the assumption is > that it's a request to apply it to master immediately. Yep, that's the same as Linux. I just send the PR to the RISC-V mailing lists marked as an RFC so it doesn't get confused. If you don't want me to do this in QEMU land then it's fine.
These are some patches that I have cherry picked from Michael's RISC-V tree that are ready to be applied. Unless anyone has any comments against these I'll send a PR later this week. Michael Clark (5): RISC-V: Allow setting and clearing multiple irqs RISC-V: Move non-ops from op_helper to cpu_helper RISC-V: Update CSR and interrupt definitions RISC-V: Add missing free for plic_hart_config RISC-V: Don't add NULL bootargs to device-tree hw/riscv/sifive_clint.c | 8 +- hw/riscv/sifive_plic.c | 4 +- hw/riscv/sifive_u.c | 4 +- hw/riscv/spike.c | 6 +- hw/riscv/virt.c | 6 +- target/riscv/Makefile.objs | 2 +- target/riscv/cpu.c | 6 +- target/riscv/cpu.h | 22 +- target/riscv/cpu_bits.h | 683 +++++++++++++----------- target/riscv/{helper.c => cpu_helper.c} | 35 +- target/riscv/op_helper.c | 34 +- 11 files changed, 438 insertions(+), 372 deletions(-) rename target/riscv/{helper.c => cpu_helper.c} (95%)