..rather than unbounded, as it used to be. This led to the rather
surprising issue #1600, where a part of the address space assumed to be
vacant would allow a subset of accesses.
The H extension defines that bits VSEIP, VSTIP, and VSSIP of hvip are
writable. (The other bits of hvip are read-only 0.) Only hip.VSSIP
(mip.VSSIP) is an alias of hvip.VSSIP. The hip.VSEIP is the logical-OR
of hvip.VSEIP, selected bit of hgeip by hstatus.VGEIN, and
platform-specific external interrupt signals to VS-level, e.g., from
AIA. The hip.VSTIP is the logical-OR of hvip.VSTIP and platform-specific
timer interrupt signals to VS-level, e.g., from Sstc. Thus, the read
values of hvip.VSEIP and hvip.VSTIP differ from the ones of hip.VSEIP
and hip.VSTIP (mip.VSEIP and mip.VSTIP). In other words, the hvip isn't
an alias (proxy) of mip.
The current aliasing (proxy) implementation does not provide the desired
behavior for hvip.VSEIP and hvip.VSTIP. An ISA-level behavior difference
is that any platform-specific external and timer interrupt signals
directed to VS-level should not be observable through the hvip. For
instance, the hvip should not observe the virtual timer interrupt signal
from the vstimecmp CSR (Sstc extension), which isn't true in the current
implementation. Additionally, the hvip should not observe the virtual
external interrupt signal from the IMSIC device (AIA extension).
Another ISA-level behavior difference is that the hgeip and
hstatus.VGEIN also should not affect hvip.VSEIP, which isn't true in the
current implementation.
This commit fixes the issue by giving the hvip a specialized class,
hvip_csr_t. The hvip_csr_t aliases the hvip.VSSIP to the mip.VSSIP but
decouples the hvip.VSEIP and hvip.VSTIP from mip.VSEIP and mip.VSTIP.
Additionally, the commit updates the read value of mip to be the
logical-OR of hvip.VSEIP, hvip.VSTIP, and other sources.
When menvcfg.STCE=0, mip.STIP reverts to its defined behavior as if
unsupporting Sstc extension. When henvcfg.STCE=0, mip.VSTIP reverts
to its defined behavior as if unsupporting Sstc extension. [https://github.com/riscv/riscv-time-compare/issues/5]
The previous Sstc implementation does not respect the xenvcfg.STCE.
In other words, the Sstc may assert mip.STIP (mip.VSTIP) when
menvcfg.STCE=0 (henvcfg.STCE=0), which is a misbehaving.
The number of triggers is configurable since https://github.com/riscv-software-src/riscv-isa-sim/pull/1219.
The trigger description was for the limited implementation when developing the extension. All trigger types are supported now. The information isn't very useful anymore.
Signed-off-by: YenHaoChen <39526191+YenHaoChen@users.noreply.github.com>
According to Subset Naming Convention section of ISA Manual Volume I,
H extension should be after V extension in ISA string.
Signed-off-by: demin.han <demin.han@starfivetech.com>
We want to evaluate whether the product of a and b is zero mod 2^64,
but the product might overflow, resulting in UB. If we instead perform
the computation in unsigned arithmetic, the overflow behavior is defined.
Resolves#1538
The configure generated by Ubuntu22's upstream autoconf (2.71) is broken.
DEFAULT_VARCH was expanded incorrectly, causing the generated line to be truncated from the comma.
Since this macro is a constant and doesn't depend on environment variables, it doesn't require shell expansion.
cpu-map node may be present in cpus node.
124e46a865
So this commit adds logic to consider that by skipping cpu-map node.
Signed-off-by: Tan En De <ende.tan@starfivetech.com>
Andrew Waterman
liangsen
YenHaoChen
YenHaoChen
rbuchner
Tilmann Bartsch
Hong Cheng
Jerry Zhao
Scott Johnson
demin.han
Ved Shanbhogue
Ved Shanbhogue
phantom1003
Tan En De