Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Laurent Desnogues 
On Mon, Feb 26, 2018 at 1:32 PM, Peter Maydell  wrote:
> Paragraph (3) isn't saying "BSD license is special",
> it's saying "the TCG codegen code is special" -- it's a theoretically
> well-defined reusable subset of code that has its own tighter standards
> for what license we accept (see also tcg/LICENSE).

That tcg/LICENSE file has alas become obsolete since the AArch64
back-end and its GPLv2+ license was added.  That's quite unfortunate.


Laurent

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Peter Maydell 
On 26 February 2018 at 12:03, Daniel P. Berrangé  wrote:
> Eeek, I totally missed that as the top level LICENSE file only mentions
> GPL and BSD licenses :-(  I guess that's a trigger for a patch to improve
> the text in the LICENSE file to better reflect reality...

Paragraph (2) says "Parts of QEMU have specific licenses which are
compatible with the GNU General Public License, version 2", which
is what this is. Paragraph (3) isn't saying "BSD license is special",
it's saying "the TCG codegen code is special" -- it's a theoretically
well-defined reusable subset of code that has its own tighter standards
for what license we accept (see also tcg/LICENSE).

thanks
-- PMM

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Daniel P . Berrangé 
On Mon, Feb 26, 2018 at 11:57:10AM +, Peter Maydell wrote:
> On 26 February 2018 at 10:47, Daniel P. Berrangé  wrote:
> > I accept that MIT is compatible with GPLv2+, so that's not an immediate 
> > legal
> > problem. The issue is that as we add more & more different licenses to QEMU,
> > it becomes a maintenance burden to developers, especially when doing code
> > refactoring across files. You have to be careful you're not taking a piece
> > of GPLv2+ code and copying/moving it into a file that's MIT licensed, as
> > that would be non-compliant. We already suffer this problem with our mixture
> > of GPLv2-only and GPLv2+ and LGPLv2+ and BSD licensed code. So I'm 
> > personally
> > loathe to see us add yet another license to the mix.
> 
> Unless I'm confused, we already have a lot of MIT-licensed code in the tree,
> including much of the block layer, accel/tcg, the audio subsystem. Looking
> at vl.c, it was put under the MIT license by Fabrice in 2003, so we've
> been living with it as part of our licensing mix for a very long time already.

Eeek, I totally missed that as the top level LICENSE file only mentions
GPL and BSD licenses :-(  I guess that's a trigger for a patch to improve
the text in the LICENSE file to better reflect reality...

So I guess you can ignore my comments in this thread about MIT license
being different from normal practice in QEMU.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Peter Maydell 
On 26 February 2018 at 10:47, Daniel P. Berrangé  wrote:
> I accept that MIT is compatible with GPLv2+, so that's not an immediate legal
> problem. The issue is that as we add more & more different licenses to QEMU,
> it becomes a maintenance burden to developers, especially when doing code
> refactoring across files. You have to be careful you're not taking a piece
> of GPLv2+ code and copying/moving it into a file that's MIT licensed, as
> that would be non-compliant. We already suffer this problem with our mixture
> of GPLv2-only and GPLv2+ and LGPLv2+ and BSD licensed code. So I'm personally
> loathe to see us add yet another license to the mix.

Unless I'm confused, we already have a lot of MIT-licensed code in the tree,
including much of the block layer, accel/tcg, the audio subsystem. Looking
at vl.c, it was put under the MIT license by Fabrice in 2003, so we've
been living with it as part of our licensing mix for a very long time already.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Andreas Schwab 
This is being used to build openSUSE Factory for riscv64 with linux-user
emulation:

https://build.opensuse.org/project/show/openSUSE:Factory:RISCV

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Richard W.M. Jones 
If anyone wants a simple way to test this, grab the latest bbl &
stage4 disk image from here and boot it under qemu-system-riscv64
using the command line given in the readme.txt file:

  https://fedorapeople.org/groups/risc-v/disk-images/

I've added v6 to Fedora copr, and switched to using it for the
Fedora/RISC-V build system, so it'll get a lot of heavy testing
shortly.

  http://copr-fe.cloud.fedoraproject.org/coprs/rjones/riscv/build/721136/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-26 Thread Daniel P . Berrangé 
On Sat, Feb 24, 2018 at 09:05:49AM +1300, Michael Clark wrote:
> Dear Daniel,
> 
> We've had this discussion on a recent pull request where some code was
> going to be copied directly from hw/arm/virt.c to hw/riscv/virt.c and we
> have subsequently relicensed the recipient file as GPLv2+. This code has
> not yet been incorporated into the port. Besides naming conventions and use
> of some common APIs, however the logic in hw/riscv/virt.c is original work.
> Try diffing them. I wrote the device tree code from scratch and we have a
> unique memory map, and the other functions are dervied from other RISC-V
> machines which are MIT licensed.
> 
> - https://github.com/riscv/riscv-qemu/pull/109
> 
> In any case, SiFive are happy to license their contributions as GPLv2+.
> We'll need to get the main contributors to agree to re-license to GPLv2+ or
> fall back to having GPLv2+ prefix the MIT license, as MIT is compatible
> with GPLv2+. Stefan O'Rear has commented that he is happy for his code to
> be GPLv2+ and so is SiFive, but we'll need to get confirmation from Sagar,
> one of the main port contributors, and potentially the whole list of
> contributors to do complete due diligence on re-licensing. i.e. if we want
> to eradicate MIT license from the code-base.
> 
> SiFive have made substantial changes to all of the non-GPLv2+ files in the
> port, and SiFive can license their contributions as GPLv2+ which would
> allow us to prefix all files in hw/riscv with GPLv2+. The only issue is
> that we must get approval from contributors to completely remove the MIT
> license, as the original contributors licensed their code under that
> license, as is the case for all of Fabrice's original code and many other
> parts of the code base e.g. GPEX hw/pci-host/gpex.c.
> 
> SiFive have made substantial changes to all files in the RISC-V port, so we
> would be empowered to at least prefix the MIT license with GPLv2+.
> 
> Is that acceptable? the MIT terms are compatible with GPLv2+ as MIT is a
> "permissive-license".

I accept that MIT is compatible with GPLv2+, so that's not an immediate legal
problem. The issue is that as we add more & more different licenses to QEMU,
it becomes a maintenance burden to developers, especially when doing code
refactoring across files. You have to be careful you're not taking a piece
of GPLv2+ code and copying/moving it into a file that's MIT licensed, as
that would be non-compliant. We already suffer this problem with our mixture
of GPLv2-only and GPLv2+ and LGPLv2+ and BSD licensed code. So I'm personally
loathe to see us add yet another license to the mix.

Ultimately though, Peter Maydall is the one who has the final say on whether
we'll pull the patch series. So I'll defer to him for a definitive answer on
whether its OK for riscv files to add MIT license to the mix, either long
term or as a temporary state.


> 
> 'cc Sagar, Bastian, as they have been main contributors to the port in the
> past...
> 
> Regards,
> Michael.
> 
> On Fri, Feb 23, 2018 at 11:10 PM, Daniel P. Berrangé 
> wrote:
> 
> > On Fri, Feb 23, 2018 at 01:11:46PM +1300, Michael Clark wrote:
> > > QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> > >
> > > This is hopefully the "fix remaining issues in-tree" release.
> >
> > This code seems to be a mixture of LGPLv2+ and MIT licensed code. The
> > preferred license for QEMU contributions is GPLv2+. Is there a reason
> > you need to diverge from this or can it be changed to be all GPLv2+ ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-23 Thread Michael Clark 
On Sat, Feb 24, 2018 at 10:31 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 02/22/2018 04:11 PM, Michael Clark wrote:
> > QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> >
> > This is hopefully the "fix remaining issues in-tree" release.
>
> FWIW, I'm happy with this.
>
> For those patches that I haven't given an explicit R-b, e.g. most of hw/, I
> didn't see anything obviously wrong.  So I'll give them
>
> Acked-by: Richard Henderson 
>
> Unless anyone has any other comments, I would expect the next step would
> be for
> you to create a signed pull request for Peter.
>

Thanks Richard!

I might see if I can sort out the license changes for include/hw/riscv/*.h
and hw/riscv/*.h

In either case, I've set the wheels in motion for the license change so it
can happen out-of-tree or in-tree... as SiFive is fine with GPLv2+, at
least for their stuff...

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-23 Thread Richard Henderson 
On 02/22/2018 04:11 PM, Michael Clark wrote:
> QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> 
> This is hopefully the "fix remaining issues in-tree" release.

FWIW, I'm happy with this.

For those patches that I haven't given an explicit R-b, e.g. most of hw/, I
didn't see anything obviously wrong.  So I'll give them

Acked-by: Richard Henderson 

Unless anyone has any other comments, I would expect the next step would be for
you to create a signed pull request for Peter.


r~

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-23 Thread Michael Clark 
Dear Daniel,

We've had this discussion on a recent pull request where some code was
going to be copied directly from hw/arm/virt.c to hw/riscv/virt.c and we
have subsequently relicensed the recipient file as GPLv2+. This code has
not yet been incorporated into the port. Besides naming conventions and use
of some common APIs, however the logic in hw/riscv/virt.c is original work.
Try diffing them. I wrote the device tree code from scratch and we have a
unique memory map, and the other functions are dervied from other RISC-V
machines which are MIT licensed.

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

In any case, SiFive are happy to license their contributions as GPLv2+.
We'll need to get the main contributors to agree to re-license to GPLv2+ or
fall back to having GPLv2+ prefix the MIT license, as MIT is compatible
with GPLv2+. Stefan O'Rear has commented that he is happy for his code to
be GPLv2+ and so is SiFive, but we'll need to get confirmation from Sagar,
one of the main port contributors, and potentially the whole list of
contributors to do complete due diligence on re-licensing. i.e. if we want
to eradicate MIT license from the code-base.

SiFive have made substantial changes to all of the non-GPLv2+ files in the
port, and SiFive can license their contributions as GPLv2+ which would
allow us to prefix all files in hw/riscv with GPLv2+. The only issue is
that we must get approval from contributors to completely remove the MIT
license, as the original contributors licensed their code under that
license, as is the case for all of Fabrice's original code and many other
parts of the code base e.g. GPEX hw/pci-host/gpex.c.

SiFive have made substantial changes to all files in the RISC-V port, so we
would be empowered to at least prefix the MIT license with GPLv2+.

Is that acceptable? the MIT terms are compatible with GPLv2+ as MIT is a
"permissive-license".

'cc Sagar, Bastian, as they have been main contributors to the port in the
past...

Regards,
Michael.

On Fri, Feb 23, 2018 at 11:10 PM, Daniel P. Berrangé 
wrote:

> On Fri, Feb 23, 2018 at 01:11:46PM +1300, Michael Clark wrote:
> > QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> >
> > This is hopefully the "fix remaining issues in-tree" release.
>
> This code seems to be a mixture of LGPLv2+ and MIT licensed code. The
> preferred license for QEMU contributions is GPLv2+. Is there a reason
> you need to diverge from this or can it be changed to be all GPLv2+ ?
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/
> dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/
> dberrange :|
>

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-23 Thread Daniel P . Berrangé 
On Fri, Feb 23, 2018 at 01:11:46PM +1300, Michael Clark wrote:
> QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> 
> This is hopefully the "fix remaining issues in-tree" release.

This code seems to be a mixture of LGPLv2+ and MIT licensed code. The
preferred license for QEMU contributions is GPLv2+. Is there a reason
you need to diverge from this or can it be changed to be all GPLv2+ ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-22 Thread no-reply 
Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1519344729-73482-1-git-send-email-...@sifive.com
Subject: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/1519344729-73482-1-git-send-email-...@sifive.com -> 
patchew/1519344729-73482-1-git-send-email-...@sifive.com
Switched to a new branch 'test'
91448084bc RISC-V Build Infrastructure
4d2720902a SiFive Freedom U500 RISC-V Machine
40842b8329 SiFive Freedom E300 RISC-V Machine
be9c81e24e SiFive RISC-V Test Finisher
381729e08d SiFive RISC-V PRCI Block
abbab7e14d SiFive RISC-V UART Device
d4d2ee95e5 RISC-V VirtIO Machine
bce4a92bc4 RISC-V Spike Machines
4a1a662a92 SiFive RISC-V PLIC Block
555fc1bf39 SiFive RISC-V CLINT Block
d5493312a1 RISC-V HART Array
119498d13f RISC-V HTIF Console
09491ad028 Add symbol table callback function interface to load_elf
d1b7cdbda6 RISC-V Linux User Emulation
69f3ef6300 RISC-V Physical Memory Protection
bfb296eb61 RISC-V TCG Code Generation
19947425dc RISC-V GDB Stub
9b571bcb34 RISC-V FPU Support
4e42636057 RISC-V CPU Helpers
b767e05ca0 RISC-V Disassembler
6ca41ebcac RISC-V CPU Core Definition
8f8ca2124d RISC-V ELF Machine Definition
8c4629c135 RISC-V Maintainers

=== OUTPUT BEGIN ===
Checking PATCH 1/23: RISC-V Maintainers...
Checking PATCH 2/23: RISC-V ELF Machine Definition...
Checking PATCH 3/23: RISC-V CPU Core Definition...
Checking PATCH 4/23: RISC-V Disassembler...
WARNING: line over 80 characters
#655: FILE: disas/riscv.c:603:
+static const rvc_constraint rvcc_jalr[] = { rvc_rd_eq_ra, rvc_imm_eq_zero, 
rvc_end };

ERROR: line over 90 characters
#656: FILE: disas/riscv.c:604:
+static const rvc_constraint rvcc_nop[] = { rvc_rd_eq_x0, rvc_rs1_eq_x0, 
rvc_imm_eq_zero, rvc_end };

WARNING: line over 80 characters
#686: FILE: disas/riscv.c:634:
+static const rvc_constraint rvcc_ret[] = { rvc_rd_eq_x0, rvc_rs1_eq_ra, 
rvc_end };

WARNING: line over 80 characters
#687: FILE: disas/riscv.c:635:
+static const rvc_constraint rvcc_jr[] = { rvc_rd_eq_x0, rvc_imm_eq_zero, 
rvc_end };

WARNING: line over 80 characters
#688: FILE: disas/riscv.c:636:
+static const rvc_constraint rvcc_rdcycle[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0xc00, rvc_end };

WARNING: line over 80 characters
#689: FILE: disas/riscv.c:637:
+static const rvc_constraint rvcc_rdtime[] = { rvc_rs1_eq_x0, rvc_csr_eq_0xc01, 
rvc_end };

ERROR: line over 90 characters
#690: FILE: disas/riscv.c:638:
+static const rvc_constraint rvcc_rdinstret[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0xc02, rvc_end };

ERROR: line over 90 characters
#691: FILE: disas/riscv.c:639:
+static const rvc_constraint rvcc_rdcycleh[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0xc80, rvc_end };

WARNING: line over 80 characters
#692: FILE: disas/riscv.c:640:
+static const rvc_constraint rvcc_rdtimeh[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0xc81, rvc_end };

ERROR: line over 90 characters
#693: FILE: disas/riscv.c:641:
+static const rvc_constraint rvcc_rdinstreth[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0xc80, rvc_end };

WARNING: line over 80 characters
#694: FILE: disas/riscv.c:642:
+static const rvc_constraint rvcc_frcsr[] = { rvc_rs1_eq_x0, rvc_csr_eq_0x003, 
rvc_end };

WARNING: line over 80 characters
#695: FILE: disas/riscv.c:643:
+static const rvc_constraint rvcc_frrm[] = { rvc_rs1_eq_x0, rvc_csr_eq_0x002, 
rvc_end };

WARNING: line over 80 characters
#696: FILE: disas/riscv.c:644:
+static const rvc_constraint rvcc_frflags[] = { rvc_rs1_eq_x0, 
rvc_csr_eq_0x001, rvc_end };

ERROR: line over 90 characters
#1095: FILE: disas/riscv.c:1043:
+{ "c.addi4spn", rv_codec_ciw_4spn, rv_fmt_rd_rs1_imm, NULL, rv_op_addi, 
rv_op_addi, rv_op_addi },

WARNING: line over 80 characters
#1096: FILE: disas/riscv.c:1044:
+{ "c.fld", rv_codec_cl_ld, rv_fmt_frd_offset_rs1, NULL, rv_op_fld, 
rv_op_fld, 0 },

WARNING: line over 80 characters
#1097: FILE: disas/riscv.c:1045:
+{ "c.lw", rv_codec_cl_lw, rv_fmt_rd_offset_rs1, NULL, rv_op_lw, rv_op_lw, 
rv_op_lw },

WARNING: line over 80 characters
#1099: FILE: disas/riscv.c:1047:
+{ "c.fsd", rv_codec_cs_sd, rv_fmt_frs2_offset_rs1, NULL, rv_op_fsd, 
rv_op_fsd, 0 },

WARNING: line over 80 characters
#1100: FILE: disas/riscv.c:1048:
+{ "c.sw", rv_codec_cs_sw, rv_fmt_rs2_

[Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission

2018-02-22 Thread Michael Clark 
QEMU RISC-V Emulation Support (RV64GC, RV32GC)

This is hopefully the "fix remaining issues in-tree" release.

This version the RISC-V patch series contains cleanups and adds locking to
the interrupt handling code and enables MTTCG. Fedora have been performing
MTTCG-enabled SMP package builds using the RISC-V 'virt' machine. This series
also removes a broken ELF implementation used by the HTIF driver, instead
adding a symbol table callback function interface to load_elf_*. The HTIF
driver has had a lot of cleanups and removal of redundant code. Also, the
"riscv" cpu type prefix has been changed to a "riscv-cpu" suffix to conform
with the scheme used by other ports. The current CPUs have been renamed with
a generic prefix. Subsequent patches will implement vendor CPU models.

We have temporarily dropped the fmin/fmax fix that adds softfloat support for
IEEE 754-201x minimumNumber/maximumNumber. This has the result of riscv-qemu
now failing the riscv-tests sNaN fmin/fmax test case. This will be fixed later.

All of the core code has now been reviewed and we believe the port is in shape
for a pull request pending review of a few remaining files in hw/riscv.
We have tested RV32/RV64 on 64-bit (x86_64) and 32-bit (i386) hosts.
RV64 riscv-linux boots on a Ubuntu 14.04 i386 host, however MTTCG is disabled.

Special thanks to Richard Henderson for his very detailed review comments,
Stefan O'Rear for his help with enabling MTTCG, and Richard WM Jones for
testing SMP support while creating the Fedora stage 4 image. Thanks to
everyone else who has given feedback submitted patches and pull requests.

The git tree for this v6 patch series (squashed and rebased):

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

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

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

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 interrupts
- Always access mstatus.mip under a lock
- Don't implement rdtime/rdtimeh in system mode (bbl emulates them)
- Implement insreth/cycleh for rv32 and always enable user-mode counters
- Add GDB stub support for reading and writing CSRs
- Rename ENABLE_CHARDEV #ifdef from HTIF code
- Replace bad HTIF ELF code with load_elf symbol callback
- Convert chained if else fault handlers to switch statements
- Use RISCV exception codes for linux-user page faults

v5

- Implement NaN-boxing for flw, set high order bits to 1
- Use float_muladd_negate_* flags to floatXX_muladd
- Use IEEE 754-201x minimumNumber/maximumNumber for fmin/fmax
- Fix TARGET_NR_syscalls
- Update linux-user/riscv/syscall_nr.h
- Fix FENCE.I, needs to terminate translation block
- Adjust unusual convention for interruptno >= 0

v4

- Add @riscv: since 2.12 to CpuInfoArch
- Remove misleading little-endian comment from load_kernel
- Rename cpu-model property to cpu-type
- Drop some unnecessary inline function attributes
- Don't allow GDB to set value of x0 register
- Remove unnecessary empty property lists
- Add Test Finisher device to implement poweroff in virt machine
- Implement priv ISA v1.10 trap and sret/mret xPIE/xIE behavior
- Store fflags data in fp_status
- Purge runtime users of helper_raise_exception
- Fix validate_csr
- Tidy gen_jalr
- Tidy immediate shifts
- Add gen_exception_inst_addr_mis
- Add gen_exception_debug
- Add gen_exception_illegal
- Tidy helper_fclass_*
- Split rounding mode setting to a new function
- Enforce MSTATUS_FS via TB flags
- Implement acquire/release barrier semantics
- Use atomic operations as required
- Fix FENCE and FENCE_I
- Remove commented code from spike machines
- PAGE_WRITE permissions can be set on loads if page is already dirty
- The result of format conversion on an NaN must be a quiet NaN
-