qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] c05a6c: hw/intc/riscv_aplic: APLICs should ad


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] c05a6c: hw/intc/riscv_aplic: APLICs should add child earli...
Date: Mon, 27 May 2024 22:28:42 -0700

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: c05a6c60d1d850f76ca0f8c17d4cc7c7df0c3ef5
      
https://github.com/qemu/qemu/commit/c05a6c60d1d850f76ca0f8c17d4cc7c7df0c3ef5
  Author: yang.zhang <yang.zhang@hexintek.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M hw/intc/riscv_aplic.c

  Log Message:
  -----------
  hw/intc/riscv_aplic: APLICs should add child earlier than realize

Since only root APLICs can have hw IRQ lines, aplic->parent should
be initialized first.

Fixes: e8f79343cf ("hw/intc: Add RISC-V AIA APLIC device emulation")
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Signed-off-by: yang.zhang <yang.zhang@hexintek.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240409014445.278-1-gaoshanliukou@163.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 6f9dcda55cfe198de6be1ba14f01594916ae873c
      
https://github.com/qemu/qemu/commit/6f9dcda55cfe198de6be1ba14f01594916ae873c
  Author: Andrew Jones <ajones@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.h
    M target/riscv/csr.c
    M target/riscv/kvm/kvm-cpu.c

  Log Message:
  -----------
  target/riscv/kvm: Fix exposure of Zkr

The Zkr extension may only be exposed to KVM guests if the VMM
implements the SEED CSR. Use the same implementation as TCG.

Without this patch, running with a KVM which does not forward the
SEED CSR access to QEMU will result in an ILL exception being
injected into the guest (this results in Linux guests crashing on
boot). And, when running with a KVM which does forward the access,
QEMU will crash, since QEMU doesn't know what to do with the exit.

Fixes: 3108e2f1c69d ("target/riscv/kvm: update KVM exts to Linux 6.8")
Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240422134605.534207-2-ajones@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 96b982d920914787841a86ae93ba0df4a00b1e48
      
https://github.com/qemu/qemu/commit/96b982d920914787841a86ae93ba0df4a00b1e48
  Author: Andrew Jones <ajones@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/helper.h
    M target/riscv/insn_trans/trans_rvzawrs.c.inc
    M target/riscv/op_helper.c

  Log Message:
  -----------
  target/riscv: Raise exceptions on wrs.nto

Implementing wrs.nto to always just return is consistent with the
specification, as the instruction is permitted to terminate the
stall for any reason, but it's not useful for virtualization, where
we'd like the guest to trap to the hypervisor in order to allow
scheduling of the lock holding VCPU. Change to always immediately
raise exceptions when the appropriate conditions are present,
otherwise continue to just return. Note, immediately raising
exceptions is also consistent with the specification since the
time limit that should expire prior to the exception is
implementation-specific.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Christoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240424142808.62936-2-ajones@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 1bdc520df2ef26d0e8085d6d3e3e2bbbc63e8f8b
      
https://github.com/qemu/qemu/commit/1bdc520df2ef26d0e8085d6d3e3e2bbbc63e8f8b
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/kvm/kvm-cpu.c
    M target/riscv/sbi_ecall_interface.h

  Log Message:
  -----------
  target/riscv/kvm: implement SBI debug console (DBCN) calls

SBI defines a Debug Console extension "DBCN" that will, in time, replace
the legacy console putchar and getchar SBI extensions.

The appeal of the DBCN extension is that it allows multiple bytes to be
read/written in the SBI console in a single SBI call.

As far as KVM goes, the DBCN calls are forwarded by an in-kernel KVM
module to userspace. But this will only happens if the KVM module
actually supports this SBI extension and we activate it.

We'll check for DBCN support during init time, checking if get-reg-list
is advertising KVM_RISCV_SBI_EXT_DBCN. In that case, we'll enable it via
kvm_set_one_reg() during kvm_arch_init_vcpu().

Finally, change kvm_riscv_handle_sbi() to handle the incoming calls for
SBI_EXT_DBCN, reading and writing as required.

A simple KVM guest with 'earlycon=sbi', running in an emulated RISC-V
host, takes around 20 seconds to boot without using DBCN. With this
patch we're taking around 14 seconds to boot due to the speed-up in the
terminal output.  There's no change in boot time if the guest isn't
using earlycon.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20240425155012.581366-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 5f29facb9030fccce125312d3b3ed269af8eb63c
      
https://github.com/qemu/qemu/commit/5f29facb9030fccce125312d3b3ed269af8eb63c
  Author: Cheng Yang <yangcheng.work@foxmail.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M hw/riscv/boot.c

  Log Message:
  -----------
  hw/riscv/boot.c: Support 64-bit address for initrd

Use qemu_fdt_setprop_u64() instead of qemu_fdt_setprop_cell()
to set the address of initrd in FDT to support 64-bit address.

Signed-off-by: Cheng Yang <yangcheng.work@foxmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <tencent_A4482251DD0890F312758FA6B33F60815609@qq.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 2451841da883364ccef228f27168153364e62559
      
https://github.com/qemu/qemu/commit/2451841da883364ccef228f27168153364e62559
  Author: Clément Léger <cleger@rivosinc.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu_bits.h

  Log Message:
  -----------
  target/riscv: change RISCV_EXCP_SEMIHOST exception number to 63

The current semihost exception number (16) is a reserved number (range
[16-17]). The upcoming double trap specification uses that number for
the double trap exception. Since the privileged spec (Table 22) defines
ranges for custom uses change the semihosting exception number to 63
which belongs to the range [48-63] in order to avoid any future
collisions with reserved exception.

Signed-off-by: Clément Léger <cleger@rivosinc.com>

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240422135840.1959967-1-cleger@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 5abe7ca759e927a986d507b1349061fcc8507bda
      
https://github.com/qemu/qemu/commit/5abe7ca759e927a986d507b1349061fcc8507bda
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/kvm/kvm-cpu.c

  Log Message:
  -----------
  target/riscv/kvm: tolerate KVM disable ext errors

Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
enabled, will fail with a kernel oops SIGILL right at the start. The
reason is that we can't expose zkr without implementing the SEED CSR.
Disabling zkr in the guest would be a workaround, but if the KVM doesn't
allow it we'll error out and never boot.

In hindsight this is too strict. If we keep proceeding, despite not
disabling the extension in the KVM vcpu, we'll not add the extension in
the riscv,isa. The guest kernel will be unaware of the extension, i.e.
it doesn't matter if the KVM vcpu has it enabled underneath or not. So
it's ok to keep booting in this case.

Change our current logic to not error out if we fail to disable an
extension in kvm_set_one_reg(), but show a warning and keep booting. It
is important to throw a warning because we must make the user aware that
the extension is still available in the vcpu, meaning that an
ill-behaved guest can ignore the riscv,isa settings and  use the
extension.

The case we're handling happens with an EINVAL error code. If we fail to
disable the extension in KVM for any other reason, error out.

We'll also keep erroring out when we fail to enable an extension in KVM,
since adding the extension in riscv,isa at this point will cause a guest
malfunction because the extension isn't enabled in the vcpu.

Suggested-by: Andrew Jones <ajones@ventanamicro.com>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240422171425.333037-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: e4ce5332e7a26de07d5b3f6d0698af2f050ccacc
      
https://github.com/qemu/qemu/commit/e4ce5332e7a26de07d5b3f6d0698af2f050ccacc
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu_helper.c
    M target/riscv/debug.c

  Log Message:
  -----------
  target/riscv/debug: set tval=pc in breakpoint exceptions

We're not setting (s/m)tval when triggering breakpoints of type 2
(mcontrol) and 6 (mcontrol6). According to the debug spec section
5.7.12, "Match Control Type 6":

"The Privileged Spec says that breakpoint exceptions that occur on
instruction fetches, loads, or stores update the tval CSR with either
zero or the faulting virtual address. The faulting virtual address for
an mcontrol6 trigger with action = 0 is the address being accessed and
which caused that trigger to fire."

A similar text is also found in the Debug spec section 5.7.11 w.r.t.
mcontrol.

Note that what we're doing ATM is not violating the spec, but it's
simple enough to set mtval/stval and it makes life easier for any
software that relies on this info.

