mbox series

[PULL] First RISC-V Patch Set for the 3.1 Soft Freeze

Message ID 20181017215422.3973-1-palmer@sifive.com (mailing list archive)
State New, archived
Headers show
Series [PULL] First RISC-V Patch Set for the 3.1 Soft Freeze | expand

Pull-request

git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0

Message

Palmer Dabbelt Oct. 17, 2018, 9:54 p.m. UTC
The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 17:42:56 +0100)

are available in the Git repository at:

  git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0

for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:

  RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 -0700)

----------------------------------------------------------------
First RISC-V Patch Set for the 3.1 Soft Freeze

This pull request contains a handful of patches that have been floating
around various trees for a while but haven't made it upstream.  These
patches all appear quite safe.  They're all somewhat independent from
each other:

* One refactors our IRQ management function to allow multiple interrupts
  to be raised an once.  This patch has no functional difference.
* Cleaning up the op_helper/cpu_helper split.  This patch has no
  functional difference.
* Updates to various constants to keep them in sync with the latest ISA
  specification and to remove some non-standard bits that snuck in.
* A fix for a memory leak in the PLIC driver.
* A fix to our device tree handling to avoid provinging a NULL string.

I've given this my standard test: building the port, booting a Fedora
root filesytem on the latest Linux tag, and then shutting down that
image.  Essentially I'm just following the QEMU RISC-V wiki page's
instructions.  Everything looks fine here.

We have a lot more outstanding patches so I'll definately be submitting
another PR for the soft freeze.

----------------------------------------------------------------
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%)

Comments

Eric Blake Oct. 17, 2018, 11:32 p.m. UTC | #1
On 10/17/18 4:54 PM, Palmer Dabbelt wrote:
> The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f:
> 
>    Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 17:42:56 +0100)
> 
> are available in the Git repository at:
> 
>    git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0
> 
> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:
> 
>    RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 -0700)
> 
> ----------------------------------------------------------------
> First RISC-V Patch Set for the 3.1 Soft Freeze
> 

> ----------------------------------------------------------------
> 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
> 

Isn't this just a subset of Alistair's pull request?
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html

which included:
> ----------------------------------------------------------------
> Alistair Francis (5):
>       hw/riscv/virt: Increase the number of interrupts
>       hw/riscv/virt: Connect the gpex PCIe
>       riscv: Enable VGA and PCIE_VGA
>       hw/riscv/sifive_u: Connect the Xilinx PCIe
>       hw/riscv/virt: Connect a VirtIO net PCIe device
> 
> 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
Palmer Dabbelt Oct. 18, 2018, 12:01 a.m. UTC | #2
On Wed, 17 Oct 2018 16:32:10 PDT (-0700), eblake@redhat.com wrote:
> On 10/17/18 4:54 PM, Palmer Dabbelt wrote:
>> The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f:
>>
>>    Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 17:42:56 +0100)
>>
>> are available in the Git repository at:
>>
>>    git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0
>>
>> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:
>>
>>    RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 -0700)
>>
>> ----------------------------------------------------------------
>> First RISC-V Patch Set for the 3.1 Soft Freeze
>>
>
>> ----------------------------------------------------------------
>> 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
>>
>
> Isn't this just a subset of Alistair's pull request?
> https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html

Yes, but there's still on-going discussion about the PCIe patches so they're 
not really fully reviewed.  I think part of the trouble here is that there 
wasn't someone submitting regular QEMU pull requests so there was always a rush 
to get things in.  I've volunteered to wrangle the branches and submit weekly 
pull requests (just like I do for Linux), so now there won't be any more big 
cliffs.

We've got a lot of patches to filter through because things have been backed up 
for a bit, so I thought it'd be best to just go with something simple for this 
first week.  Assuming everything gets sorted out for the PCIe patches they'll 
just go up next week -- I'm super excited for them as well :)

