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

[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 +0000)

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 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
- - Add missing process_queued_cpu_work to riscv linux-user
- - Remove float(32|64)_classify from cpu.h
- - Removed nonsensical unions aliasing the same type
- - Use uintN_t instead of uintN_fast_t in fpu_helper.c
- - Use macros for FPU exception values in softfloat_flags_to_riscv
- - Move code to set round mode into set_fp_round_mode function
- - Convert set_fp_exceptions from a macro to an inline function
- - Convert round mode helper into an inline function
- - Make fpu_helper ieee_rm array static const
- - Include cpu_mmu_index in cpu_get_tb_cpu_state flags
- - Eliminate MPRV influence on mmu_index
- - Remove unrecoverable do_unassigned_access function
- - Only update PTE accessed and dirty bits if necessary
- - Remove unnecessary tlb_flush in set_mode as mode is in mmu_idx
- - Remove buggy support for misa writes. misa writes are optional
  and are not implemented in any known hardware
- - Always set PTE read or execute permissions during page walk
- - Reorder helper function declarations to match order in helper.c
- - Remove redundant variable declaration in get_physical_address
- - Remove duplicated code from get_physical_address
- - Use mmu_idx instead of mem_idx in riscv_cpu_get_phys_page_debug

v3

- - Fix indentation in PMP and HTIF debug macros
- - Fix disassembler checkpatch open brace '{' on next line errors
- - Fix trailing statements on next line in decode_inst_decompress
- - NOTE: the other checkpatch issues have been reviewed previously

v2

- - Remove redundant NULL terminators from disassembler register arrays
- - Change disassembler register name arrays to const
- - Refine disassembler internal function names
- - Update dates in disassembler copyright message
- - Remove #ifdef CONFIG_USER_ONLY version of cpu_has_work
- - Use ULL suffix on 64-bit constants
- - Move riscv_cpu_mmu_index from cpu.h to helper.c
- - Move riscv_cpu_hw_interrupts_pending from cpu.h to helper.c
- - Remove redundant TARGET_HAS_ICE from cpu.h
- - Use qemu_irq instead of void* for irq definition in cpu.h
- - Remove duplicate typedef from struct CPURISCVState
- - Remove redundant g_strdup from cpu_register
- - Remove redundant tlb_flush from riscv_cpu_reset
- - Remove redundant mode calculation from get_physical_address
- - Remove redundant debug mode printf and dcsr comment
- - Remove redundant clearing of MSB for bare physical addresses
- - Use g_assert_not_reached for invalid mode in get_physical_address
- - Use g_assert_not_reached for unreachable checks in get_physical_address
- - Use g_assert_not_reached for unreachable type in raise_mmu_exception
- - Return exception instead of aborting for misaligned fetches
- - Move exception defines from cpu.h to cpu_bits.h
- - Remove redundant breakpoint control definitions from cpu_bits.h
- - Implement riscv_cpu_unassigned_access exception handling
- - Log and raise exceptions for unimplemented CSRs
- - Match Spike HTIF exit behavior - don’t print TEST-PASSED
- - Make frm,fflags,fcsr writes trap when mstatus.FS is clear
- - Use g_assert_not_reached for unreachable invalid mode
- - Make hret,uret,dret generate illegal instructions
- - Move riscv_cpu_dump_state and int/fpr regnames to cpu.c
- - Lift interrupt flag and mask into constants in cpu_bits.h
- - Change trap debugging to use qemu_log_mask LOG_TRACE
- - Change CSR debugging to use qemu_log_mask LOG_TRACE
- - Change PMP debugging to use qemu_log_mask LOG_TRACE
- - Remove commented code from pmp.c
- - Change CpuInfoRISCV qapi schema docs to Since 2.12
- - Change RV feature macro to use target_ulong cast
- - Remove riscv_feature and instead use misa extension flags
- - Make riscv_flush_icache_syscall a no-op
- - Undo checkpatch whitespace fixes in unrelated linux-user code
- - Remove redudant constants and tidy up cpu_bits.h
- - Make helper_fence_i a no-op
- - Move include "exec/cpu-all" to end of cpu.h
- - Rename set_privilege to riscv_set_mode
- - Move redundant forward declaration for cpu_riscv_translate_address
- - Remove TCGV_UNUSED from riscv_translate_init
- - Add comment to pmp.c stating the code is untested and currently unused
- - Use ctz to simplify decoding of PMP NAPOT address ranges
- - Change pmp_is_in_range to use than equal for end addresses
- - Fix off by one error in pmp_update_rule
- - Rearrange PMP_DEBUG so that formatting is compile-time checked
- - Rearrange trap debugging so that formatting is compile-time checked
- - Rearrange PLIC debugging so that formatting is compile-time checked
- - Use qemu_log/qemu_log_mask for HTIF logging and debugging
- - Move exception and interrupt names into cpu.c
- - Add Palmer Dabbelt as a RISC-V Maintainer
- - Rebase against current qemu master branch

v1

- - initial version based on forward port from riscv-qemu repository

*** Background ***

"RISC-V is an open, free ISA enabling a new era of processor innovation
through open standard collaboration. Born in academia and research,
RISC-V ISA delivers a new level of free, extensible software and
hardware freedom on architecture, paving the way for the next 50 years
of computing design and innovation."

The QEMU RISC-V port has been developed and maintained out-of-tree for
several years by Sagar Karandikar and Bastian Koppelmann. The RISC-V
Privileged specification has evolved substantially over this period but
has recently been solidifying. The RISC-V Base ISA has been frozon for
some time and the Privileged ISA, GCC toolchain and Linux ABI are now
quite stable. I have recently joined Sagar and Bastian as a RISC-V QEMU
Maintainer and hope to support upstreaming the port.

There are multiple vendors taping out, preparing to ship, or shipping
silicon that implements the RISC-V Privileged ISA Version 1.10. There
are also several RISC-V Soft-IP cores implementing Privileged ISA
Version 1.10 that run on FPGA such as SiFive's Freedom U500 Platform
and the U54‑MC RISC-V Core IP, among many more implementations from a
variety of vendors. See https://riscv.org/ for more details.

RISC-V support was upstreamed in binutils 2.28 and GCC 7.1 in the first
half of 2016. RISC-V support is now available in LLVM top-of-tree and
the RISC-V Linux port was accepted into Linux 4.15-rc1 late last year
and is available in the Linux 4.15 release. GLIBC 2.27 added support
for the RISC-V ISA running on Linux (requires at least binutils-2.30,
gcc-7.3.0, and linux-4.15). We believe it is timely to submit the
RISC-V QEMU port for upstream review with the goal of incorporating
RISC-V support into the upcoming QEMU 2.12 release.

The RISC-V QEMU port is still under active development, mostly with
respect to device emulation, the addition of Hypervisor support as
specified in the RISC-V Draft Privileged ISA Version 1.11, and Vector
support once the first draft is finalized later this year. We believe
now is the appropriate time for RISC-V QEMU development to be carried
out in the main QEMU repository as the code will benefit from more
rigorous review. The RISC-V QEMU port currently supports all the ISA
extensions that have been finalized and frozen in the Base ISA.

Blog post about recent additions to RISC-V QEMU: https://goo.gl/fJ4zgk

The RISC-V QEMU wiki: https://github.com/riscv/riscv-qemu/wiki

Instructions for building a busybox+dropbear root image, BBL (Berkeley
Boot Loader) and linux kernel image for use with the RISC-V QEMU
'virt' machine: https://github.com/michaeljclark/busybear-linux

*** Overview ***

The RISC-V QEMU port implements the following specifications:

- - RISC-V Instruction Set Manual Volume I: User-Level ISA Version 2.2
- - RISC-V Instruction Set Manual Volume II: Privileged ISA Version 1.9.1
- - RISC-V Instruction Set Manual Volume II: Privileged ISA Version 1.10

The RISC-V QEMU port supports the following instruction set extensions:

- - RV32GC with Supervisor-mode and User-mode (RV32IMAFDCSU)
- - RV64GC with Supervisor-mode and User-mode (RV64IMAFDCSU)

The RISC-V QEMU port adds the following targets to QEMU:

- - riscv32-softmmu
- - riscv64-softmmu
- - riscv32-linux-user
- - riscv64-linux-user

The RISC-V QEMU port supports the following hardware:

