Re: csrrc/csrrs with mip, sip and uip


John Hauser
 

Allen Baum wrote:
When mip is *read* with a CSR instruction, the *value* of the SEIP bit
returned in the rd destination register is the logical-OR of the
software-writable bit and the interrupt signal from the interrupt
controller. However, the *value* *used* in the read-modify-write sequence
of a CSRRS or CSRRC instruction contains only the software-writable SEIP
bit, ignoring the interrupt value from the external interrupt controller.
If you interpret "value used" as the value read and returned in Rd, then
the value read does differ.
If you interpret "value used" as the value written into the
software-writable bit, then it doesn't.
The problem here is how to interpret "used", and I interpreted is as it was
used (sorry) in the previous sentence.
The interpretation is supposed to be the second one.

Normally, I would expect to execute CSRRC to clear the existing pending
bit, but to OR in any incoming interrupt into the SW writeable bit order
not to lose it.
Your interpretation can cause an incoming interrupt to be lost.
Actually, 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 possible
ambiguity.
I won't disagree.

- John Hauser

Join tech-privileged@lists.riscv.org to automatically receive all group messages.