Open
Conversation
be6d849 to
89b61e6
Compare
Signed-off-by: Jose Martins <josemartins90@gmail.com>
89b61e6 to
2b296f4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR refactors APLIC MSI injection in IMSIC guest interrupt files and fixes two issues:
The previous implementation assumed that MSI injection into a guest interrupt file always targeted the local vCPU. If the target vCPU was remote, it sent a CPU message to the target core so the MSI could be injected locally. However, the IMSIC MMIO interface allows a CPU to inject an MSI directly into a remote (i.e., different core) guest IMSIC via its MMIO interface. Supporting this requires:
Alternatively, local vCPU injection could still use the AIA CSRs (as before). To simplify the code, this optimization is intentionally avoided for now. Future work may evaluate whether MMIO-based injection is sufficiently costly to justify reintroducing this optimization.
On updates to APLIC registers, the previous implementation iterated over all APLIC interrupts to determine whether an MSI should be forwarded to a vCPU. In most cases (e.g., enabling a single interrupt), only one interrupt needs to be considered. This PR addresses the issue by adding a third argument to
vaplic_update_hart, indicating whether the call was triggered by a single interrupt state update. If the interrupt ID is invalid (e.g., when triggered by a global vAPLIC control update), the logic falls back to scanning all interrupts for forwarding.