Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix hvip.VSEIP and hvip.VSTIP so they don't observe platform-specific interrupts #1590

Merged
merged 1 commit into from
Feb 7, 2024

Conversation

YenHaoChen
Copy link
Collaborator

@YenHaoChen YenHaoChen commented Feb 2, 2024

The H extension defines that bit VSEIP, VSTIP, and VSSIP of hvip are writable. (The other bits of hvip are read-only 0.) Only the VSSIP of hip (mip) is an alias of the same bit of hvip. The VSEIP and VSTIP of hip are the logical-OR of ones of hvip and other sources.

The current aliasing (proxy) implementation does not provide the desired behavior. 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 Sstc extension (vstimecmp CSR), 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 and hvip.VSTIP and other sources.

image
image

@YenHaoChen YenHaoChen force-pushed the pr-hvip branch 5 times, most recently from 2d01070 to 1a9d394 Compare February 2, 2024 08:58
@YenHaoChen
Copy link
Collaborator Author

YenHaoChen commented Feb 2, 2024

Need help on the CI issue. I can compile the code on my computer.

Copy link
Contributor

@scottj97 scottj97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change the commit message (and PR title) to indicate what is changing. It's not clear from the message if hvip is supposed to be an alias of mip or not.

The latest commit 5927541 is core dumping on every test I attempt. (1bdc833 was not doing this.)

riscv/csrs.cc Outdated Show resolved Hide resolved
riscv/csrs.cc Outdated Show resolved Hide resolved
@YenHaoChen YenHaoChen force-pushed the pr-hvip branch 2 times, most recently from 2f544c0 to 63bd8d8 Compare February 5, 2024 02:02
@YenHaoChen
Copy link
Collaborator Author

Update the title and commit message to clarify that the hvip isn't an alias of mip.

@YenHaoChen YenHaoChen requested a review from scottj97 February 5, 2024 02:04
Copy link
Contributor

@scottj97 scottj97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me explain what I'm asking for w.r.t. the commit message and PR title.

The old message of "hvip isn't an alias..." describes a fact. Is this is a true or false fact? Is hvip supposed to be an alias? Is it a problem if it is an alias? Or is it a problem if it's not an alias? Was it an alias in the old code? Does this commit change that, so it's not an alias anymore? Or maybe it wasn't an alias and needs to be, so this commit makes it an alias? None of those important questions are answered by that commit title.

Even the new phrasing of "shouldn't" describes a problem, not a change. Okay, I accept that it shouldn't be an alias. So what? What does this commit have to do with that? Does this change it so it's not an alias anymore? I don't know. This is a good title for an issue report, but not a pull request or commit message.

The commit message should include a verb explaining what is changing. How about:

Fix hvip.VSEIP and hvip.VSTIP so they don't observe platform-specific interrupts

Followed by all the rest of the explanation from 63bd8d8

…c interrupts or CSR hgeip bits

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.
@scottj97 scottj97 changed the title hvip isn't an alias (proxy) of mip Fix hvip.VSEIP and hvip.VSTIP so they don't observe platform-specific interrupts Feb 7, 2024
@aswaterman aswaterman merged commit d4726e1 into riscv-software-src:master Feb 7, 2024
3 checks passed
@YenHaoChen YenHaoChen deleted the pr-hvip branch March 28, 2024 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants