Note: lists.riscv.org will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
Allen Baum wrote:
When mip is *read* with a CSR instruction, the *value* of the SEIP bitThe interpretation is supposed to be the second one.
Normally, I would expect to execute CSRRC to clear the existing pendingActually, no, for two reasons:
First, supervisor-level interrupts are normally handled in S mode, and
bit SEIP isn't writable in sip. And obviously S mode can't touch mip.
So, a supervisor-level OS can't clear the pending interrupt by clearing
sip.SEIP; it doesn't have that ability.
Second, for M mode, the incoming external interrupt for SEIP is not
affected by a write to mip, only the software-writable bit is. So,
only the software-writable interrupt could possibly be "lost" this way,
not the externally sourced interrupt. I put _lost_ in quotation marks
because the only reason to write to clear mip.SEIP is to intentionally
clear the software-writable bit. If that's the intention, then the
"loss" of that interrupt isn't an accident.
I think the wording here needs to be updated to remove any possibleI won't disagree.
- John Hauser