- - HTIF Console (Host Target Interface)
- - SiFive CLINT (Core Local Interruptor) for Timer interrupts and IPIs
- - SiFive PLIC (Platform Level Interrupt Controller)
- - SiFive Test (Test Finisher) for exiting simulation
- - SiFive UART, PRCI, AON, PWM, QSPI support is partially implemented
- - VirtIO MMIO (GPEX PCI support will be added in a future patch)
- - Generic 16550A UART emulation using 'hw/char/serial.c'
- - MTTCG and SMP support (PLIC and CLINT) on the 'virt' machine

The RISC-V QEMU full system emulator supports 5 machines:

- - 'spike_v1.9.1', CLINT, PLIC, HTIF console, config-string, Priv v1.9.1
- - 'spike_v1.10', CLINT, PLIC, HTIF console, device-tree, Priv v1.10
- - 'sifive_e', CLINT, PLIC, SiFive UART, HiFive1 compat, Priv v1.10
- - 'sifive_u', CLINT, PLIC, SiFive UART, device-tree, Priv v1.10
- - 'virt', CLINT, PLIC, 16550A UART, VirtIO, device-tree, Priv v1.10

This is a list of RISC-V QEMU Port Contributors:

- - Alex Suykov
- - Andreas Schwab
- - Antony Pavlov
- - Bastian Koppelmann
- - Bruce Hoult
- - Chih-Min Chao
- - Daire McNamara
- - Darius Rad
- - David Abdurachmanov
- - Hesham Almatary
- - Ivan Griffin
- - Jim Wilson
- - Kito Cheng
- - Michael Clark
- - Palmer Dabbelt
- - Richard Henderson
- - Sagar Karandikar
- - Shea Levy
- - Stefan O'Rear

Notes:

- - contributor email addresses available off-list on request.
- - checkpatch has been run on all 23 patches.
- - checkpatch exceptions are noted in patches that have errors.
- - passes "make check" on full build for all targets
- - tested riscv-linux-4.6.2 on 'spike_v1.9.1' machine
- - tested riscv-linux-4.15 on 'spike_v1.10' and 'virt' machines
- - tested SiFive HiFive1 binaries in 'sifive_e' machine
- - tested RV64 on 32-bit i386

This patch series includes the following patches:

