Bus-error clarification

[oolegoon]

The privileged specification states that:

Precise PMA traps might not always be possible, for example, when probing a legacy bus architecture that uses access failures as part of the discovery mechanism. In this case, error responses from peripheral devices will be reported as imprecise bus-error interrupts.

I have several questions about that:

1. Do I understand correctly that in the case of a bus error no synchronous exception will be generated, but an asynchronous interrupt?
2. If so, how could this discovery mechanism (probing) be implemented in software? What should software do in this case? Should it wait for an interrupt or poll something?
3. We have profiles specs (RVA22/23) with the goal to align processor vendors targeting binary software markets, so software can rely on the existence of a certain set of ISA features in a particular generation of RISC-V implementations.
   How does bus-error relate to the profile? Shouldn't it be described in the profile, because now it is vendor-specific. In a comment (Is it appropriate to specify an exception vs interrupt priority? #544 (comment)) @aswaterman indicated that this issue would be addressed to the RVI TG for standardization. Is there any progress on this TG?
4. In a comment (Is it appropriate to specify an exception vs interrupt priority? #544 (comment)) @allenjbaum states (and the similar behavior is described in some other sources) that the bus error is handled as an asynchronous interrupt, since after accessing memory, high-performance implementations execute subsequent instructions. Executing subsequent instructions means changing the PC and retirement of the instruction that performed the access?

[allenjbaum]

I've been think about this a lot lately, so these are my "opinions", not RV sanctioned answers: 1. yes, that can be the case (but some implementations could make it synchronous, and some profiles might require it) 2. either of those two methods would work, but you have the right idea. That case is a bit unusual in that an interrupt is known to be (one of) the expected behaviors. Often, this particular case ends with a timeout interrupt, not necessarily a buserr (my understanding of PCIE enumeration). 3. I am unclear which TG would (or have) address(ed) this. A software error exception has been defined (cause 0x12), but I think the use case was primarily intended for security violations (e.g. control flow integrity/landing pad violations). I don't know how its reporting requirements fit with the buserr case or not (it is likely fatal, so it may not matter) 4. My opinion is that this is implementation defined. This depends on the type of what is being accessed (memory vs. posted IO vs. non-posted IO), among other implementation details. The case that concerns me is IO device access, where (say) 4K of address space is set aside for an IO device (e.g. a UART) but only a small address range within that is implemented, and all the rest get address decoding errors. For this discussion, we should probably - carefully define the terms [im]precise and [a]synchronous, - what distinguishes an interrupt from an exception based on those terms (and others) - how buserrs *may* be handled

…

On Thu, Nov 14, 2024 at 3:37 AM oolegoon ***@***.***> wrote: The privileged specification states that: Precise PMA traps might not always be possible, for example, when probing a legacy bus architecture that uses access failures as part of the discovery mechanism. In this case, error responses from peripheral devices will be reported as imprecise bus-error interrupts. I have several questions about that: 1. Do I understand correctly that in the case of a bus error no synchronous exception will be generated, but an asynchronous interrupt? 2. If so, how could this discovery mechanism (probing) be implemented in software? What should software do in this case? Should it wait for an interrupt or poll something? 3. We have profiles specs (RVA22/23) with *the goal to align processor vendors targeting binary software markets, so software can rely on the existence of a certain set of ISA features in a particular generation of RISC-V implementations.* How does bus-error relate to the profile? Shouldn't it be described in the profile, because now it is vendor-specific. In a comment (#544 (comment) <#544 (comment)>) @aswaterman <https://github.com/aswaterman> indicated that this issue would be addressed to the RVI TG for standardization. Is there any progress on this TG? 4. In a comment (#544 (comment) <#544 (comment)>) @allenjbaum <https://github.com/allenjbaum> states (and the similar behavior is described in some other sources) that the bus error is handled as an asynchronous interrupt, since after accessing memory, high-performance implementations execute subsequent instructions. Executing subsequent instructions means changing the PC and retirement of the instruction that performed the access? — Reply to this email directly, view it on GitHub <#1725>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJR6UTMAWALKFSI46ET2ASDO7AVCNFSM6AAAAABRYWACWKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY2TQNJVGYYTENI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aswaterman]

Agreed with Allen overall. I'd just add that the standardization of these events is within the domain of RAS/RERI.