> which included:
>> ----------------------------------------------------------------
>> Alistair Francis (5):
>>       hw/riscv/virt: Increase the number of interrupts
>>       hw/riscv/virt: Connect the gpex PCIe
>>       riscv: Enable VGA and PCIE_VGA
>>       hw/riscv/sifive_u: Connect the Xilinx PCIe
>>       hw/riscv/virt: Connect a VirtIO net PCIe device
>>
>> 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
Michael Clark Oct. 18, 2018, 12:54 p.m. UTC | #3
Any patches intended for the RISC-V port should go through the maintainer
tree. I have been pretty clear that I would like to run regression tests. I
do not wish to pull surprises in via master. I also do not agree with this
random patch approach. It's all well and good for inactive maintainers to
pop up now, but we were not getting our patches reviewed. The riscv-qemu
tree is actively managed and we rebase and test at release time. I don't
like the idea of busted stuff getting into the tree with patch churn
correcting it. In any case we disagree regards process. Please don't break
any of the branches in the riscv-qemu repository. I have scripts to tag our
stable branches there (we got positive feedback from Karsten on the
"series"). You are adding risk to the process. Fine. You are in charge.
Don't break stuff.

On Thu, Oct 18, 2018 at 1:01 PM Palmer Dabbelt <palmer@sifive.com> wrote:

> On Wed, 17 Oct 2018 16:32:10 PDT (-0700), eblake@redhat.com wrote:
> > On 10/17/18 4:54 PM, Palmer Dabbelt wrote:
> >> The following changes since commit
> 09558375a634e17cea6cfbfec883ac2376d2dc7f:
> >>
> >>    Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16
> 17:42:56 +0100)
> >>
> >> are available in the Git repository at:
> >>
> >>    git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0
> >>
> >> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:
> >>
> >>    RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30
> -0700)
> >>
> >> ----------------------------------------------------------------
> >> First RISC-V Patch Set for the 3.1 Soft Freeze
> >>
> >
> >> ----------------------------------------------------------------
> >> 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
> >>
> >
> > Isn't this just a subset of Alistair's pull request?
> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html
>
> Yes, but there's still on-going discussion about the PCIe patches so
> they're
> not really fully reviewed.  I think part of the trouble here is that there
> wasn't someone submitting regular QEMU pull requests so there was always a
> rush
> to get things in.  I've volunteered to wrangle the branches and submit
> weekly
> pull requests (just like I do for Linux), so now there won't be any more
> big
> cliffs.
>
> We've got a lot of patches to filter through because things have been
> backed up
> for a bit, so I thought it'd be best to just go with something simple for
> this
> first week.  Assuming everything gets sorted out for the PCIe patches
> they'll
> just go up next week -- I'm super excited for them as well :)
>
> > which included:
> >> ----------------------------------------------------------------
> >> Alistair Francis (5):
> >>       hw/riscv/virt: Increase the number of interrupts
> >>       hw/riscv/virt: Connect the gpex PCIe
> >>       riscv: Enable VGA and PCIE_VGA
> >>       hw/riscv/sifive_u: Connect the Xilinx PCIe
> >>       hw/riscv/virt: Connect a VirtIO net PCIe device
> >>
> >> 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
>
Palmer Dabbelt Oct. 18, 2018, 6:26 p.m. UTC | #4
On Thu, 18 Oct 2018 05:54:01 PDT (-0700), Michael Clark wrote:
> Any patches intended for the RISC-V port should go through the maintainer
> tree. I have been pretty clear that I would like to run regression tests. I
> do not wish to pull surprises in via master. I also do not agree with this
> random patch approach. It's all well and good for inactive maintainers to
> pop up now, but we were not getting our patches reviewed. The riscv-qemu
> tree is actively managed and we rebase and test at release time. I don't
> like the idea of busted stuff getting into the tree with patch churn
> correcting it. In any case we disagree regards process. Please don't break
> any of the branches in the riscv-qemu repository. I have scripts to tag our
> stable branches there (we got positive feedback from Karsten on the
> "series"). You are adding risk to the process. Fine. You are in charge.
> Don't break stuff.

Sorry Michael, I thought we talked about this last week in on the call and 
decided that you were happy to let someone else take over the process of 
getting the current RISC-V patch queue upstream.  While I agree there's a risk 
to submitting patches, right now we're in the position where there are known 
bugs in the upstream QEMU port.  

The real intent here is to provide a process by which we can get the RISC-V 
QEMU port flowing smoothly.  You haven't submitted a PR since May, and as a 
result it's very hard for a community to develop around the RISC-V port -- 
distros have to go track down out-of-tree patches, releases have known bugs, 
developers don't know where to start, etc.  I know it's easy to get overwhelmed 
(that happened to me with both binutils and Linux), and I thought we agreed 
that you'd be happy to have someone else help out with shepherding patches from 
the RISC-V patch queue into master.  I know it's hard to get the ball rolling, 
but the longer we wait the harder it'll be.