- ----------------------------------------------------------------
Michael Clark (23):
      RISC-V Maintainers
      RISC-V ELF Machine Definition
      RISC-V CPU Core Definition
      RISC-V Disassembler
      RISC-V CPU Helpers
      RISC-V FPU Support
      RISC-V GDB Stub
      RISC-V TCG Code Generation
      RISC-V Physical Memory Protection
      RISC-V Linux User Emulation
      Add symbol table callback interface to load_elf
      RISC-V HTIF Console
      RISC-V HART Array
      SiFive RISC-V CLINT Block
      SiFive RISC-V PLIC Block
      RISC-V Spike Machines
      SiFive RISC-V Test Finisher
      RISC-V VirtIO Machine
      SiFive RISC-V UART Device
      SiFive RISC-V PRCI Block
      SiFive Freedom E Series RISC-V Machine
      SiFive Freedom U Series RISC-V Machine
      RISC-V Build Infrastructure

 MAINTAINERS                            |   11 +
 arch_init.c                            |    2 +
 configure                              |   13 +
 cpus.c                                 |    6 +
 default-configs/riscv32-linux-user.mak |    1 +
 default-configs/riscv32-softmmu.mak    |    4 +
 default-configs/riscv64-linux-user.mak |    1 +
 default-configs/riscv64-softmmu.mak    |    4 +
 disas.c                                |    2 +
 disas/Makefile.objs                    |    1 +
 disas/riscv.c                          | 3048 ++++++++++++++++++++++++++++++++
 fpu/softfloat-specialize.h             |    7 +-
 hw/core/loader.c                       |   18 +-
 hw/riscv/Makefile.objs                 |   11 +
 hw/riscv/riscv_hart.c                  |   89 +
 hw/riscv/riscv_htif.c                  |  258 +++
 hw/riscv/sifive_clint.c                |  254 +++
 hw/riscv/sifive_e.c                    |  234 +++
 hw/riscv/sifive_plic.c                 |  505 ++++++
 hw/riscv/sifive_prci.c                 |   89 +
 hw/riscv/sifive_test.c                 |   93 +
 hw/riscv/sifive_u.c                    |  339 ++++
 hw/riscv/sifive_uart.c                 |  176 ++
 hw/riscv/spike.c                       |  376 ++++
 hw/riscv/virt.c                        |  420 +++++
 include/disas/bfd.h                    |    2 +
 include/elf.h                          |    2 +
 include/hw/elf_ops.h                   |   34 +-
 include/hw/loader.h                    |   17 +-
 include/hw/riscv/riscv_hart.h          |   39 +
 include/hw/riscv/riscv_htif.h          |   61 +
 include/hw/riscv/sifive_clint.h        |   50 +
 include/hw/riscv/sifive_e.h            |   79 +
 include/hw/riscv/sifive_plic.h         |   85 +
 include/hw/riscv/sifive_prci.h         |   37 +
 include/hw/riscv/sifive_test.h         |   42 +
 include/hw/riscv/sifive_u.h            |   69 +
 include/hw/riscv/sifive_uart.h         |   71 +
 include/hw/riscv/spike.h               |   53 +
 include/hw/riscv/virt.h                |   74 +
 include/sysemu/arch_init.h             |    1 +
 linux-user/elfload.c                   |   22 +
 linux-user/main.c                      |   99 ++
 linux-user/riscv/syscall_nr.h          |  287 +++
 linux-user/riscv/target_cpu.h          |   18 +
 linux-user/riscv/target_elf.h          |   14 +
 linux-user/riscv/target_signal.h       |   23 +
 linux-user/riscv/target_structs.h      |   46 +
 linux-user/riscv/target_syscall.h      |   56 +
 linux-user/riscv/termbits.h            |  222 +++
 linux-user/signal.c                    |  203 ++-
 linux-user/syscall.c                   |    2 +
 linux-user/syscall_defs.h              |   13 +-
 qapi-schema.json                       |   17 +-
 scripts/qemu-binfmt-conf.sh            |   13 +-
 target/riscv/Makefile.objs             |    1 +
 target/riscv/cpu.c                     |  432 +++++
 target/riscv/cpu.h                     |  296 ++++
 target/riscv/cpu_bits.h                |  411 +++++
 target/riscv/cpu_user.h                |   13 +
 target/riscv/fpu_helper.c              |  373 ++++
 target/riscv/gdbstub.c                 |   62 +
 target/riscv/helper.c                  |  503 ++++++
 target/riscv/helper.h                  |   78 +
 target/riscv/instmap.h                 |  364 ++++
 target/riscv/op_helper.c               |  669 +++++++
 target/riscv/pmp.c                     |  380 ++++
 target/riscv/pmp.h                     |   64 +
 target/riscv/translate.c               | 1978 +++++++++++++++++++++
 69 files changed, 13310 insertions(+), 27 deletions(-)
 create mode 100644 default-configs/riscv32-linux-user.mak
 create mode 100644 default-configs/riscv32-softmmu.mak
 create mode 100644 default-configs/riscv64-linux-user.mak
 create mode 100644 default-configs/riscv64-softmmu.mak
 create mode 100644 disas/riscv.c
 create mode 100644 hw/riscv/Makefile.objs
 create mode 100644 hw/riscv/riscv_hart.c
 create mode 100644 hw/riscv/riscv_htif.c
 create mode 100644 hw/riscv/sifive_clint.c
 create mode 100644 hw/riscv/sifive_e.c
 create mode 100644 hw/riscv/sifive_plic.c
 create mode 100644 hw/riscv/sifive_prci.c
 create mode 100644 hw/riscv/sifive_test.c
 create mode 100644 hw/riscv/sifive_u.c
 create mode 100644 hw/riscv/sifive_uart.c
 create mode 100644 hw/riscv/spike.c
 create mode 100644 hw/riscv/virt.c
 create mode 100644 include/hw/riscv/riscv_hart.h
 create mode 100644 include/hw/riscv/riscv_htif.h
 create mode 100644 include/hw/riscv/sifive_clint.h
 create mode 100644 include/hw/riscv/sifive_e.h
 create mode 100644 include/hw/riscv/sifive_plic.h
 create mode 100644 include/hw/riscv/sifive_prci.h
 create mode 100644 include/hw/riscv/sifive_test.h
 create mode 100644 include/hw/riscv/sifive_u.h
 create mode 100644 include/hw/riscv/sifive_uart.h
 create mode 100644 include/hw/riscv/spike.h
 create mode 100644 include/hw/riscv/virt.h
 create mode 100644 linux-user/riscv/syscall_nr.h
 create mode 100644 linux-user/riscv/target_cpu.h
 create mode 100644 linux-user/riscv/target_elf.h
 create mode 100644 linux-user/riscv/target_signal.h
 create mode 100644 linux-user/riscv/target_structs.h
 create mode 100644 linux-user/riscv/target_syscall.h
 create mode 100644 linux-user/riscv/termbits.h
 create mode 100644 target/riscv/Makefile.objs
 create mode 100644 target/riscv/cpu.c
 create mode 100644 target/riscv/cpu.h
 create mode 100644 target/riscv/cpu_bits.h
 create mode 100644 target/riscv/cpu_user.h
 create mode 100644 target/riscv/fpu_helper.c
 create mode 100644 target/riscv/gdbstub.c
 create mode 100644 target/riscv/helper.c
 create mode 100644 target/riscv/helper.h
 create mode 100644 target/riscv/instmap.h
 create mode 100644 target/riscv/op_helper.c
 create mode 100644 target/riscv/pmp.c
 create mode 100644 target/riscv/pmp.h
 create mode 100644 target/riscv/translate.c
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQR8mZMOsXzYugc9Xvpr8dezV+8+TwUCWplUuQAKCRBr8dezV+8+
T6u0AKCBe9DLKQ8g9T5J3Gzpb/XBXVEODQCeLrfRCglGqcaX9869KwM4Z/kbTZg=
=j1E4
-----END PGP SIGNATURE-----

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

