Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

On Wed, Mar 7, 2018 at 12:09 AM, Peter Maydell 
wrote:

> On 6 March 2018 at 01:30, Michael Clark  wrote:
> > I've squashed the trivial spike rename fix and rebased against master as
> of
> > commit f2bb2d14c2958f3f5aef456bd2cdb1ff99f4a562 Merge remote-tracking
> branch
> > 'remotes/stefanha/tags/block-pull-request' into staging. See here:
> >
> > - https://github.com/riscv/riscv-qemu/releases/tag/riscv-
> qemu-upstream-v8.1
>
> OK. In the interests of getting the RISC-V port into upstream before
> the upcoming softfreeze deadline (which is next Tuesday)[*], please
> can you:
>  * make sure you have a signed tag and send it as a proper pull request
> email
>  * send your other queued changes to the mailing list as a patch series
>so they can be reviewed
>  * work with Igor to identify the changes you need to make for the
>CPU type registering issue he's raised, and then send a patch for that
>

I believe I have done all 3 now.

I would also like to forward port the change to implement IEEE-754
minimumNumber/maximumNumber to fix our fmin/fmax regression. I dropped the
patch due to conflicting changes in softfloat. With that change we are
passing all of the current riscv-tests for the Base ISA, with the exception
of returning NaN for SP floating point ops on DP register values. RISC-V
has a NaN boxing scheme to identify the type of floating point values in
memory, unlike SSE registers where the upper bits are undefined, RISC-V
requires the FP register file to "box" SP inside of a wider -NaN. i.e. the
upper 32 bits are all 1s. This was done to support type identification for
FPUs that work with a recoded internal format. The mechanism is described
in "9.2 NaN Boxing of Narrower Values" in the draft RISC-V ISA Manual. The
essence is to solve the context switch issue where FSD (Store Double) is
used to save values from the register file. By defining the upper bits as
Boxed within a NaN, the spec solves a binary compatibility issue between
different RISC-V implementations. For QEMU RISC-V, we'll need to add checks
on all SP floating point operations to check that the value is canonically
boxed, otherwise return a NaN (in the corner case where incorrect code
performs a SP operation on an FPU register containing a DP value). Once we
fix this issue, and minimumNumber/maximumNumber, QEMU RISC-V will be
passing 100% of the current Base ISA tests.

[*] For us, 'softfreeze' means that any new features must be in a pull
> request on the mailing list by that date; after that only bugfixes.
> Hardfreeze and the first rc candidate build is a week after that.
> See https://wiki.qemu.org/Planning/2.12 for other dates.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

On Tue, Mar 6, 2018 at 10:13 PM, Andrea Bolognani 
wrote:

> On Tue, 2018-03-06 at 14:30 +1300, Michael Clark wrote:
> > I'm currently working on some changes locally to split the firmware from
> > the kernel image. Currently the kernel image is embedded in the firmware
> (r
> > iscv-pk/bbl).
>
> I was wondering about this just yesterday.
>
> Will this eventually lead to a situation where we can have a single
> firmware image which is shared between all guests, a la OVMF/AAVMF,
> with grub and the kernels stored on the virtual disk itself, like
> on most other architectures?
>

Possibly.

My first cut is to put the kernel-entry load address into a "chosen"
device-tree node so that the firmware knows where to jump to, versus having
the kernel as an embedded payload.

Currently the kernel image is embedded inside of the riscv-pk/bbl firmware
which is less than ideal and obviously a temporary solution.

We want to be able to build the firmware, kernel and initramfs separately.

That should make it less awkward to add RISC-V support to libvirt,
> plus I expect it to be kind of a requirement for full distribution
> support, especially when it comes to updates and such.
>

Apparently some folk have spent some time working on UEFI support for
RISC-V and I noticed that there is a UEFI model for passing FDT (versus
other platform specific tables).

The only thing I don't like about UEFI is that it uses LLP64 and PE/COFF vs
LP64/ELF

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Peter Maydell]