Given that we always use action = 0, save the faulting address for the
mcontrol and mcontrol6 trigger breakpoints into env->badaddr, which is
used as as scratch area for traps with address information. 'tval' is
then set during riscv_cpu_do_interrupt().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Message-ID: <20240416230437.1869024-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: fce17e4bd7d2321b784cbcb69f08de7dc5534368
      
https://github.com/qemu/qemu/commit/fce17e4bd7d2321b784cbcb69f08de7dc5534368
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_privileged.c.inc

  Log Message:
  -----------
  trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

Privileged spec section 4.1.9 mentions:

"When a trap is taken into S-mode, stval is written with
exception-specific information to assist software in handling the trap.
(...)

If stval is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, or page-fault exception occurs on an
instruction fetch, load, or store, then stval will contain the faulting
virtual address."

A similar text is found for mtval in section 3.1.16.

Setting mtval/stval in this scenario is optional, but some softwares read
these regs when handling ebreaks.

Write 'badaddr' in all ebreak breakpoints to write the appropriate
'tval' during riscv_do_cpu_interrrupt().

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240416230437.1869024-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 2c55fcaf3dcd40a086bac1afdebb9e59ab060a4c
      
https://github.com/qemu/qemu/commit/2c55fcaf3dcd40a086bac1afdebb9e59ab060a4c
  Author: Jason Chien <jason.chien@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.c
    M target/riscv/cpu_cfg.h
    M target/riscv/cpu_helper.c
    M target/riscv/csr.c
    M target/riscv/insn_trans/trans_rvv.c.inc
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: Add support for Zve32x extension

Add support for Zve32x extension and replace some checks for Zve32f with
Zve32x, since Zve32f depends on Zve32x.

Signed-off-by: Jason Chien <jason.chien@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240328022343.6871-2-jason.chien@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 584e1899d1ebfd9f37b654bdaac1d6e5b75d48ad
      
https://github.com/qemu/qemu/commit/584e1899d1ebfd9f37b654bdaac1d6e5b75d48ad
  Author: Jason Chien <jason.chien@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.c
    M target/riscv/cpu_cfg.h
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: Add support for Zve64x extension

Add support for Zve64x extension. Enabling Zve64f enables Zve64x and
enabling Zve64x enables Zve32x according to their dependency.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2107
Signed-off-by: Jason Chien <jason.chien@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240328022343.6871-3-jason.chien@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 6f2dac8d7042f92bd810d566686b01f629db2d43
      
https://github.com/qemu/qemu/commit/6f2dac8d7042f92bd810d566686b01f629db2d43
  Author: Jason Chien <jason.chien@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/gdbstub.c

  Log Message:
  -----------
  target/riscv: Relax vector register check in RISCV gdbstub

In current implementation, the gdbstub allows reading vector registers
only if V extension is supported. However, all vector extensions and
vector crypto extensions have the vector registers and they all depend
on Zve32x. The gdbstub should check for Zve32x instead.

Signed-off-by: Jason Chien <jason.chien@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Message-ID: <20240328022343.6871-4-jason.chien@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 553ea83f3b2e07616729fa6e4b9fb9b014ba37da
      
https://github.com/qemu/qemu/commit/553ea83f3b2e07616729fa6e4b9fb9b014ba37da
  Author: Huang Tao <eric.huang@linux.alibaba.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/vector_internals.c

  Log Message:
  -----------
  target/riscv: Fix the element agnostic function problem

In RVV and vcrypto instructions, the masked and tail elements are set to 1s
using vext_set_elems_1s function if the vma/vta bit is set. It is the element
agnostic policy.

However, this function can't deal the big endian situation. This patch fixes
the problem by adding handling of such case.

Signed-off-by: Huang Tao <eric.huang@linux.alibaba.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240325021654.6594-1-eric.huang@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 9acdb110899682759b1e9d00157e580fa791f460
      
https://github.com/qemu/qemu/commit/9acdb110899682759b1e9d00157e580fa791f460
  Author: Yangyu Chen <cyy@cyyself.name>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.c

  Log Message:
  -----------
  target/riscv/cpu.c: fix Zvkb extension config