I purposefully created a new "for-master" branch on the RISC-V QEMU github repo 
to avoid touching any of the branches you've been maintaining, and my intent 
was for all these patches to have come off of "for-upstream" (which IIUC is the 
RISC-V patch queue).  If I screwed anything up then let me know.

Maybe we can talk about what we're going to do here this afternoon?  I 
certainly don't want to step on your toes here, but I really would like to get 
patches to start flowing upstream.

Sorry for the confusion, everyone!

> On Thu, Oct 18, 2018 at 1:01 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
>> On Wed, 17 Oct 2018 16:32:10 PDT (-0700), eblake@redhat.com wrote:
>> > On 10/17/18 4:54 PM, Palmer Dabbelt wrote:
>> >> The following changes since commit
>> 09558375a634e17cea6cfbfec883ac2376d2dc7f:
>> >>
>> >>    Merge remote-tracking branch
>> 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16
>> 17:42:56 +0100)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >>    git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0
>> >>
>> >> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:
>> >>
>> >>    RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30
>> -0700)
>> >>
>> >> ----------------------------------------------------------------
>> >> First RISC-V Patch Set for the 3.1 Soft Freeze
>> >>
>> >
>> >> ----------------------------------------------------------------
>> >> 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
>> >>
>> >
>> > Isn't this just a subset of Alistair's pull request?
>> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html
>>
>> Yes, but there's still on-going discussion about the PCIe patches so
>> they're
>> not really fully reviewed.  I think part of the trouble here is that there
>> wasn't someone submitting regular QEMU pull requests so there was always a
>> rush
>> to get things in.  I've volunteered to wrangle the branches and submit
>> weekly
>> pull requests (just like I do for Linux), so now there won't be any more
>> big
>> cliffs.
>>
>> We've got a lot of patches to filter through because things have been
>> backed up
>> for a bit, so I thought it'd be best to just go with something simple for
>> this
>> first week.  Assuming everything gets sorted out for the PCIe patches
>> they'll
>> just go up next week -- I'm super excited for them as well :)
>>
>> > which included:
>> >> ----------------------------------------------------------------
>> >> Alistair Francis (5):
>> >>       hw/riscv/virt: Increase the number of interrupts
>> >>       hw/riscv/virt: Connect the gpex PCIe
>> >>       riscv: Enable VGA and PCIE_VGA
>> >>       hw/riscv/sifive_u: Connect the Xilinx PCIe
>> >>       hw/riscv/virt: Connect a VirtIO net PCIe device
>> >>
>> >> 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
>>
Peter Maydell Oct. 25, 2018, 6:34 p.m. UTC | #5
On 17 October 2018 at 22:54, Palmer Dabbelt <palmer@sifive.com> wrote:
> The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f:
>
>   Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 17:42:56 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0
>
> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78:
>
>   RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 -0700)
>
> ----------------------------------------------------------------
> First RISC-V Patch Set for the 3.1 Soft Freeze
>
> This pull request contains a handful of patches that have been floating
> around various trees for a while but haven't made it upstream.  These
> patches all appear quite safe.  They're all somewhat independent from
> each other:
>
> * One refactors our IRQ management function to allow multiple interrupts
>   to be raised an once.  This patch has no functional difference.
> * Cleaning up the op_helper/cpu_helper split.  This patch has no
>   functional difference.
> * Updates to various constants to keep them in sync with the latest ISA
>   specification and to remove some non-standard bits that snuck in.
> * A fix for a memory leak in the PLIC driver.
> * A fix to our device tree handling to avoid provinging a NULL string.
>
> I've given this my standard test: building the port, booting a Fedora
> root filesytem on the latest Linux tag, and then shutting down that
> image.  Essentially I'm just following the QEMU RISC-V wiki page's
> instructions.  Everything looks fine here.
>
> We have a lot more outstanding patches so I'll definately be submitting
> another PR for the soft freeze.
>
> ----------------------------------------------------------------

Applied to master, thanks (following some off-list discussions
of what we are doing wrt who is submitting riscv upstream pullreqs).

-- PMM