Updated arch_test.h interrupt handler defaults

[SadhviNarayanan]

Updated arch_test.h interrupt handler defaults, for example mapped RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT to RVMODEL_CLR_SSW_INT instead of the default trap handler, if the individual flavors are not explicitly defined.

[allenjbaum]

Why was the M/U mode table removed? The intent of the trap handler is to deal with any hart configuration, and that includes models that don't have Smode. A lot of these changes seem unnecessary, e.g. the original names of the form Why is there a difference between an Mmode macro for an Smode handler, vs just using the Smode macro even if you're in Mmode? Mmode is capable of executing anything that Smode can do. I'm not sure who made those changes I'm also not sure why the default was replaced with an empty macro (which is what the sequence #ifndef X; #define X X does). If you want that behavior, then just leave it the way it was and add #ifndef RVTEST_DFLT_INT_HNDLR #define RVTEST_DFLT_INT_HNDLR \There might be an explanation for all this, but I'd like to see it documented as comments in the code.

…

On Wed, Jan 7, 2026 at 10:50 PM Sadhvi Narayanan ***@***.***> wrote: Updated arch_test.h interrupt handler defaults, for example mapped RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT to RVMODEL_CLR_SSW_INT instead of the default trap handler, if the individual flavors are not explicitly defined. ------------------------------ You can view, comment on, or merge this pull request online at: #837 Commit Summary - ca171f0 <ca171f0> updated arch_test.h interrupt handler - 21c8808 <21c8808> Merge branch 'act4' into trap_handler File Changes (1 file <https://github.com/riscv-non-isa/riscv-arch-test/pull/837/files>) - *M* tests/env/arch_test.h <https://github.com/riscv-non-isa/riscv-arch-test/pull/837/files#diff-1f210ab4fafbfd1d21452c2ea5d9b667178961234d1cbca247074ffefaee4245> (31) Patch Links: - https://github.com/riscv-non-isa/riscv-arch-test/pull/837.patch - https://github.com/riscv-non-isa/riscv-arch-test/pull/837.diff — Reply to this email directly, view it on GitHub <#837>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQ6DV7C4AE77ZB4W6T4FX44HAVCNFSM6AAAAACRA5IFKSVHI2DSMVQWIX3LMV43ASLTON2WKOZTG44TCNJZGY3DMNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jordancarlin]

Why was the M/U mode table removed? The intent of the trap handler is to deal with any hart configuration, and that includes models that don't have Smode.

We ran into an issue when an M-mode interrupt test attempts to write to the supervisor interrupt pending bits of mip (mip.SEIP for example). If S-mode is not supported, mip.SEIP is read-only zero. If S-mode is supported, the interrupt is taken (assuming mideleg is cleared). Writing to the mip.SEIP bit needs to be tested either way. This is an M-mode only test and does not instantiate the supervisor trap handler because it will be run on cores that do not support S-mode, but if the core it is running on does support S-mode, then the machine trap handler needs a way to clear the interrupt. If S-mode is not supported, supervisor interrupts will never be taken and this part of the trap vector table will never be exercised, so it shouldn't matter if the table is fully populated even without S-mode.

A lot of these changes seem unnecessary, e.g. the original names of the form. Why is there a difference between an Mmode macro for an Smode handler, vs just using the Smode macro even if you're in Mmode? Mmode is capable of executing anything that Smode can do. I'm not sure who made those changes

It's unclear to us as well why there are two variants of the S-mode interrupt macros. That's what @davidharrishmc was asking in a recent email. If no-one can think of a good reason to have multiple versions of the interrupt macros, we'd prefer to drop the RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT macros and just use a RVMODEL_CLR_SSW_INT macro when in both priv modes.

I'm also not sure why the default was replaced with an empty macro (which is what the sequence #ifndef X; #define X X does). If you want that behavior, then just leave it the way it was and add #ifndef RVTEST_DFLT_INT_HNDLR #define RVTEST_DFLT_INT_HNDLR

That's not what this PR is doing. The priv mode specific variants of the macros (eg RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT) are being defined to use the mode-agnostic RVMODEL_CLR_SSW_INT macro if the priv mode specific variants are not defined.

[allenjbaum]

ISorry no making sense. IF there is no Smode, then writing it will have no effect as the bit will be RdOnly 0. IF there is an Smode, then there will be a trap IFF interrupts are enabled. So, if all you're trying to do is see if SEIP is RdOnly zero, disable interrupts before, or "attempt" to clear SSIE before writing SEIP in MU systems, and have a different test written for MSU ... but don't remove support for what will become an actually usable configuration. But, if there is no Smode, it can't be delegated, so not having an Smode handler is irrelevant. My motto: if it hurts when you do that, don't do that. Note that the fundamental difference between MSIP and SSIP mostly the name. Both can be taken into smode or both into Mmode (depending on delegation) of it's a problem for S mode, it is for Mmode as well. I agree that the Smode variants aren't necessary. I don't understand what you're saying about mode-agnostic here; I'll wait to you change the names as proposed and see how it turns out.

…

On Thu, Jan 8, 2026 at 12:21 PM Jordan Carlin ***@***.***> wrote: *jordancarlin* left a comment (riscv/riscv-arch-test#837) <#837 (comment)> Why was the M/U mode table removed? The intent of the trap handler is to deal with any hart configuration, and that includes models that don't have Smode. We ran into an issue when an M-mode interrupt test attempts to write to the supervisor interrupt pending bits of mip (mip.SEIP for example). If S-mode is not supported, mip.SEIP is read-only zero. If S-mode is supported, the interrupt is taken (assuming mideleg is cleared). Writing to the mip.SEIP bit needs to be tested either way. This is an M-mode only test and does not instantiate the supervisor trap handler because it will be run on cores that do not support S-mode, but if the core it is running on does support S-mode, then the machine trap handler needs a way to clear the interrupt. If S-mode is not supported, supervisor interrupts will never be taken and this part of the trap vector table will never be exercised, so it shouldn't matter if the table is fully populated even without S-mode. A lot of these changes seem unnecessary, e.g. the original names of the form. Why is there a difference between an Mmode macro for an Smode handler, vs just using the Smode macro even if you're in Mmode? Mmode is capable of executing anything that Smode can do. I'm not sure who made those changes It's unclear to us as well why there are two variants of the S-mode interrupt macros. That's what @davidharrishmc <https://github.com/davidharrishmc> was asking in a recent email. If no-one can think of a good reason to have multiple versions of the interrupt macros, we'd prefer to drop the RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT macros and just use a RVMODEL_CLR_SSW_INT macro when in both priv modes. I'm also not sure why the default was replaced with an empty macro (which is what the sequence #ifndef X; #define X X does). If you want that behavior, then just leave it the way it was and add #ifndef RVTEST_DFLT_INT_HNDLR #define RVTEST_DFLT_INT_HNDLR That's not what this PR is doing. The priv mode specific variants of the macros (eg RVMODEL_MCLR_SSW_INT and RVMODEL_SCLR_SSW_INT) are being defined to use the mode-agnostic RVMODEL_CLR_SSW_INT macro if the priv mode specific variants are not defined. — Reply to this email directly, view it on GitHub <#837 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJR36F3VEN566LW4JZ34F235FAVCNFSM6AAAAACRA5IFKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRVGYYTMNJYGU> . You are receiving this because your review was requested.Message ID: ***@***.***>