[Peter Maydell]

On 2 March 2018 at 13:55, Michael Clark <mjc@sifive.com> 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 +0000)
>
> 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

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

[Michael Clark]

On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 2 March 2018 at 13:55, Michael Clark <mjc@sifive.com> 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 3 March 2018 at 02:46, Michael Clark <mjc@sifive.com> wrote:
> On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell <peter.maydell@linaro.org>
> 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 Sun, Mar 4, 2018 at 11:52 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 3 March 2018 at 02:46, Michael Clark <mjc@sifive.com> wrote:
> > On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell <peter.maydell@linaro.org>
> > 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

[Michael Clark]

On Tue, Mar 6, 2018 at 12:10 PM, Michael Clark <mjc@sifive.com> wrote:

>
>
> On Sun, Mar 4, 2018 at 11:52 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>
>> On 3 March 2018 at 02:46, Michael Clark <mjc@sifive.com> wrote:
>> > On Sat, Mar 3, 2018 at 3:22 AM, Peter Maydell <peter.maydell@linaro.org
>> >
>> > 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 'remotes/stefanha/tags/block-pull-request' into staging. See here:

- https://github.com/riscv/riscv-qemu/releases/tag/riscv-qemu-upstream-v8.1

I've rebased my queued changes against the qemu-upstream-v8.1 branch (tag r
iscv-qemu-upstream-v8.1) and have them in my own tree:

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

I have a pending pull request against the riscv.org tree for my queued
changes, which I may re-target if we get these changes upstream:

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

Would appreciate it some folk could add a remote for
github.com/riscv/riscv-qemu.git and pull in riscv-qemu-upstream-v8.1, and
test... It's been pretty well tested out-of-tree already. RISC-V docs are
on the wiki, which require the riscv-toolchain, building and packaging
riscv-linux inside riscv-pk/bbl.

- https://github.com/riscv/riscv-qemu/wiki

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 want to do this as I'd like to get the riscv CI to automate
some more of the "execution environment" testing (which could be spike,
qemu, FPGA, or silicon). I'm also working on cross toolchain packages to
automate some of the test image creation. I perform various local tests
manually. i.e. booting linux on the various board combinations, and running
MCU binaries on the MMU-less SiFive E-series board, which can run HiFive1
binaries (i.e. a little more than make check). I'm pretty confident that we
won't hurt any other arches. The only core code change is to add a symbol
callback function to load_elf for our HTIF (Host Target Interface).

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

[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

[Peter Maydell]

On 6 March 2018 at 01:30, Michael Clark <mjc@sifive.com> 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

[Michael Clark]

On Tue, Mar 6, 2018 at 10:13 PM, Andrea Bolognani <abologna@redhat.com>
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

[Michael Clark]

On Wed, Mar 7, 2018 at 12:09 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 6 March 2018 at 01:30, Michael Clark <mjc@sifive.com> 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
>