On 6 March 2018 at 01:30, Michael Clark  wrote:
> I've squashed the trivial spike rename fix and rebased against master as of
> commit f2bb2d14c2958f3f5aef456bd2cdb1ff99f4a562 Merge remote-tracking branch
> 'remotes/stefanha/tags/block-pull-request' into staging. See here:
>
> - https://github.com/riscv/riscv-qemu/releases/tag/riscv-qemu-upstream-v8.1

OK. In the interests of getting the RISC-V port into upstream before
the upcoming softfreeze deadline (which is next Tuesday)[*], please
can you:
 * make sure you have a signed tag and send it as a proper pull request email
 * send your other queued changes to the mailing list as a patch series
   so they can be reviewed
 * work with Igor to identify the changes you need to make for the
   CPU type registering issue he's raised, and then send a patch for that

?

[*] For us, 'softfreeze' means that any new features must be in a pull
request on the mailing list by that date; after that only bugfixes.
Hardfreeze and the first rc candidate build is a week after that.
See https://wiki.qemu.org/Planning/2.12 for other dates.

thanks
-- PMM

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Andrea Bolognani]

On Tue, 2018-03-06 at 14:30 +1300, Michael Clark wrote:
> I'm currently working on some changes locally to split the firmware from
> the kernel image. Currently the kernel image is embedded in the firmware (r
> iscv-pk/bbl).

I was wondering about this just yesterday.

Will this eventually lead to a situation where we can have a single
firmware image which is shared between all guests, a la OVMF/AAVMF,
with grub and the kernels stored on the virtual disk itself, like
on most other architectures?

That should make it less awkward to add RISC-V support to libvirt,
plus I expect it to be kind of a requirement for full distribution
support, especially when it comes to updates and such.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

On Tue, Mar 6, 2018 at 12:10 PM, Michael Clark  wrote:

>
>
> On Sun, Mar 4, 2018 at 11:52 AM, Peter Maydell 
> wrote:
>
>> On 3 March 2018 at 02:46, Michael Clark  wrote:
>> > On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell > >
>> > wrote:
>> >> Please don't send pull requests until after patches have been put
>> >> on list and been reviewed. A minor update to a pullreq is OK if
>> >> it's something like a trivial compiler fix or just dropping some
>> >> patches that had problems, but if you have this many changes that
>> >> deserves a fresh patchset to be sent to the list for review.
>> >>
>> >> (For the QEMU workflow, a pull request isn't a request for patch
>> >> review, it's a statement that patches have all had review and
>> >> are ready to go into master immediately.)
>> >
>> >
>> > My apoligies. I won't do this again.
>>
>> No worries, it's just a workflow thing (which differs a lot from
>> project to project), and we don't really have much documentation
>> on the submaintainer part of the process. (What we do have is here:
>> https://wiki.qemu.org/Contribute/SubmitAPullRequest  )
>>
>> The basic idea is that for us code review happens in the "patches
>> posted to list" phase, and then "pull request" is pretty much
>> the same as "commit to master". As the submaintainer you review,
>> test and accumulate in a branch patches from yourself and other
>> people, and then send them out in a pull request. In the ideal
>> case that goes straight into master without problems. Sometimes
>> it runs into trouble (like a compile issue on an oddball platform),
>> and then rather than going through the whole process again for
>> something as small as a messed up format string you can just fix
>> and resend the pullreq. (There are examples of this on list at
>> the moment, for instance.)
>> Bigger stuff it's usually easier to drop the relevant patches
>> from the pull, and then respin them and resend for review before
>> putting them in a later pull. The dividing line for what you
>> can get away with fixing up locally and what you can't is
>> kind of similar to what you can tweak without needing to drop
>> a reviewed-by: tag from a changed patch and get it re-reviewed.
>> When you get familiar with the process and what people do you
>> can take shortcuts sometimes (this is me posting what I'm
>> going to squash into a patch as a followup, to save reposting
>> a 20 patch series, for instance:
>> http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg00310.html).
>> For getting started as a submaintainer, it's probably easiest
>> to follow the 'by the book' process: patches go to mailing
>> list as 'PATCH', get review, changes made, patch series resent,
>> reviewed patches go into pull requests. (The idea is to ensure
>> that anything that goes into master has been on list for at
>> least a few days so people who want to review can do so.)
>>
>> > I have some very very minor cleanups that do not affect logic, but
>> perhaps
>> > we could address this after getting approval to make a pull request for
>> v8.
>> >
>> > My qemu-devel branch holds changes against the latest rebase:
>> >
>> > - https://github.com/michaeljclark/riscv-qemu/tree/qemu-devel
>> >
>> > Someone raised timebase frequency on the RISC-V sw-dev and after
>> looking at
>> > the code I noticed we had a hard-coded value for a few of the constants
>> we
>> > put in device tree, and i spotted a missed rename. I'm going to have to
>> > learn about the qemu-devel process for trivial fixes...
>>
>> I would probably squash in the missed rename into the relevant
>> patch, at any rate. The rest can probably go through the post
>> patch/get review/sent pull request cycle after this first lot
>> have been applied.
>>
>
> It seems I need to rebase against master based on recent changes, so I'll
> make a v9 tag, include the minimal missed rename but exluding my queued
> changes. The changes in v8 are the minimum required to allow us to keep the
> SiFive machines as we renamed them and added the SiFive cpu models. The
> essence of the v8 patch series.
>
> The trivial fixes to v8 ended up becoming non-trivial and now includes a
> lot of specification conformance issues (essentially specification related
> bug fixes) and a fix for a potential buffer overflow wrt. device-tree, that
> doesn't appear to trigger in practice. I was also able to shed some dead
> code (machines aren't objects, so empty object boilerplate was removed):
>
> - https://github.com/riscv/riscv-qemu/pull/112
>
> We'll hold off merging these changes into the v8 branch, and will send
> them as a post merge cleanup and bugfix patch series, hopefully after
> getting the port merged.
>
> I'll get back to you when I have rebased against master...
>

I've squashed the trivial spike rename fix and rebased against master as of
commit f2bb2d14c2958f3f5aef456bd2cdb1ff99f4a562 Merge remote-tracking
branch 

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

On Sun, Mar 4, 2018 at 11:52 AM, Peter Maydell 
wrote:

> On 3 March 2018 at 02:46, Michael Clark  wrote:
> > On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell 
> > wrote:
> >> Please don't send pull requests until after patches have been put
> >> on list and been reviewed. A minor update to a pullreq is OK if
> >> it's something like a trivial compiler fix or just dropping some
> >> patches that had problems, but if you have this many changes that
> >> deserves a fresh patchset to be sent to the list for review.
> >>
> >> (For the QEMU workflow, a pull request isn't a request for patch
> >> review, it's a statement that patches have all had review and
> >> are ready to go into master immediately.)
> >
> >
> > My apoligies. I won't do this again.
>
> No worries, it's just a workflow thing (which differs a lot from
> project to project), and we don't really have much documentation
> on the submaintainer part of the process. (What we do have is here:
> https://wiki.qemu.org/Contribute/SubmitAPullRequest  )
>
> The basic idea is that for us code review happens in the "patches
> posted to list" phase, and then "pull request" is pretty much
> the same as "commit to master". As the submaintainer you review,
> test and accumulate in a branch patches from yourself and other
> people, and then send them out in a pull request. In the ideal
> case that goes straight into master without problems. Sometimes
> it runs into trouble (like a compile issue on an oddball platform),
> and then rather than going through the whole process again for
> something as small as a messed up format string you can just fix
> and resend the pullreq. (There are examples of this on list at
> the moment, for instance.)
> Bigger stuff it's usually easier to drop the relevant patches
> from the pull, and then respin them and resend for review before
> putting them in a later pull. The dividing line for what you
> can get away with fixing up locally and what you can't is
> kind of similar to what you can tweak without needing to drop
> a reviewed-by: tag from a changed patch and get it re-reviewed.
> When you get familiar with the process and what people do you
> can take shortcuts sometimes (this is me posting what I'm
> going to squash into a patch as a followup, to save reposting
> a 20 patch series, for instance:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg00310.html).
> For getting started as a submaintainer, it's probably easiest
> to follow the 'by the book' process: patches go to mailing
> list as 'PATCH', get review, changes made, patch series resent,
> reviewed patches go into pull requests. (The idea is to ensure
> that anything that goes into master has been on list for at
> least a few days so people who want to review can do so.)
>
> > I have some very very minor cleanups that do not affect logic, but
> perhaps
> > we could address this after getting approval to make a pull request for
> v8.
> >
> > My qemu-devel branch holds changes against the latest rebase:
> >
> > - https://github.com/michaeljclark/riscv-qemu/tree/qemu-devel
> >
> > Someone raised timebase frequency on the RISC-V sw-dev and after looking
> at
> > the code I noticed we had a hard-coded value for a few of the constants
> we
> > put in device tree, and i spotted a missed rename. I'm going to have to
> > learn about the qemu-devel process for trivial fixes...
>
> I would probably squash in the missed rename into the relevant
> patch, at any rate. The rest can probably go through the post
> patch/get review/sent pull request cycle after this first lot
> have been applied.
>

It seems I need to rebase against master based on recent changes, so I'll
make a v9 tag, include the minimal missed rename but exluding my queued
changes. The changes in v8 are the minimum required to allow us to keep the
SiFive machines as we renamed them and added the SiFive cpu models. The
essence of the v8 patch series.

The trivial fixes to v8 ended up becoming non-trivial and now includes a
lot of specification conformance issues (essentially specification related
bug fixes) and a fix for a potential buffer overflow wrt. device-tree, that
doesn't appear to trigger in practice. I was also able to shed some dead
code (machines aren't objects, so empty object boilerplate was removed):

- https://github.com/riscv/riscv-qemu/pull/112

We'll hold off merging these changes into the v8 branch, and will send them
as a post merge cleanup and bugfix patch series, hopefully after getting
the port merged.

I'll get back to you when I have rebased against master...

We have some objectives with regards to the sifive_e and sifive_u machines,
such that we may properly abstract the SOC/board and also have a
configurable SOC as we need to model configurable soft-core IP as well as
actual SOCs based on this IP. This will be in the future. The machines at
this point are relatively simple.

Thanks,
Michael.

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Peter Maydell]

On 3 March 2018 at 02:46, Michael Clark  wrote:
> On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell 
> wrote:
>> Please don't send pull requests until after patches have been put
>> on list and been reviewed. A minor update to a pullreq is OK if
>> it's something like a trivial compiler fix or just dropping some
>> patches that had problems, but if you have this many changes that
>> deserves a fresh patchset to be sent to the list for review.
>>
>> (For the QEMU workflow, a pull request isn't a request for patch
>> review, it's a statement that patches have all had review and
>> are ready to go into master immediately.)
>
>
> My apoligies. I won't do this again.

No worries, it's just a workflow thing (which differs a lot from
project to project), and we don't really have much documentation
on the submaintainer part of the process. (What we do have is here:
https://wiki.qemu.org/Contribute/SubmitAPullRequest  )

The basic idea is that for us code review happens in the "patches
posted to list" phase, and then "pull request" is pretty much
the same as "commit to master". As the submaintainer you review,
test and accumulate in a branch patches from yourself and other
people, and then send them out in a pull request. In the ideal
case that goes straight into master without problems. Sometimes
it runs into trouble (like a compile issue on an oddball platform),
and then rather than going through the whole process again for
something as small as a messed up format string you can just fix
and resend the pullreq. (There are examples of this on list at
the moment, for instance.)
Bigger stuff it's usually easier to drop the relevant patches
from the pull, and then respin them and resend for review before
putting them in a later pull. The dividing line for what you
can get away with fixing up locally and what you can't is
kind of similar to what you can tweak without needing to drop
a reviewed-by: tag from a changed patch and get it re-reviewed.
When you get familiar with the process and what people do you
can take shortcuts sometimes (this is me posting what I'm
going to squash into a patch as a followup, to save reposting
a 20 patch series, for instance:
http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg00310.html).
For getting started as a submaintainer, it's probably easiest
to follow the 'by the book' process: patches go to mailing
list as 'PATCH', get review, changes made, patch series resent,
reviewed patches go into pull requests. (The idea is to ensure
that anything that goes into master has been on list for at
least a few days so people who want to review can do so.)

> I have some very very minor cleanups that do not affect logic, but perhaps
> we could address this after getting approval to make a pull request for v8.
>
> My qemu-devel branch holds changes against the latest rebase:
>
> - https://github.com/michaeljclark/riscv-qemu/tree/qemu-devel
>
> Someone raised timebase frequency on the RISC-V sw-dev and after looking at
> the code I noticed we had a hard-coded value for a few of the constants we
> put in device tree, and i spotted a missed rename. I'm going to have to
> learn about the qemu-devel process for trivial fixes...

I would probably squash in the missed rename into the relevant
patch, at any rate. The rest can probably go through the post
patch/get review/sent pull request cycle after this first lot
have been applied.

thanks
-- PMM

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell 
wrote:

> On 2 March 2018 at 13:55, Michael Clark  wrote:
> >
> > *** Changelog ***
> >
> > v8
> >
> > - - Added linux-user/riscv/target_elf.h during rebase
> > - - Make resetvec configurable and clear mpp and mie on reset
> > - - Use SiFive E31, E51, U34 and U54 cores in SiFive machines
> > - - Define SiFive E31, E51, U34 and U54 cores
> > - - Refactor CPU core definition in preparation for vendor cores
> > - - Prevent S or U mode unless S or U extensions are present
> > - - SiFive E Series cores have no MMU
> > - - SiFive E Series cores have U mode
> > - - Make privileged ISA v1.10 implicit in CPU types
> > - - Remove DRAM_BASE and EXT_IO_BASE as they vary by machine
> > - - Correctly handle mtvec and stvec alignment with respect to RVC
> > - - Print more machine mode state in riscv_cpu_dump_state
> > - - Make riscv_isa_string use compact extension order method
> > - - Fix bug introduced in v6 RISCV_CPU_TYPE_NAME macro change
> > - - Parameterize spike v1.9.1 config string
> > - - Coalesce spike_v1.9.1 and spike_v1.10 machines
> > - - Rename sifive_e300 to sifive_e, and sifive_u500 to sifive_u
>
> Please don't send pull requests until after patches have been put
> on list and been reviewed. A minor update to a pullreq is OK if
> it's something like a trivial compiler fix or just dropping some
> patches that had problems, but if you have this many changes that
> deserves a fresh patchset to be sent to the list for review.
>
> (For the QEMU workflow, a pull request isn't a request for patch
> review, it's a statement that patches have all had review and
> are ready to go into master immediately.)


My apoligies. I won't do this again.

I have some very very minor cleanups that do not affect logic, but perhaps
we could address this after getting approval to make a pull request for v8.

My qemu-devel branch holds changes against the latest rebase:

- https://github.com/michaeljclark/riscv-qemu/tree/qemu-devel

Someone raised timebase frequency on the RISC-V sw-dev and after looking at
the code I noticed we had a hard-coded value for a few of the constants we
put in device tree, and i spotted a missed rename. I'm going to have to
learn about the qemu-devel process for trivial fixes...

Thanks for bearing with me, and my apologies for not following QEMU
workflow ettiquite with the v8 series. the tag is locked down and signed in
any case.

Regards,
Michael.

Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Peter Maydell]

On 2 March 2018 at 13:55, Michael Clark  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The following changes since commit 427cbc7e4136a061628cb4315cc8182ea36d772f:
>
>   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
> (2018-03-01 18:46:41 +)
>
> are available in the git repository at:
>
>   https://github.com/riscv/riscv-qemu.git tags/riscv-qemu-upstream-v8
>
> for you to fetch changes up to b6e0a38a922005d4015e2fdb42e8a783b3cc8e41:
>
>   RISC-V Build Infrastructure (2018-03-03 02:29:21 +1300)
>
> - 
> QEMU RISC-V Emulation Support (RV64GC, RV32GC)
>
> This release renames the SiFive machines to sifive_e and sifive_u
> to represent the SiFive Everywhere and SiFive Unleashed platforms.
> SiFive has configurable soft-core IP, so it is intended that these
> machines will be extended to enable a variety of SiFive IP blocks.
> The CPU definition infrastructure has been improved and there are
> now vendor CPU modules including the SiFiVe E31, E51, U34 and U54
> cores. The emulation accuracy for the E series has been improved
> by disabling the MMU for the E series. S mode has been disabled on
> cores that only support M mode and U mode. The two Spike machines
> that support two privileged ISA versions have been coalesced into
> one file. This series has Signed-off-by from the core contributors.
>
> The git tree for the v8 patch series tree (squashed and rebased):
>
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v8
>
> The git tree for the v1-v7 patch series with review commit history:
>
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v7
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v6
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v5
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v4
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v3
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v2
> - - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v1
>
> *** Known Issues ***
>
> - - Disassembler has some checkpatch warnings for the sake of code brevity
> - - scripts/qemu-binfmt-conf.sh has checkpatch warnings due to line length
> - - PMP (Physical Memory Protection) is as-of-yet unused and needs testing
>
> *** Changelog ***
>
> v8
>
> - - Added linux-user/riscv/target_elf.h during rebase
> - - Make resetvec configurable and clear mpp and mie on reset
> - - Use SiFive E31, E51, U34 and U54 cores in SiFive machines
> - - Define SiFive E31, E51, U34 and U54 cores
> - - Refactor CPU core definition in preparation for vendor cores
> - - Prevent S or U mode unless S or U extensions are present
> - - SiFive E Series cores have no MMU
> - - SiFive E Series cores have U mode
> - - Make privileged ISA v1.10 implicit in CPU types
> - - Remove DRAM_BASE and EXT_IO_BASE as they vary by machine
> - - Correctly handle mtvec and stvec alignment with respect to RVC
> - - Print more machine mode state in riscv_cpu_dump_state
> - - Make riscv_isa_string use compact extension order method
> - - Fix bug introduced in v6 RISCV_CPU_TYPE_NAME macro change
> - - Parameterize spike v1.9.1 config string
> - - Coalesce spike_v1.9.1 and spike_v1.10 machines
> - - Rename sifive_e300 to sifive_e, and sifive_u500 to sifive_u

Please don't send pull requests until after patches have been put
on list and been reviewed. A minor update to a pullreq is OK if
it's something like a trivial compiler fix or just dropping some
patches that had problems, but if you have this many changes that
deserves a fresh patchset to be sent to the list for review.

(For the QEMU workflow, a pull request isn't a request for patch
review, it's a statement that patches have all had review and
are ready to go into master immediately.)

thanks
-- PMM

[Qemu-devel] [PULL] RISC-V QEMU Port Submission v8

[Michael Clark]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The following changes since commit 427cbc7e4136a061628cb4315cc8182ea36d772f:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2018-03-01 18:46:41 +)

are available in the git repository at:

  https://github.com/riscv/riscv-qemu.git tags/riscv-qemu-upstream-v8

for you to fetch changes up to b6e0a38a922005d4015e2fdb42e8a783b3cc8e41:

  RISC-V Build Infrastructure (2018-03-03 02:29:21 +1300)

- 
QEMU RISC-V Emulation Support (RV64GC, RV32GC)

This release renames the SiFive machines to sifive_e and sifive_u
to represent the SiFive Everywhere and SiFive Unleashed platforms.
SiFive has configurable soft-core IP, so it is intended that these
machines will be extended to enable a variety of SiFive IP blocks.
The CPU definition infrastructure has been improved and there are
now vendor CPU modules including the SiFiVe E31, E51, U34 and U54
cores. The emulation accuracy for the E series has been improved
by disabling the MMU for the E series. S mode has been disabled on
cores that only support M mode and U mode. The two Spike machines
that support two privileged ISA versions have been coalesced into
one file. This series has Signed-off-by from the core contributors.

The git tree for the v8 patch series tree (squashed and rebased):

- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v8

The git tree for the v1-v7 patch series with review commit history:

- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v7
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v6
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v5
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v4
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v3
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v2
- - https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v1

*** Known Issues ***

- - Disassembler has some checkpatch warnings for the sake of code brevity
- - scripts/qemu-binfmt-conf.sh has checkpatch warnings due to line length
- - PMP (Physical Memory Protection) is as-of-yet unused and needs testing

