mbox series

[PR,RFC] RISC-V Patches for 3.2, Part 3

Message ID 20190130173601.3268-1-palmer@sifive.com
State New
Headers show
Series [PR,RFC] RISC-V Patches for 3.2, Part 3 | expand

Pull-request

git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-master-3.2-part3

Message

Palmer Dabbelt Jan. 30, 2019, 5:35 p.m. UTC
The following changes since commit 5385a5988c8a55bebdc878c05b96648579b5d6e0:

  hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config struct (2019-01-21 17:20:36 +0000)

are available in the Git repository at:

  git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-master-3.2-part3

for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:

  target/riscv: fix counter-enable checks in ctr() (2019-01-29 11:33:38 -0800)

----------------------------------------------------------------
RISC-V Patches for 3.2, Part 3

This patch set contains a handful of patches I've collected over the
last few weeks.  There's nothing really fundamental, but I thought it
would be good to send these out now as there are some other patch sets
on the mailing list that are getting ready to go.

As far as the actual patches, there's:

* A set that cleans up our FS dirty-mode handling.
* Support for writing MISA.
* The removal of Michael as a maintainer.
* A fix to {m,s}counteren handling.

This passes my standard "boots Fedora" test case.

----------------------------------------------------------------
Alistair Francis (1):
      RISC-V: Add priv_ver to DisasContext

Michael Clark (5):
      RISC-V: Implement mstatus.TSR/TW/TVM
      RISC-V: Use riscv prefix consistently on cpu helpers
      RISC-V: Add misa to DisasContext
      RISC-V: Add misa.MAFD checks to translate
      RISC-V: Add misa runtime write support

Palmer Dabbelt (1):
      MAINTAINERS: Remove Michael Clark as a RISC-V Maintainer

Richard Henderson (2):
      RISC-V: Split out mstatus_fs from tb_flags
      RISC-V: Mark mstatus.fs dirty

Xi Wang (1):
      target/riscv: fix counter-enable checks in ctr()

 MAINTAINERS               |   1 -
 linux-user/riscv/signal.c |   4 +-
 target/riscv/cpu.c        |   2 +-
 target/riscv/cpu.h        |  31 ++---
 target/riscv/cpu_bits.h   |  11 ++
 target/riscv/cpu_helper.c |  10 +-
 target/riscv/csr.c        | 103 ++++++++++++----
 target/riscv/fpu_helper.c |   6 +-
 target/riscv/op_helper.c  |  47 +++++---
 target/riscv/translate.c  | 290 +++++++++++++++++++++++++++++++++++++++-------
 10 files changed, 396 insertions(+), 109 deletions(-)

Comments

Eric Blake Jan. 30, 2019, 5:45 p.m. UTC | #1
On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
> The following changes since commit 5385a5988c8a55bebdc878c05b96648579b5d6e0:
> 
>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config struct (2019-01-21 17:20:36 +0000)
> 
> are available in the Git repository at:
> 
>   git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-master-3.2-part3
> 
> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
> 
>   target/riscv: fix counter-enable checks in ctr() (2019-01-29 11:33:38 -0800)
> 
> ----------------------------------------------------------------
> RISC-V Patches for 3.2, Part 3

There is no 3.2 release; the next release is named 4.0.  However, if you
don't want to bother with sending a v2 pull request just to fix the
merge commit message, that's okay with me.
Palmer Dabbelt Jan. 30, 2019, 7:01 p.m. UTC | #2
On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>> The following changes since commit 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>>
>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config struct (2019-01-21 17:20:36 +0000)
>>
>> are available in the Git repository at:
>>
>>   git://github.com/palmer-dabbelt/qemu.git tags/riscv-for-master-3.2-part3
>>
>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>>
>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29 11:33:38 -0800)
>>
>> ----------------------------------------------------------------
>> RISC-V Patches for 3.2, Part 3
>
> There is no 3.2 release; the next release is named 4.0.  However, if you
> don't want to bother with sending a v2 pull request just to fix the
> merge commit message, that's okay with me.

Ah, sorry.  I think I'm just going to leave it as is, I'll get it right next 
time.
Thomas Huth Jan. 31, 2019, 6:39 a.m. UTC | #3
On 2019-01-30 20:01, Palmer Dabbelt wrote:
> On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
>> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>>> The following changes since commit
>>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>>>
>>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config
>>> struct (2019-01-21 17:20:36 +0000)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://github.com/palmer-dabbelt/qemu.git
>>> tags/riscv-for-master-3.2-part3
>>>
>>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>>>
>>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
>>> 11:33:38 -0800)
>>>
>>> ----------------------------------------------------------------
>>> RISC-V Patches for 3.2, Part 3
>>
>> There is no 3.2 release; the next release is named 4.0.  However, if you
>> don't want to bother with sending a v2 pull request just to fix the
>> merge commit message, that's okay with me.
> 
> Ah, sorry.  I think I'm just going to leave it as is, I'll get it right
> next time.

Also note that you used "PR RFC" in the title ... so not sure whether
Peter's scripts will catch this PR as a valid one...

 Thomas
Peter Maydell Jan. 31, 2019, 9:51 a.m. UTC | #4
On Thu, 31 Jan 2019 at 06:39, Thomas Huth <thuth@redhat.com> wrote:
>
> On 2019-01-30 20:01, Palmer Dabbelt wrote:
> > On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
> >> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
> >>> The following changes since commit
> >>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
> >>>
> >>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config
> >>> struct (2019-01-21 17:20:36 +0000)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   git://github.com/palmer-dabbelt/qemu.git
> >>> tags/riscv-for-master-3.2-part3
> >>>
> >>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
> >>>
> >>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
> >>> 11:33:38 -0800)
> >>>
> >>> ----------------------------------------------------------------
> >>> RISC-V Patches for 3.2, Part 3
> >>
> >> There is no 3.2 release; the next release is named 4.0.  However, if you
> >> don't want to bother with sending a v2 pull request just to fix the
> >> merge commit message, that's okay with me.
> >
> > Ah, sorry.  I think I'm just going to leave it as is, I'll get it right
> > next time.
>
> Also note that you used "PR RFC" in the title ... so not sure whether
> Peter's scripts will catch this PR as a valid one...

My mail filter finds these RFC pullrequests, yes. I'm then
relying on my manual brain to not actually apply them.
(If it's a slow day I might do a test merge on them, but
usually my queue is full enough that I don't get to them
before the real PR appears.)

thanks
-- PMM
Palmer Dabbelt Feb. 2, 2019, 8:41 a.m. UTC | #5
On Wed, 30 Jan 2019 22:39:35 PST (-0800), thuth@redhat.com wrote:
> On 2019-01-30 20:01, Palmer Dabbelt wrote:
>> On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
>>> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>>>> The following changes since commit
>>>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>>>>
>>>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config
>>>> struct (2019-01-21 17:20:36 +0000)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   git://github.com/palmer-dabbelt/qemu.git
>>>> tags/riscv-for-master-3.2-part3
>>>>
>>>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>>>>
>>>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
>>>> 11:33:38 -0800)
>>>>
>>>> ----------------------------------------------------------------
>>>> RISC-V Patches for 3.2, Part 3
>>>
>>> There is no 3.2 release; the next release is named 4.0.  However, if you
>>> don't want to bother with sending a v2 pull request just to fix the
>>> merge commit message, that's okay with me.
>>
>> Ah, sorry.  I think I'm just going to leave it as is, I'll get it right
>> next time.
>
> Also note that you used "PR RFC" in the title ... so not sure whether
> Peter's scripts will catch this PR as a valid one...

It's actually meant not to: my blow is to send out these as a test to see if 
there's anything wrong, and then if there is to fix it up.  I'm less worried 
about the text of the pull request and more about making sure I didn't screw up 
a patch, which is the only reason I wasn't worried about picking up your 
suggested change.
Palmer Dabbelt Feb. 2, 2019, 8:41 a.m. UTC | #6
On Thu, 31 Jan 2019 01:51:52 PST (-0800), Peter Maydell wrote:
> On Thu, 31 Jan 2019 at 06:39, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 2019-01-30 20:01, Palmer Dabbelt wrote:
>> > On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
>> >> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>> >>> The following changes since commit
>> >>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>> >>>
>> >>>   hw/virtio/virtio-balloon: zero-initialize the virtio_balloon_config
>> >>> struct (2019-01-21 17:20:36 +0000)
>> >>>
>> >>> are available in the Git repository at:
>> >>>
>> >>>   git://github.com/palmer-dabbelt/qemu.git
>> >>> tags/riscv-for-master-3.2-part3
>> >>>
>> >>> for you to fetch changes up to 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>> >>>
>> >>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
>> >>> 11:33:38 -0800)
>> >>>
>> >>> ----------------------------------------------------------------
>> >>> RISC-V Patches for 3.2, Part 3
>> >>
>> >> There is no 3.2 release; the next release is named 4.0.  However, if you
>> >> don't want to bother with sending a v2 pull request just to fix the
>> >> merge commit message, that's okay with me.
>> >
>> > Ah, sorry.  I think I'm just going to leave it as is, I'll get it right
>> > next time.
>>
>> Also note that you used "PR RFC" in the title ... so not sure whether
>> Peter's scripts will catch this PR as a valid one...
>
> My mail filter finds these RFC pullrequests, yes. I'm then
> relying on my manual brain to not actually apply them.
> (If it's a slow day I might do a test merge on them, but
> usually my queue is full enough that I don't get to them
> before the real PR appears.)

Ah, OK -- do you want me to do something else?
Thomas Huth Feb. 4, 2019, 9:05 a.m. UTC | #7
On 2019-02-02 09:41, Palmer Dabbelt wrote:
> On Thu, 31 Jan 2019 01:51:52 PST (-0800), Peter Maydell wrote:
>> On Thu, 31 Jan 2019 at 06:39, Thomas Huth <thuth@redhat.com> wrote:
>>>
>>> On 2019-01-30 20:01, Palmer Dabbelt wrote:
>>> > On Wed, 30 Jan 2019 09:45:33 PST (-0800), eblake@redhat.com wrote:
>>> >> On 1/30/19 11:35 AM, Palmer Dabbelt wrote:
>>> >>> The following changes since commit
>>> >>> 5385a5988c8a55bebdc878c05b96648579b5d6e0:
>>> >>>
>>> >>>   hw/virtio/virtio-balloon: zero-initialize the
>>> virtio_balloon_config
>>> >>> struct (2019-01-21 17:20:36 +0000)
>>> >>>
>>> >>> are available in the Git repository at:
>>> >>>
>>> >>>   git://github.com/palmer-dabbelt/qemu.git
>>> >>> tags/riscv-for-master-3.2-part3
>>> >>>
>>> >>> for you to fetch changes up to
>>> 461ab9de46d085a37b0da6f096aadc4e0dda4d4c:
>>> >>>
>>> >>>   target/riscv: fix counter-enable checks in ctr() (2019-01-29
>>> >>> 11:33:38 -0800)
>>> >>>
>>> >>> ----------------------------------------------------------------
>>> >>> RISC-V Patches for 3.2, Part 3
>>> >>
>>> >> There is no 3.2 release; the next release is named 4.0.  However,
>>> if you
>>> >> don't want to bother with sending a v2 pull request just to fix the
>>> >> merge commit message, that's okay with me.
>>> >
>>> > Ah, sorry.  I think I'm just going to leave it as is, I'll get it
>>> right
>>> > next time.
>>>
>>> Also note that you used "PR RFC" in the title ... so not sure whether
>>> Peter's scripts will catch this PR as a valid one...
>>
>> My mail filter finds these RFC pullrequests, yes. I'm then
>> relying on my manual brain to not actually apply them.
>> (If it's a slow day I might do a test merge on them, but
>> usually my queue is full enough that I don't get to them
>> before the real PR appears.)
> 
> Ah, OK -- do you want me to do something else?

At least I got a little bit confused by "PR RFC" ... I think some other
maintainers rather send out patch series marked with "PATCH" first, and
add some non-pull-request cover letter with a text like "I'm intending
to send a pull request for this soon, please review one more time...".
Then after a day or two, once Patchew checked the series and nobody else
complained, they send a real "PULL" request.
(at least that's how I saw the handling on the mailing list in the past,
not sure whether Peter has a different point of view here, though).

 Thomas
Peter Maydell Feb. 4, 2019, 9:59 a.m. UTC | #8
On Mon, 4 Feb 2019 at 09:05, Thomas Huth <thuth@redhat.com> wrote:
> On 2019-02-02 09:41, Palmer Dabbelt wrote:
> >> My mail filter finds these RFC pullrequests, yes. I'm then
> >> relying on my manual brain to not actually apply them.
> >> (If it's a slow day I might do a test merge on them, but
> >> usually my queue is full enough that I don't get to them
> >> before the real PR appears.)
> >
> > Ah, OK -- do you want me to do something else?
>
> At least I got a little bit confused by "PR RFC" ... I think some other
> maintainers rather send out patch series marked with "PATCH" first, and
> add some non-pull-request cover letter with a text like "I'm intending
> to send a pull request for this soon, please review one more time...".
> Then after a day or two, once Patchew checked the series and nobody else
> complained, they send a real "PULL" request.

Yeah, generally nobody else sends RFC pull requests, they just
send the actual pulls. I don't object if Palmer finds them
useful, though.

For what it's worth, my filter for finding pull requests is emails
containing "for you to fetch changes up to" but not either of
"not for master" or "PULL SUBSYSTEM". So if you want to specifically
keep out of the filters you can add "not for master" in the cover
letter. But as I say it's not a big deal for me to sort things out
manually -- the filter has the odd false positive anyway.

thanks
-- PMM
Palmer Dabbelt Feb. 6, 2019, 4:47 p.m. UTC | #9
On Mon, 04 Feb 2019 01:59:48 PST (-0800), Peter Maydell wrote:
> On Mon, 4 Feb 2019 at 09:05, Thomas Huth <thuth@redhat.com> wrote:
>> On 2019-02-02 09:41, Palmer Dabbelt wrote:
>> >> My mail filter finds these RFC pullrequests, yes. I'm then
>> >> relying on my manual brain to not actually apply them.
>> >> (If it's a slow day I might do a test merge on them, but
>> >> usually my queue is full enough that I don't get to them
>> >> before the real PR appears.)
>> >
>> > Ah, OK -- do you want me to do something else?
>>
>> At least I got a little bit confused by "PR RFC" ... I think some other
>> maintainers rather send out patch series marked with "PATCH" first, and
>> add some non-pull-request cover letter with a text like "I'm intending
>> to send a pull request for this soon, please review one more time...".
>> Then after a day or two, once Patchew checked the series and nobody else
>> complained, they send a real "PULL" request.
>
> Yeah, generally nobody else sends RFC pull requests, they just
> send the actual pulls. I don't object if Palmer finds them
> useful, though.

If nobody else does it then I might stop -- they were more useful for me when I 
was new at this, as I was pretty worried about making mistakes and wanted to 
make sure I didn't screw anything up.  Things have gone pretty smoothly, so it 
might just have been paranoia.

Unless anyone likes these I think I'll stop sending them.

>
> For what it's worth, my filter for finding pull requests is emails
> containing "for you to fetch changes up to" but not either of
> "not for master" or "PULL SUBSYSTEM". So if you want to specifically
> keep out of the filters you can add "not for master" in the cover
> letter. But as I say it's not a big deal for me to sort things out
> manually -- the filter has the odd false positive anyway.

OK, makes sense.