devices: rtc_pl031: Disable broken interrupt #7199
Merged
Conversation
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
likebreath
reviewed
Jul 16, 2025
Member
likebreath
left a comment
likebreath
left a comment
There was a problem hiding this comment.
@jpbrucker Thank you for reporting and fixing this bug. It appears to me that the IMSC register is only used for interrupts too. Why we don't remove imsc related code too? Any considerations?
Can you please also share some kernel logs from the guest showing the spurious interrupts? It might be helpful for the community to search when looking for similar issues.
Contributor
Author
|
Sure I can remove the local storage of IMSC as well. It's the interrupt mask, where the guest writes 1 to enable the interrupt. So removing the variable and tying it to 0 does seem more accurate since we don't support the interrupt. The warning we get when Linux disables the interrupt after initially hanging in the interrupt handler is: |
The PL031 RTC provides two features: a real-time counter and an alarm interrupt. To use the alarm, the driver normally writes a time value into the match register RTCMR, and when the counter reaches that value the device triggers the interrupt. At the moment the implementation ignores programming of the alarm, as the feature seems rarely used in VMs. However the interrupt is still triggered arbitrarily when the guest writes to registers, and the line is never cleared. This really confuses the Linux driver, which loops in the interrupt handler until Linux realizes that no one is dealing with the interrupt (200000 unanswered calls) and disables the handler. One way to fix this would be implementing the alarm function properly, which isn't too difficult but requires adding some async timer logic which probably won't ever get used. In addition the device's interrupt is level-triggered and we don't support level interrupts at the moment, though we could probably get away with changing this interrupt to edge. The simplest fix, though, is to just disable the interrupt logic entirely, so that the alarm function still doesn't work but the guest doesn't see spurious interrupts. Add a default() implementation to satisfy clippy's new_without_default check, since Rtc::new() doesn't take a parameter after this change. Signed-off-by: Jean-Philippe Brucker <[email protected]>
likebreath
approved these changes
Jul 17, 2025
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in Cloud Hypervisor Roadmap
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The PL031 RTC provides two features: a real-time counter and an alarm interrupt. To use the alarm, the driver normally writes a time value into the match register RTCMR, and when the counter reaches that value the device triggers the interrupt.
At the moment the implementation ignores programming of the alarm, as the feature seems rarely used in VMs. However the interrupt is still triggered arbitrarily when the guest writes to registers, and the line is never cleared. This really confuses the Linux driver, which loops in the interrupt handler until Linux realizes that no one is dealing with the interrupt (200000 unanswered calls) and disables the handler.
One way to fix this would be implementing the alarm function properly, which isn't too difficult but requires adding some async timer logic which probably won't ever get used. In addition the device's interrupt is level-triggered and we don't support level interrupts at the moment, though we could probably get away with changing this interrupt to edge.
The simplest fix, though, is to just disable the interrupt logic entirely, so that the alarm function still doesn't work but the guest doesn't see spurious interrupts.