This code has a typo that writes zvkb to zvkg, causing users can't
enable zvkb through the config. This patch gets this fixed.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Fixes: ea61ef7097d0 ("target/riscv: Move vector crypto extensions to 
riscv_cpu_extensions")
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Max Chou <max.chou@sifive.com>
Reviewed-by:  Weiwei Li <liwei1518@gmail.com>
Message-ID: <tencent_7E34EEF0F90B9A68BF38BEE09EC6D4877C0A@qq.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: d774b027d138931a6aeb8979ed472506d35c1c29
      
https://github.com/qemu/qemu/commit/d774b027d138931a6aeb8979ed472506d35c1c29
  Author: Huang Tao <eric.huang@linux.alibaba.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.c
    M target/riscv/cpu.h
    M target/riscv/tcg/tcg-cpu.c
    M target/riscv/tcg/tcg-cpu.h
    M target/riscv/translate.c

  Log Message:
  -----------
  target/riscv: Implement dynamic establishment of custom decoder

In this patch, we modify the decoder to be a freely composable data
structure instead of a hardcoded one. It can be dynamically builded up
according to the extensions.
This approach has several benefits:
1. Provides support for heterogeneous cpu architectures. As we add decoder in
   RISCVCPU, each cpu can have their own decoder, and the decoders can be
   different due to cpu's features.
2. Improve the decoding efficiency. We run the guard_func to see if the decoder
   can be added to the dynamic_decoder when building up the decoder. Therefore,
   there is no need to run the guard_func when decoding each instruction. It can
   improve the decoding efficiency
3. For vendor or dynamic cpus, it allows them to customize their own decoder
   functions to improve decoding efficiency, especially when vendor-defined
   instruction sets increase. Because of dynamic building up, it can skip the 
other
   decoder guard functions when decoding.
4. Pre patch for allowing adding a vendor decoder before decode_insn32() with 
minimal
   overhead for users that don't need this particular vendor decoder.

Signed-off-by: Huang Tao <eric.huang@linux.alibaba.com>
Suggested-by: Christoph Muellner <christoph.muellner@vrull.eu>
Co-authored-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240506023607.29544-1-eric.huang@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: f06d4ef67e566e10c300e02460fe57e33e7d2558
      
https://github.com/qemu/qemu/commit/f06d4ef67e566e10c300e02460fe57e33e7d2558
  Author: Christoph Müllner <christoph.muellner@vrull.eu>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M MAINTAINERS
    M target/riscv/cpu.c
    M target/riscv/cpu.h
    M target/riscv/meson.build
    A target/riscv/th_csr.c

  Log Message:
  -----------
  riscv: thead: Add th.sxstatus CSR emulation

The th.sxstatus CSR can be used to identify available custom extension
on T-Head CPUs. The CSR is documented here:
  
https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsxstatus.adoc

An important property of this patch is, that the th.sxstatus MAEE field
is not set (indicating that XTheadMae is not available).
XTheadMae is a memory attribute extension (similar to Svpbmt) which is
implemented in many T-Head CPUs (C906, C910, etc.) and utilizes bits
in PTEs that are marked as reserved. QEMU maintainers prefer to not
implement XTheadMae, so we need give kernels a mechanism to identify
if XTheadMae is available in a system or not. And this patch introduces
this mechanism in QEMU in a way that's compatible with real HW
(i.e., probing the th.sxstatus.MAEE bit).

Further context can be found on the list:
https://lists.gnu.org/archive/html/qemu-devel/2024-02/msg00775.html

Reviewed-by: LIU Zhiwei <zhiwe_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Message-ID: <20240429073656.2486732-1-christoph.muellner@vrull.eu>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 1210f05a3932b80c29ea9db9fa852d86b4fce4af
      
https://github.com/qemu/qemu/commit/1210f05a3932b80c29ea9db9fa852d86b4fce4af
  Author: Max Chou <max.chou@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc

  Log Message:
  -----------
  target/riscv: rvv: Fix Zvfhmin checking for vfwcvt.f.f.v and vfncvt.f.f.w 
instructions

According v spec 18.4, only the vfwcvt.f.f.v and vfncvt.f.f.w
instructions will be affected by Zvfhmin extension.
And the vfwcvt.f.f.v and vfncvt.f.f.w instructions only support the
conversions of

* From 1*SEW(16/32) to 2*SEW(32/64)
* From 2*SEW(32/64) to 1*SEW(16/32)

Signed-off-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240322092600.1198921-2-max.chou@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 39a01fe2f410d893d10cceca4535c6f59c71d5ad
      
https://github.com/qemu/qemu/commit/39a01fe2f410d893d10cceca4535c6f59c71d5ad
  Author: Max Chou <max.chou@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc

  Log Message:
  -----------
  target/riscv: rvv: Check single width operator for vector fp widen 
instructions

The require_scale_rvf function only checks the double width operator for
the vector floating point widen instructions, so most of the widen
checking functions need to add require_rvf for single width operator.

The vfwcvt.f.x.v and vfwcvt.f.xu.v instructions convert single width
integer to double width float, so the opfxv_widen_check function doesn’t
need require_rvf for the single width operator(integer).

Signed-off-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240322092600.1198921-3-max.chou@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: a4b70a80c8bfa5bd1594c8bd605c94b08702623a
      
https://github.com/qemu/qemu/commit/a4b70a80c8bfa5bd1594c8bd605c94b08702623a
  Author: Max Chou <max.chou@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc

  Log Message:
  -----------
  target/riscv: rvv: Check single width operator for vfncvt.rod.f.f.w

The opfv_narrow_check needs to check the single width float operator by
require_rvf.

Signed-off-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240322092600.1198921-4-max.chou@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 3d35a104330f6674cce3c2903d49f77eeebb6fbd
      
https://github.com/qemu/qemu/commit/3d35a104330f6674cce3c2903d49f77eeebb6fbd
  Author: Max Chou <max.chou@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc

  Log Message:
  -----------
  target/riscv: rvv: Remove redudant SEW checking for vector fp narrow/widen 
instructions

If the checking functions check both the single and double width
operators at the same time, then the single width operator checking
functions (require_rvf[min]) will check whether the SEW is 8.

Signed-off-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240322092600.1198921-5-max.chou@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 87293ed1ab54ac0ff4e2512d0985cb56e552d660
      
https://github.com/qemu/qemu/commit/87293ed1ab54ac0ff4e2512d0985cb56e552d660
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu_helper.c

  Log Message:
  -----------
  target/riscv: prioritize pmp errors in raise_mmu_exception()

raise_mmu_exception(), as is today, is prioritizing guest page faults by
checking first if virt_enabled && !first_stage, and then considering the
regular inst/load/store faults.

There's no mention in the spec about guest page fault being a higher
priority that PMP faults. In fact, privileged spec section 3.7.1 says:

"Attempting to fetch an instruction from a PMP region that does not have
execute permissions raises an instruction access-fault exception.
Attempting to execute a load or load-reserved instruction which accesses
a physical address within a PMP region without read permissions raises a
load access-fault exception. Attempting to execute a store,
store-conditional, or AMO instruction which accesses a physical address
within a PMP region without write permissions raises a store
access-fault exception."

So, in fact, we're doing it wrong - PMP faults should always be thrown,
regardless of also being a first or second stage fault.

The way riscv_cpu_tlb_fill() and get_physical_address() work is
adequate: a TRANSLATE_PMP_FAIL error is immediately reported and
reflected in the 'pmp_violation' flag. What we need is to change
raise_mmu_exception() to prioritize it.

Reported-by: Joseph Chan <jchan@ventanamicro.com>
Fixes: 82d53adfbb ("target/riscv/cpu_helper.c: Invalid exception on MMU 
translation stage")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240413105929.7030-1-alexei.filippov@syntacore.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 2b0a62d4c60992ae14ea20fd0450e4760548b48b
      
https://github.com/qemu/qemu/commit/2b0a62d4c60992ae14ea20fd0450e4760548b48b
  Author: Alexei Filippov <alexei.filippov@syntacore.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu_helper.c

  Log Message:
  -----------
  target/riscv: do not set mtval2 for non guest-page faults

Previous patch fixed the PMP priority in raise_mmu_exception() but we're still
setting mtval2 incorrectly. In riscv_cpu_tlb_fill(), after pmp check in 2 stage
translation part, mtval2 will be set in case of successes 2 stage translation 
but
failed pmp check.

In this case we gonna set mtval2 via env->guest_phys_fault_addr in context of
riscv_cpu_tlb_fill(), as this was a guest-page-fault, but it didn't and mtval2
should be zero, according to RISCV privileged spec sect. 9.4.4: When a guest
page-fault is taken into M-mode, mtval2 is written with either zero or guest
physical address that faulted, shifted by 2 bits. *For other traps, mtval2
is set to zero...*

Signed-off-by: Alexei Filippov <alexei.filippov@syntacore.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240503103052.6819-1-alexei.filippov@syntacore.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 916bb28bd77643b6fd8eb6938b95836813ce428f
      
https://github.com/qemu/qemu/commit/916bb28bd77643b6fd8eb6938b95836813ce428f
  Author: Rob Bradford <rbradford@rivosinc.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.c
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: Remove experimental prefix from "B" extension

This extension has now been ratified:
https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be
removed.

Since this is now a ratified extension add it to the list of extensions
included in the "max" CPU variant.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Message-ID: <20240514110217.22516-1-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 7b38c7e570c5a5abeb8ab2c5156fe3ef93018525
      
https://github.com/qemu/qemu/commit/7b38c7e570c5a5abeb8ab2c5156fe3ef93018525
  Author: Alistair Francis <alistair23@gmail.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvzicbo.c.inc

  Log Message:
  -----------
  target/riscv: rvzicbo: Fixup CBO extension register calculation

When running the instruction

```
    cbo.flush 0(x0)
```

QEMU would segfault.

The issue was in cpu_gpr[a->rs1] as QEMU does not have cpu_gpr[0]
allocated.

In order to fix this let's use the existing get_address()
helper. This also has the benefit of performing pointer mask
calculations on the address specified in rs1.

The pointer masking specificiation specifically states:

"""
Cache Management Operations: All instructions in Zicbom, Zicbop and Zicboz
"""

So this is the correct behaviour and we previously have been incorrectly
not masking the address.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reported-by: Fabian Thomas <fabian.thomas@cispa.de>
Fixes: e05da09b7cfd ("target/riscv: implement Zicbom extension")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240514023910.301766-1-alistair.francis@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 04257ebb480ff3547a08437567c8c7c2daa1ee08
      
https://github.com/qemu/qemu/commit/04257ebb480ff3547a08437567c8c7c2daa1ee08
  Author: Yong-Xuan Wang <yongxuan.wang@sifive.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/kvm/kvm-cpu.c

  Log Message:
  -----------
  target/riscv/kvm.c: Fix the hart bit setting of AIA

In AIA spec, each hart (or each hart within a group) has a unique hart
number to locate the memory pages of interrupt files in the address
space. The number of bits required to represent any hart number is equal
to ceil(log2(hmax + 1)), where hmax is the largest hart number among
groups.

However, if the largest hart number among groups is a power of 2, QEMU
will pass an inaccurate hart-index-bit setting to Linux. For example, when
the guest OS has 4 harts, only ceil(log2(3 + 1)) = 2 bits are sufficient
to represent 4 harts, but we passes 3 to Linux. The code needs to be
updated to ensure accurate hart-index-bit settings.

Additionally, a Linux patch[1] is necessary to correctly recover the hart
index when the guest OS has only 1 hart, where the hart-index-bit is 0.

[1] 
https://lore.kernel.org/lkml/20240415064905.25184-1-yongxuan.wang@sifive.com/t/

Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240515091129.28116-1-yongxuan.wang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: e533b287fc6a8a45973904137b58f7a16d343f16
      
https://github.com/qemu/qemu/commit/e533b287fc6a8a45973904137b58f7a16d343f16
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/gdbstub.c

  Log Message:
  -----------
  riscv, gdbstub.c: fix reg_width in ricsv_gen_dynamic_vector_feature()

Commit 33a24910ae changed 'reg_width' to use 'vlenb', i.e. vector length
in bytes, when in this context we want 'reg_width' as the length in
bits.

Fix 'reg_width' back to the value in bits like 7cb59921c05a
("target/riscv/gdbstub.c: use 'vlenb' instead of shifting 'vlen'") set
beforehand.

While we're at it, rename 'reg_width' to 'bitsize' to provide a bit more
clarity about what the variable represents. 'bitsize' is also used in
riscv_gen_dynamic_csr_feature() with the same purpose, i.e. as an input to
gdb_feature_builder_append_reg().

Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Alex Bennée <alex.bennee@linaro.org>
Reported-by: Robin Dapp <rdapp.gcc@gmail.com>
Fixes: 33a24910ae ("target/riscv: Use GDBFeature for dynamic XML")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240517203054.880861-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 1cb61b085682b294b9f47f2a30512561e237915e
      
https://github.com/qemu/qemu/commit/1cb61b085682b294b9f47f2a30512561e237915e
  Author: Alistair Francis <alistair23@gmail.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M disas/riscv.c

  Log Message:
  -----------
  disas/riscv: Decode all of the pmpcfg and pmpaddr CSRs

Previously we only listed a single pmpcfg CSR and the first 16 pmpaddr
CSRs. This patch fixes this to list all 16 pmpcfg and all 64 pmpaddr
CSRs are part of the disassembly.

Reported-by: Eric DeVolder <eric_devolder@yahoo.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Fixes: ea10325917 ("RISC-V Disassembler")
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Message-ID: <20240514051615.330979-1-alistair.francis@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 1806da76cb81088ea026ca3441551782b850e393
      
https://github.com/qemu/qemu/commit/1806da76cb81088ea026ca3441551782b850e393
  Author: Yu-Ming Chang <yumin686@andestech.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M target/riscv/cpu.h
    M target/riscv/csr.c
    M target/riscv/op_helper.c

  Log Message:
  -----------
  target/riscv: raise an exception when CSRRS/CSRRC writes a read-only CSR

Both CSRRS and CSRRC always read the addressed CSR and cause any read side
effects regardless of rs1 and rd fields. Note that if rs1 specifies a register
holding a zero value other than x0, the instruction will still attempt to write
the unmodified value back to the CSR and will cause any attendant side effects.

So if CSRRS or CSRRC tries to write a read-only CSR with rs1 which specifies
a register holding a zero value, an illegal instruction exception should be
raised.

Signed-off-by: Yu-Ming Chang <yumin686@andestech.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240403070823.80897-1-yumin686@andestech.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


  Commit: 34f79c354352419ac80a0076ce06826c28082838
      
https://github.com/qemu/qemu/commit/34f79c354352419ac80a0076ce06826c28082838
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-05-27 (Mon, 27 May 2024)

  Changed paths:
    M MAINTAINERS
    M disas/riscv.c
    M hw/intc/riscv_aplic.c
    M hw/riscv/boot.c
    M target/riscv/cpu.c
    M target/riscv/cpu.h
    M target/riscv/cpu_bits.h
    M target/riscv/cpu_cfg.h
    M target/riscv/cpu_helper.c
    M target/riscv/csr.c
    M target/riscv/debug.c
    M target/riscv/gdbstub.c
    M target/riscv/helper.h
    M target/riscv/insn_trans/trans_privileged.c.inc
    M target/riscv/insn_trans/trans_rvv.c.inc
    M target/riscv/insn_trans/trans_rvzawrs.c.inc
    M target/riscv/insn_trans/trans_rvzicbo.c.inc
    M target/riscv/kvm/kvm-cpu.c
    M target/riscv/meson.build
    M target/riscv/op_helper.c
    M target/riscv/sbi_ecall_interface.h
    M target/riscv/tcg/tcg-cpu.c
    M target/riscv/tcg/tcg-cpu.h
    A target/riscv/th_csr.c
    M target/riscv/translate.c
    M target/riscv/vector_internals.c

  Log Message:
  -----------
  Merge tag 'pull-riscv-to-apply-20240528' of 
https://github.com/alistair23/qemu into staging

RISC-V PR for 9.1

* APLICs add child earlier than realize
* Fix exposure of Zkr
* Raise exceptions on wrs.nto
* Implement SBI debug console (DBCN) calls for KVM
* Support 64-bit addresses for initrd
* Change RISCV_EXCP_SEMIHOST exception number to 63
* Tolerate KVM disable ext errors
* Set tval in breakpoints
* Add support for Zve32x extension
* Add support for Zve64x extension
* Relax vector register check in RISCV gdbstub
* Fix the element agnostic Vector function problem
* Fix Zvkb extension config
* Implement dynamic establishment of custom decoder
* Add th.sxstatus CSR emulation
* Fix Zvfhmin checking for vfwcvt.f.f.v and vfncvt.f.f.w instructions
* Check single width operator for vector fp widen instructions
* Check single width operator for vfncvt.rod.f.f.w
* Remove redudant SEW checking for vector fp narrow/widen instructions
* Prioritize pmp errors in raise_mmu_exception()
* Do not set mtval2 for non guest-page faults
* Remove experimental prefix from "B" extension
* Fixup CBO extension register calculation
* Fix the hart bit setting of AIA
* Fix reg_width in ricsv_gen_dynamic_vector_feature()
* Decode all of the pmpcfg and pmpaddr CSRs
* Raise an exception when CSRRS/CSRRC writes a read-only CSR

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmZVRIwACgkQr3yVEwxT
# gBMzCQ/+JsOx7+1Zlk3DjX6Q0lzdBuW/ruoIO3DcMw1Y9THR935rCeSk6NARzq2W
# oOeSz+EM0C2Q0MXX6nX0LdVtp7gQ1pjKcOFAwGDX00c4XtpVtjFl2jD0DMufY1f2
# sZ6Khyd9m1YPVYSmJXntNGpVi/53TZC54HKu+V1vpjPojYuIi9fkfYiA2If+H64+
# xXtLYxXdarHJyTBPnH/hadcHIgIr+TMjkevwSazvf+Ta6j5sx9kTh0iHaYLXx8w+
# VwPMPCE5oqJjJgMS1ZzRxpt+VXRJL6esq8OzkLxHnsXHC7AlcZBeI9JAhEo0CLgq
# KoiYpyPwBONFvQr5g0diIu9uGN3GSu1BqUt/BdgakkusHE3RdaSRtoD8zTIB0sih
# e0i6C+2ltwNtt1whmkFr2hTho0MCDGq4ZTYVN+z60w8AN41hO1M9GU4YjQ3LYByZ
# Nfb8gjgMLLXEGARa2DhcBIXUpHfEmcl/iW1gxn44CrF6oMPFRXvDpEVc+ZCXx8SF
# dyNaxDVU2snvHE/Sx9w2efFLag4Z/d5Km/XZrzOZtzj2q5EXw8u1byj9Nq6F1eAu
# +yoPHOWJM7z0NYf5emTx9StOUAHr/XTunNANgRhpt0HwgeAkgh8pLTwQgj8POzMG
# DLcVHtX8ip0UYIoeEZSK6Js42qgpz30Rfp/s79avm0mGAoC6u0E=
# =4InK
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 27 May 2024 07:42:20 PM PDT
# gpg:                using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65  9296 AF7C 9513 0C53 8013

* tag 'pull-riscv-to-apply-20240528' of https://github.com/alistair23/qemu: (28 
commits)
  target/riscv: raise an exception when CSRRS/CSRRC writes a read-only CSR
  disas/riscv: Decode all of the pmpcfg and pmpaddr CSRs
  riscv, gdbstub.c: fix reg_width in ricsv_gen_dynamic_vector_feature()
  target/riscv/kvm.c: Fix the hart bit setting of AIA
  target/riscv: rvzicbo: Fixup CBO extension register calculation
  target/riscv: Remove experimental prefix from "B" extension
  target/riscv: do not set mtval2 for non guest-page faults
  target/riscv: prioritize pmp errors in raise_mmu_exception()
  target/riscv: rvv: Remove redudant SEW checking for vector fp narrow/widen 
instructions
  target/riscv: rvv: Check single width operator for vfncvt.rod.f.f.w
  target/riscv: rvv: Check single width operator for vector fp widen 
instructions
  target/riscv: rvv: Fix Zvfhmin checking for vfwcvt.f.f.v and vfncvt.f.f.w 
instructions
  riscv: thead: Add th.sxstatus CSR emulation
  target/riscv: Implement dynamic establishment of custom decoder
  target/riscv/cpu.c: fix Zvkb extension config
  target/riscv: Fix the element agnostic function problem
  target/riscv: Relax vector register check in RISCV gdbstub
  target/riscv: Add support for Zve64x extension
  target/riscv: Add support for Zve32x extension
  trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint
  ...

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/ad10b4badc1d...34f79c354352

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications



reply via email to

[Prev in Thread] Current Thread [Next in Thread]