*** Changelog ***

v8

- - Added linux-user/riscv/target_elf.h during rebase
- - Make resetvec configurable and clear mpp and mie on reset
- - Use SiFive E31, E51, U34 and U54 cores in SiFive machines
- - Define SiFive E31, E51, U34 and U54 cores
- - Refactor CPU core definition in preparation for vendor cores
- - Prevent S or U mode unless S or U extensions are present
- - SiFive E Series cores have no MMU
- - SiFive E Series cores have U mode
- - Make privileged ISA v1.10 implicit in CPU types
- - Remove DRAM_BASE and EXT_IO_BASE as they vary by machine
- - Correctly handle mtvec and stvec alignment with respect to RVC
- - Print more machine mode state in riscv_cpu_dump_state
- - Make riscv_isa_string use compact extension order method
- - Fix bug introduced in v6 RISCV_CPU_TYPE_NAME macro change
- - Parameterize spike v1.9.1 config string
- - Coalesce spike_v1.9.1 and spike_v1.10 machines
- - Rename sifive_e300 to sifive_e, and sifive_u500 to sifive_u

v7

- - Make spike_v1.10 the default machine
- - Rename spike_v1.9 to spike_v1.9.1 to match privileged spec version
- - Remove empty target/riscv/trace-events file
- - Monitor ROM 32-bit reset code needs to be target endian
- - Add TARGET_TIOCGPTPEER to linux-user/riscv/termbits.h
- - Add -initrd support to the virt board
- - Fix naming in spike machine interface header
- - Update copyright notice on RISC-V Spike machines
- - Update copyright notice on RISC-V HTIF Console device
- - Change CPU Core and translator to GPLv2+
- - Change RISC-V Disassembler to GPLv2+
- - Change SiFive Test Finisher to GPLv2+
- - Change SiFive CLINT to GPLv2+
- - Change SiFive PRCI to GPLv2+
- - Change SiFive PLIC to GPLv2+
- - Change RISC-V spike machines to GPLv2+
- - Change RISC-V virt machine to GPLv2+
- - Change SiFive E300 machine to GPLv2+
- - Change SiFive U500 machine to GPLv2+
- - Change RISC-V Hart Array to GPLv2+
- - Change RISC-V HTIF device to GPLv2+
- - Change SiFiveUART device to GPLv2+

v6

- - Drop IEEE 754-201x minimumNumber/maximumNumber for fmin/fmax
- - Remove some unnecessary commented debug statements
- - Change RISCV_CPU_TYPE_NAME to use riscv-cpu suffix
- - Define all CPU variants for linux-user
- - qemu_log calls require trailing \n
- - Replace PLIC printfs with qemu_log
- - Tear out unused HTIF code and eliminate shouting debug messages
- - Fix illegal instruction when sfence.vma is passed (rs2) arguments
- - Make updates to PTE accessed and dirty bits atomic
- - Only require atomic PTE updates on MTTCG enabled guests
- - Page fault if accessed or dirty bits can't be updated
- - Fix get_physical_address PTE reads and writes on riscv32
- - Remove erroneous comments from the PLIC
- - Default enable MTTCG
- - Make WFI less conservative
- - Unify local interrupt handling
- - Expunge HTIF