riscv/riscv-aia

RISC-V Advanced Interrupt Architecture (AIA)

The RISC-V Advanced Interrupt Architecture (AIA) builds upon the interrupt-handling functionality of the basic RISC-V ISA to add support mainly for the following:

• Message-signaled interrupts (MSIs) from devices.

• Direct control of device interrupts (as MSIs) by a guest operating system running in virtual supervisor mode (VS mode), reducing the reliance on regular hypervisor intervention.

• Additional standard local interrupts for RISC-V harts.

• Intermixing of priorities of local interrupts and device (external) interrupts.

• Conditional delegation of local interrupts to lower privilege levels, including to virtual machines.

Obtaining the document

A pre-built PDF is usually available under Releases: https://github.com/riscv/riscv-aia/releases

Licensing

The files in this repository are licensed under the Creative Commons Attribution 4.0 International License (CC-BY 4.0). The full license text is available at https://creativecommons.org/licenses/by/4.0/.

riscv-aia's Issues

Optional setting of interrupt pending when writing sourcecfg?

The spec states:

Any write to a sourcecfg register might (or might not) cause the corresponding interrupt-pending bit to be set to one if the rectified input value is high (= 1) under the new source mode.

Is this intended to mean that there is no architectural requirement for an interrupt pending bit to be set in such a case. Or is intended to mean that there are other factors that impact the architectural behavior in such a case?

More specifically, in MSI mode when switching from Detached to Level Zero and the incoming wire value is zero, is it required that the corresponding interrupt-pending bit to be set to one? It seems like the answer is no since the inversion of the incoming wire value is a constant 1.

Behavior of accessing vsireg at vsiselect addresses 0x30~0x3f from HS-mode.

The AIA spec says that there are no registers at vsiselect addresses 0x30-0x3f (iprio array), and an attempt from VS-mode to access sireg (vsireg) casues a virtual instruction exception when vsiselect has a value in the range 0x30-0x3f.

What's the behavior of an attempt from HS-mode to access vsireg when vsiselect has a value in the range 0x30-0x3f? The HS-qualified concept in the preliminary privileged spec states that normally raising a virtual instruction exception from VS-mode if it would be valid to execute from HS-mode. Does the vsireg provide a valid constant-zero behavior for HS-mode when vsiselect has a value 0x30-0x3f? Or does it cause an illegal instruction or virtual instruction exception?

Is there any requirement about the speed of arbitration or the interrupt infomation transfer?

For example:

1. Is it necessary for the change of the value of *topei to be immediately visible on *topi? If the answer is no, what if a fence io is executed between reading *topei and *topi?
2. Is it mandatory for the value of *topi to cause an immediate trap? In other words, if software reads a value of *topi that should cause a trap, will HART trap right after the CSR read instruction? Additionally, if the answer is no, what happens if a fence io is executed after reading *topi?
3. Is it mandatory that after I changed the hstatus.VGEIN, the vstopei should immediately changed to show the interrupt of corresponding guest interrupt file, and hart won't see any interrupt from the last guest interrupt file after the CSRW instruction?

Does interrupts have priority when aplic forward through MSI? How to send MSI if 1023 interrupts arrive simultaneously

Feature Request: Hypervisor Guest interrupts on APLIC-only systems

Hypervisor Guest Interrupts in APLIC-only Systems

Rationale

There is a business case for multi-core SoCs without PCI-express but employing the RISC-V Advanced Interrupt Architecture (AIA), i.e., look at the many multi-core SoCs without PCI-express targeting low-end embedded systems in existence today.

The AIA addresses these systems with an APLIC-only solution. As such systems are basically not modifiable in the field, a simple wired interrupt request scheme, such as provided with the APLIC, suffices.

A useful software architecture for these devices is to use a simple hypervisor to statically partition the multi-core into different "cells" (consisting of subsets of the cores, of memory ranges, and of the system's devices the cells may access exclusively), with each running a separate operating system (such as Linux or an RTOS) or bare metal software. This sort of architecture occurs when consolidating legacy multi-board solutions on to a single SoC and can also be driven by safety concerns, where one would like to separate safety-critical code from the rest of the system as much as possible.

Unfortunately, the AIA in its present form does not allow such a hypervisor (footing on the RISC-V H-extension) to use the guest-interrupt passthrough feature on an APLIC-only implementation: this feature is supported by the Incoming MSI Controller (IMSIC) only. The interrupt passthrough feature allows interrupts to be passed through to guests (or cells) with no software overhead in the hypervisor, making it an attractive feature for real-time systems with tight timing constraints.

As an initial idea, I think it would suffice for each APLIC interrupt source to be augmented with an additional attribute, the virtual guest interrupt number, with an encoding identical to the hstatus.VGEIN field (a 6-bit field where the value 0 means non-guest, i.e., hypervisor). I do not expect the systems outlined above to require more than 63 cells in total. (A more general proposal would allow each interrupt source to specify its VGEIN value on a per hart basis.)

Implementation Suggestion

The target[i] registers in the MSI delivery mode already have a guest index field defined for this purpose when these bits are unused in the direct delivery mode. Using the same field for the same purpose in direct delivery mode would seem to satisfy the requirements of this request. On a hardware level, the cores in a SoC implementing only an APLIC would require an additional 6-bit bus from APLIC to cores that indicates the guest interrupt number when they implement the H-extension.

SEE API to APLIC

Incidentally, the APLIC suffers from the same security loophole as the PLIC: there is basically no way for M-mode code to protect its registers from S-mode (the PMP is not granular enough)[*]. The original PLIC proposal addressed this with a to-be-defined S-mode Execution Environment (SEE) API (e.g. an SBI extension) to deal with configuration of the PLIC, but this has not been realized for PLIC in openSBI to date.

[*] Assuming the memory address bus does not record the hart mode (M/S/U/VS/VU) of the access.

The APLIC chapter addresses these concerns when discussing the M-mode and S-mode interface to the IMSIC, but it applies to all registers: setip/setipnum/clipnum/setie/setienum/...

The same approach -- configuration via the SEE -- should be viable for the APLIC, but this time it needs to be done: for a simple system assuming non-antagonistic S-mode software, the present situation may be tenable, but for hypervisor systems, both large and small, security and safety are essential. With the RISC-V ISA explicitly acknowledging the existence of the SEE, a SEE API to the interrupt controller is an elegant way of not requiring fine grained PMP protection of APLIC registers on the one hand and to eliminate the need for trapping APLIC accesses or providing a new para-virtualized interface to the APLIC on the other: if the APLIC specification itself defines the API, hypervisors can implement that API as they see fit without affecting guest code bases (by requiring the use of new para-virtualized interfaces).

For completeness: a technically correct solution would be for the API to be specified as direct memory accesses to the registers themselves, with M-mode code decoding APLIC accesses in the memory-access exception handler and hypervisors decoding them in guest memory access exception handlers. If a technical case can be made for this solution, viz. para-virtualization via a new SEE API is not clearly more performant than trapping and decoding individual memory accesses, I guess it would be viable, but it should be made clear in the AIA specification that this step is necessary -- the comments regarding the interface registers to the IMSIC would then be redundant.

Perhaps a better solution would be to have the APLIC have a CSR interface instead of a memory-mapped one: an indirect interface using an address and a data register would probably suffice and reduce pressure on the CSR address space.

Is APLIC Child Index Relative or Absolute?

In section 4.5.2, is the child index field of sourcecfg relative or absolute? Relative would be relative to the domain (first child is always at index 0), absolute would assign a unique index to each domain the hierarchy. Can an interrupt be delegated to any child in the hierarchy or just to the immediate child?

Can interrupt identity >63 cause a trap in non virtualized mode?

On page 61:

The RISC-V Privileged Architecture ensures that, when the value of mtopi is not zero, a trap is taken to M-mode for the interrupt indicated by fi eld IID if either the current privilege mode is M and mstatus.MIE is one, or the current privilege mode has less privilege than M-mode. The trap itself does not cause the value of mtopi to change.

The mtopi actually allows IID>63. But the Privilege spec says:

an interrupt traps to M-mode wheneverall of the following are true: (a) either the current privilege mode is M-mode and machine-level interrupts are enabled by the MIE bit of mstatus, or the current privilege mode has less privilege than M-mode; (b) matching bits in mip and mie are both one; and (c) if mideleg exists, the corresponding bit in mideleg is zero.

The mip and mie cannot be wider than 64, so why are they compliant?

About the possibility of IOMMU examining ie bit before sending notify MSI.

On page 86:

The interrupt-pending and interrupt-enable bits are stored interleaved by doublewords within an MRIF to facilitate the possibility of an IOMMU examining the relevant enable bit to determine whether to send a notice MSI after updating a pending bit, rather than the default behavior of always sending a notice MSI after an update without regard for the interrupt-enable bits. The memory arrangement matters only when MRIFs are supported without atomic update.

I don't understand the last sentence. In my understand, if supported without atomic update, IOMMU can't specify the interrupt enable state at the time it update the interrupt pending state. Also, when supported with atomic update, if ip and ie bits of a interrupt are far from each other, IOMMU can't do this too. So in my undersatand, the interleaving of ie and ip array is only matter for IOMMU with atomic support, while it is always impossible for IOMMU without atomic support to examine the relevant enable bit to determine whether to send a notice MSI after updating a pending bit.

'UNSPECIFIED' Value for 'hideleg[n]', During Read-Only to Writable transition.

For 13 <=n <= 63, value of hideleg/h[n] may become writable from being read only zero, when mvien/h[n] or mideleg/h[n] transitions from zero to one. Should the spec include a sentence saying value of hideleg/h[n] becomes UNSPECIFIED when hideleg/h[n] becomes writable?

Add time capture support to ACLINT

The ACLINT (Advanced Core Local Interruptor) has a Machine-level Timer Device (MTIMER). It is hard to synchronize the MTIMER with an external reference clock. What would help if the MTIMER had a time capture mechanism which can be triggered by an external signal (for example a pulse-per-second signal). When the external capture signal arrives, the current timer value should be stored to a time capture register, a capture status flag should be set, and an interrupt should be generated (if enabled). If the capture status flag is already set, then a capture overflow status flag should be set. The captured time can be used by time synchronization algorithms to synchronize the MTIMER with an external reference clock, see for example RFC 2783

How to distinguish APLIC interrupt in MSI mode?

TOPI, CLAIMI registers used to identify APLIC interrupt to be serviced are available only in direct mode, but not in MSI mode. How is it supposed to identify interrupt in MSI mode? Scan SETIP[0..31] bits? Allocate MSI interrupt vector for each APLIC interrupt? If second, is it supposed to preallocate MSI interrupt vectors for all APLIC interrupts (maximum possible interrupt count as specified in ACPI/FDT)? If so, it looks wasteful to spend limited number of MSI interrupts to all APLIC interrupts, most of them may be unused. Also what is supposed to happen if APLIC have more interrupts than IMSIC? Maybe MSI interrupt vectors should be allocated dynamically for used APLIC interrupts? If so, it can complicate software design and need special RISC-V only handling that do not fit to generic architecture.

IMSIC interrupt file eidelivery register affects only external interrupt in *ip CSR

Clarify that an IMSIC interrupt file's eidelivery register affects (at most) only whether an external interrupt appears in an *ip register (MEI or SEI in mip or sip, or a bit in hgeip) and what the source of such an interrupt may be (either the interrupt file or a separate external interrupt controller such as an APLIC). An interrupt file's eidelivery register has no effect on the following:

• other state within the interrupt file, including the arrays of interrupt-pending and interrupt-enable bits;
• any *topei CSR (mtopei, stopei, or vstopei).

Conflict register model between MVIEN and HVIEN

Original thread here:
#64

The issue can be reconsidered using register model point of view.

IMO, when understanding MVIEN, one should refer to HVIEN spec words as a cross reference.
IMO, MVIEN is added by AIA just because nested virtualization requires MVIEN to S-mode to act as equivalent as HVIEN to HS-mode.
Thus, yes, spec is wrong for MVIEN, but it is wrong not because it controls MVIP (it shouldn't control MVIP), but it should be designed equivalent to HVIEN which controls multiple invisible SIP bits for virtual machines. So we should fix the SPEC along the other way.

SPEC actually dictates this clearly in a different paragraph.
MVIP/HVIP which is still a single M-mode/HS-mode bit (whatever it is an aliasing bit or logically ORed bit), is a kind of usage model, known as interrupt filtering. This usage model is designed for traditional RISC-V machines where CLINT MTIP is meant to be filtered as STIP and this bit is made visible in AIA as MVIP.
However, MVIEN/HVIEN is implemented as a totally different usage model, controlling multiple S-mode/VS-mode bits, which is known as virtual interrupt.

AIA introduces the new virtual interrupt usage model, just because the original interrupt filtering model (virtualized in the lower privileged mode) is not such useful for virtual machines and extended major interrupts (should have virtualized bits in the upper privileged mode).

As a conclusion, I don't think MVIEN controls an alias of MVIP, but should control an alias of SIP virtual interrupt bit and this bit is invisible to MIP and MVIP.

So why don't we just leave SEIP original usage model to MVIP and don't let it bother the new register model since software won't suffer from the original usage model when they are going to use the new register model?

Clarification of the behavior of virtual interrupts

Can you please clarify the behavior of virtual interrupts?

Firstly, I understand that mvien/mvip allow virtual interrupts to be presented to S-mode by M-mode. Suppose that a local interrupt (e.g. ID16) is signalled in this way and also connected externally. Is my understanding correct that if presented as a virtual interrupt it can only be taken to HS/VS mode, whereas when signalled externally it will be taken to M-mode (because mideleg[16] must be 0 in this case)? In other words, is it true that with virtual interrupts the interrupt ID alone is no longer sufficient to determine the target execution level?

Secondly, can you clarify whether virtual interrupts affect the WFI instruction in any way? Do pending virtual interrupts affect whether execution of WFI is allowed to enter a wait state, and is this execution-mode-dependent?

Thanks.

What's the purpose of virtual interrupts?

I'm confused about the purpose of virtual interrupts. What Can it do that mideleg can't?

Why the priority of the third candidate of vstopi is 256?

On page 76:

• if bit 9 is one in both vsip and vsie, and neither of the fi rst two cases applies:

• a supervisor external interrupt (code 9) with priority number 256;

Since on page 77:

If bit IPRIOM (IPRIO Mode) of hvictl is zero, IPRIO in vstopi is 1; else, if the priority number for the highest-priority candidate is within the range 1 to 255, IPRIO is that value; else, IPRIO is set to either 0 or 255 in the manner documented for stopi in Section 5.4.2.

It seems that the priority will be regulated to 255, so I wonder why use 256 rather than use 255.

The timing issue regarding reading *topei

Hi,

I have one question about the *topei.

If a hart asks IMSIC for the interrupt arbitration, leading a trap handler to a lower priority interrupt handling (e.g. IID=4), the following scenario may occur:

A new MSI with the higher priority (e.g., ID = 1 has higher priority than previous *topei.IID = 4) updates the interrupt file of IMSIC before the software read the *topei and claim the interrupt in the trap handler.

What is the expected/suggested behavior (return the latest *topei with IID = 1 or return the served *topei with IID = 4)?

Thanks!

Question regarding mvip[9]

1. Start with deleg[9]=0 mvien[9]=1
2. An interrupt is delivered to S mode through setting mvip[9]=1
3. Spec says mvip is independent writeable bit of mip[9] and mip[9] is readonly and comes purely from IMSIC
4. We move to deleg[9]=1, mvien[9]=1
5. Now, should mip[9] see the '1' delivered in step 2 ?

Duo-PLIC of limited use?

Since compatibility mode is a property of the root domain only, either the entire system is using a legacy PLIC or the entire system is using a series of APLIC domains. This creates a nasty interaction between M-mode firmware and an S-mode OS where they both have to agree on which scheme is being used; firmware can't enable APLIC use because it might break an OS written to the old de-facto platform standard that used a SiFive PLIC (and since OS backwards compatibility is a far greater concern than firmware, given new SoCs need new firmware anyway, saying that's ok to do then would render CM pretty much pointless), and an OS can't enable APLIC use because it might break firmware written to the old de-facto platform standard, and maybe even new firmware that can support an APLIC if there's no nice way to inform M-mode that the PLIC's configuration has been changed underneath it and it needs to switch immediately to the APLIC driver.

How is this intended to work in practice? I struggle to see how there can be a sensible transition period. It seems to me that this would be solved if it were per-domain such that the S-mode domain can be left in compatibility mode with the OS free to change that, but the M-mode domain can be eagerly switched to APLIC mode without fear of breaking S-mode.

Interrupt flow

In PLIC Spec ,“Interrupt Completion:After the target has serviced the interrupt, it sends the associated interrupt gateway an interrupt completion message.” We don't have any completion regs in APLIC.what's the new interrupt flow in APLIC?

APLIC ithreshold description typo

In ithreshold section, it says interrupt sources with priority numbers P and higher do not contribute to signaling interrupts to the hart. I believe that higher should be corrected to lower, just likes the threshold definition in original PLIC spec.

regarding delegation and child index

If I have three domains A -> B -> C (like figure 4.3 in the spec).

• Is C considered a child of A i.e. is the index of C a valid value for A's sourcecfg.child_index field ?

• Can A directly delegate an interrupt to C even if B does not delegate the same interrupt to C?

• Lastly, is there a practical scenario where one would require to have A -> (B,D) -> C (more than one child at the same level ?

Possible typos in table 6.1

Given that bit 10, 6, and 2 in hideleg correspond to bits 9, 5, and 1 in the vsip/vsie CSRs, it seems that some of the bit indices in table 6.1 is off by 1. Instead of vsip[n], we should have vsip[n-1]: this way when hiedelg[10] is zero, vsip[9] is read only zero.

Similarly, sip[n], vsie[n], and sie[n] should all be indexed with n-1.

APLIC Level sensitive interrupts in MSI mode

I have following queries on level sensitive interrupts in MSI mode.

The pending bit is cleared whenever the rectified input value is low, when the interrupt is forwarded by MSI, or by a relevant write to an in clrip register or to clripnum.

Once level sensitive interrupt related rectified input value goes from low to high, MSI has to be forwarded by APLIC. However there is no specification on how much time APLIC can take to forward MSI. Since pending bit is cleared as soon as rectified input becomes low, Is it possible that interrupt is lost because before MSI is forwarded, pending bit is cleared, and due to clearing of pending bit, MSI is not generated.

How much time level sensitive interrupt wire has to remain asserted to successfully generate MSI.

A write to a sourcecfg register will not by itself cause a pending bit to be cleared except when the source is made inactive. (But see Section 4.7.)

If we change sourcecfg.SM from Level0 to Level1 or vice-versa, rectified input value becomes low subsequently clearing the interrupt. Is this correct functioning and legal way to clear level sensitive interrupts?

Conflicting sentences about mvip[9] and mip[9] when mvien[9]=0

The spec says that "when mvien[9]=0, mvip[9] is an alias of mip[9]" and "when mvien[9]=0, mvip[9] is logically ORed into the readable value of mip[9]."

In my reading, aliasing bits means identical bits and logically ORed means bits may differ. For instance, if mip[9] and mvip[9] are aliasing bits, the value pair of (mip[9], mvip[9]) can be (0, 0) and (1, 1) only. On the other hand, if mip[9] logically ORs the mvip[9] into the readable value, the value pair of (mip[9], mvip[9]) can be (0, 0), (1, 0), and (1, 1).

Is the value pair of (mip[9], mvip[9]) = (1, 0) a valid state when mvien[9]=0?

APLIC Domain Privilege

How do we tell the privilege (Machine or Supervisor) level of a domain. The spec says that the root domain must be at Machine level and that a parent domain must also be at machine level. This implies that supervisor must be a leaf. But Machine can also be a leaf. So how do we identify a domain with supervisor privilege?

Remove term 'master' from AdvPLIC-ex-3Domains.png

Are priorities of virtual interrupts configurable to HS-mode through iprio array?

I want to clarify whether priorities of the virtual interrupts, i.e., VSEI, VSTI, and VSSI, are configurable to HS-mode through iprio array if supporting H-extension. The spec has some words about setting a priority to the VSEI through the iprio array (bits 23:16 of iprio2). Thus, I assume the answer is yes, and the HS-mode may configure the virtual interrupts, including VSEI, though the iprio array if supporting H-extension.

However, I was confused by another sentence: For a given interrupt number, if the corresponding bit in SIE is read-only zero, then the interrupt’s priority number in the supervisor-level iprio array must be read-only zero as well. All virtual interrupt bits in SIE are read-only 0, including SIE.VSEI. According to the above sentence, the corresponding bits of the iprio array (bits 23:16 of iprio2) must be read-only zero, which I believe wasn't the intended conclusion from the spec.

Does the following sentence provide a better description when supporting H-extension? If an interrupt number corresponds to a read-only zero bit in both SIE and HIE (if supported), then the interrupt’s priority number in the supervisor-level iprio array must also be read-only zero.

APLIC's domaincfg.IE bit and idelivery registers affect only interrupt delivery

For an APLIC, clarify that an interrupt domain's global IE bit in register domaincfg affects only whether interrupts are delivered to harts (by wire or by MSI), nothing else. The value of domaincfg.IE has no effect on the following:

• the visible values of the interrupt-enable and interrupt-pending bits of active interrupt sources;
• the values of IDC registers, including idelivery, topi, and claimi.

Likewise, an IDC structure's idelivery register affects only whether interrupts are delivered to the relevant hart; it has no effect on other IDC registers, including topi and claimi.

APLIC level-sensitive interrupts in direct delivery mode

APLIC has following description to level-sensitive interrupts in direct delivery mode.

If the source mode is Level1 or Level0 and the interrupt domain is configured in direct delivery
mode (domaincfg.DM = 0):
• The pending bit is set to one whenever the rectified input value is high. The pending bit
cannot be set by a write to a setip or setipnum register.
• The pending bit is cleared whenever the rectified input value is low. The pending bit is
not cleared by a claim of the interrupt at the PLIC, nor can it be cleared by a write to an
in clrip register or to clripnum.

Assume the rectified input of a level-sensitive interrupt is high and enabled, the interrupt will be sent to all hart with idelivery is high in the domain. The interrupt then be taken multiple times because the pending of claimed interrupt remains high. In original PLIC spec, this won't happen because the pending is cleared after interrupt claim. Next interrupt request will be forwarded after interrupt completion.

To fix the issue, we could use the same mechanism of level-sensitive interrupts in MSI delivery mode. The term forwarded by MSI is changed to claimed. After the first responder who claimed the interrupt, others can't claim it until positive edge of rectified input or a relevant write to setip or setipnum register (the same purpose of interrupt completion in original PLIC spec). The changed description is written below:

If the source mode is Level1 or Level0 and the interrupt domain is configured in direct delivery
mode (domaincfg.DM = 0):
• The pending bit is set to one by a low-to-high transition in the rectified input value. The
pending bit may also be set by a relevant write to a setip or setipnum register when the
rectified input value is high, but not when the rectified input value is low.
• The pending bit is cleared whenever the rectified input value is low, or when the interrupt is
claimed. The pending bit cannot be cleared by a write to an in clrip register or
to clripnum.

typo controoler -> controller

There's a typo on

riscv-aia/doc/src/AdvPLIC.tex

Line 44 in c7614b2

as its external interrupt controoler, a system with multiple PLICs

controoler should be controller.

@jhauser-us

Illegal instruction exception or virtual instruction exception?

AIA spec:

Following the default rules for the hypervisor extension, attempts from VS-mode to directly access a hypervisor or VS CSR, or from VU-mode to access any supervisor-level CSR (including hypervisor and VS CSRs), usually raise not an illegal instruction exception but instead a virtual instruction exception. For details, see the RISC-V Privileged Architecture.

Privileged spec:

• in VS-mode or VU-mode, attempts to access an implemented non-high-half hypervisor CSR or VS CSR when the same access (read/write) would be allowed in HS-mode, assuming mstatus.TVM=0;
• in VU-mode, attempts to access an implemented non-high-half supervisor CSR when the same access (read/write) would be allowed in HS-mode, assuming mstatus.TVM=0;

Consider the following scenario

• vsiselect=0x0
• siselect=0x0
• VU-mode accesses sireg

Since said access is not HS-qualified (since siselect=0x0), should an illegal instruction exception instead of a virtual instruction exception be raised?

Virtualizing the contents of the IMSIC supervisor interrupt file

Consider the M-mode-assisted virtualization paradigm:

• The H extension is (typically) not implemented.
• M-mode software switches between one or more S-mode worlds.
• At most one S-mode world is "privileged", runs with mstatus.TVM=0 and mideleg[SEIP]=1. This supports type-2 hypervisors with only a minimal code footprint in M-mode.
• Limited support exists for assigning hardware directly to VMs; interrupts are delivered to VMs by software, not hardware.

Without IMSIC, delivering an interrupt to a VM involves setting mvip[SEIP] (or the hidden mip[SEIP] bit pre-AIA), entering the guest, then using memory-access virtualization to handle the guest's accesses to (A)PLIC claim and complete registers.

With an IMSIC in the host, if there is a privileged S-mode world, the S-mode IMSIC must be under the control of the privileged world at all times because it can receive interrupts at any time. But this prevents exposing a virtual IMSIC to the guest, because the guest needs to have its own view of the supervisor eipNN and eieNN registers, and if Smstateen is not implemented all S-mode worlds can observe the contents of eipNN.

Proposed solution: Mandate the functionality of mstateen[58] to be implemented by all harts which provide M-mode-assisted virtualization (support for the TVM, TW, and TSR bits in mstatus) and an IMSIC. This could be either a dependency on the Smstateen extension, an alias for the state bit in some M-mode register, or a new state bit which provides the same functionality (logical AND if both are implemented).

typo issue

riscv-aia/doc/src/intro.tex

Line 94 in f9d020c

restoration on exit; and

The last ‘and’ of this line can be removed

vstopei when VGEIN=0

Re-asking the question I asked on the mailing list so it doesn't get lost/forgotten.

Section 2.3 of AIA says:

Along the same lines, when hstatus.VGEIN is not the number of an implemented guest external interrupt, attempts from M-mode or HS-mode to access CSRs vsseteipnum, vsclreipnum, vsseteienum, or vsclreienum raise an illegal instruction exception, and attempts from VS-mode to access sseteipnum, sclreipnum, sseteienum, sclreienum, or stopei raise a virtual instruction exception.

Why is vstopei missing from the list of CSRs being accessed from M/HS? If that's intentional then what should a read of vstopei return when VGEIN is 0 or some other unimplemented guest external interrupt?

About the "sticky" property of sip.

On page 64:

If a standard local interrupt becomes pending (= 1) in sip, the bit in sip is writable and will remain set until cleared by software.

But what if mvien or mideleg changes? (Since they can change the meaning of sip between the alias of mvip, the alias of mip and read-only 0)

And same question about vsip.

Detecting the extension

How can a debugger (or other software) detect which CSRs are available, without trying to access each CSR individually?

I think if miselect is can be read without getting an exception, then miselect, mireg, mtopei, mtopi, mvien, and mvip are all implemented, and if XLEN=32 then midelegh, mieh, mvienh, mviph, and miph are also implemented.

Then if misa.S is set, the Section 2.2. CSRs are also implemented, and if misa.H is set, then the Section 2.3 CSRs are also implemented.

So I can detect everything I need by just attempting to read miselect. Is that right?

Does SEI in VS mode use default priority?

On page 74:

Major interrupts outside the priority-confi gurable subset can still be directed to VS level, but their priority will simply be the default order defi ned in Section 5.1.

But SEI is also not in the subset of major interrupt numbers listed on page 73:

1 Supervisor software interrupt
5 Supervisor timer interrupt
13 Counter overfl ow interrupt
14–23 Reserved for standard local interrupts

So I wonder whether SEI in VS mode uses default priority.

WARL values for hvictl.IID

Section 7.3.2 states that hvictl.IID is WARL. Can you please clarify what determines the legal values for this field, specifically:

1. whether there are any values in the standard interrupt range 0-15 that are always illegal, always legal or implementation-defined; and
2. what constraints are likely for values 16 and above.

Thanks.

Convert LaTeX specification to AsciiDoc

Opening this issue in order to track conversion of the LaTeX specification to AsciiDoc. Progress can be found on the asciidoc branch.

mvien[1]

1.mvien[1] =0 , external interrupt controller give a intrrupt setting mip.ssip = 1
2.should mvip.ssip[1] change from 0 to 1 ?

Add a comment calling out the software-writable bit behind mip.SEIP

Add a comment calling out the Privileged ISA's software-writable bit behind mip.SEIP and emphasizing how the AIA makes that bit directly accessible as bit 9 of mvip. See #64.

How hvictl affect vstopi? Is every value legal?

Hi @jhauser-us,
We have two question about HVICTL.

1. There is a candidate for vstopi, if bit 9 is not one in both vsip and vsie, hvictl.VTI=1, and hvictl.IID is not 9, the major interrupt is specified by hvictl field. Is it true that vstopi will reflect the value of hvictl no matter what value it contains? For example, what if the hvictl.iid is written with IID=MEI? (Machine External Interrupt should not be in VS-level).

if hvictl fields VTI = 1 and IID ̸= 9:
the major interrupt specified by hvictl fields IID, DPR, and IPRIO.

2. In spec, hvictl[27:16] is reserved for IID and the requirement is at least 6-bit. If the user choose to implement with 6-bit, could I say it's legal that hvictl[27:22] is always zero no matter what value is written to hvictl[27:22]?

IID is a WARL unsigned integer field with at least 6 implemented bits, while IPRIO is always the full 8 bits. If k bits are implemented for IID, then all values 0 through 2k − 1 are supported, and a write to hvictl sets IID equal to bits (15 + k):16 of the value written.

Thanks.

vstopi behavior

The behavior of CSR vstopi is described in section 6.3.3.

vstopi returns information about the highest-priority interrupt for VS level, found from among
these candidates (prefixed by + signs):
• if bit 9 is one in both vsip and vsie, hstatus.VGEIN is the valid number of a guest interrupt
file, and vstopei is not zero:

• a supervisor external interrupt (code 9) with the priority number indicated by vstopei;
  • if bit 9 is one in both vsip and vsie, hstatus.VGEIN = 0, and hvictl fields IID = 9 and
  IPRIO ̸= 0:
• a supervisor external interrupt (code 9) with priority number hvictl.IPRIO;
  • if bit 9 is one in both vsip and vsie, and neither of the first two cases applies:
• a supervisor external interrupt (code 9) with priority number 256;
  • if hvictl.VTI = 0:
• the highest-priority pending-and-enabled major interrupt indicated by vsip and vsie
  other than a supervisor external interrupt (code 9), using the priority numbers assigned
  by hviprio1 and hviprio2;
  • if hvictl fields VTI = 1 and IID ̸= 9:
• the major interrupt specified by hvictl fields IID, DPR, and IPRIO.

Does this imply that when hvictl fields VTI = 1 and IID != 9, our focus is solely on SEI (code 9) and the hvictl interrupt, disregarding other major interrupts?
Consider the following case:
Only two pending and enabled interrupts exist: 44 and 43.
hvictl.VTI = 1, hvictl.IID = 44, and hvictl.IPRIO = 1. Additionally, all hviprio array values are zero.
What is the expected/suggested behavior?

1. The return ID should be 44 because we need to consider other interrupts. (Default priority 44 > 43)
2. The expected return ID should be 43. This is because, under the condition hvictl.VTI = 1 and hvictl.IID != 9, we solely prioritize SEI and the hvictl interrupt.
   Thanks!

regarding holes in idc structures

The idc structures requires 32-bytes but fields for only 20 bytes have been allocated. Are the other 12-bytes reserved or available for custom use? Should they be read-only zeros if accessed or should we raise a bus/slave error?

Request: Extension name (Sm*?) for CSR names support on toolchains

c.f.
https://wiki.riscv.org/pages/viewpage.action?pageId=327814

Much like Core-Local Interrupt Controller (CLIC) on fast interrupts TG, AIA specification adds number of CSRs (44 CSRs on 0.2.1-draft) for efficient yet flexible interrupt handling.

As a toolchain developer, that would be nice to have an extension name (possibly starting with Sm) for AIA to enable CSR names for AIA ... like CLIC (Smclic is shown above as an example ― WARNING: this name is not ratified).
If we have that (e.g. smexample), we can add it like gcc -march=rv64gc_smexample ... to enable AIA CSR names.

Of course, we can also use integer literal to control AIA CSRs (by number) and that (not defining the names in the toolchain) may be an option. On the other hand, I think enabling AIA CSR names by default is not reasonable.

behavior when CLIC implemented and enabled?

Is it legal to implement both CLIC and AIA extensions?

If so, what effect (if any) does this have on AIA CSRs when CLIC mode is enabled? Do any of them appear hard-wired to zero, like xie/xip CSRs?

Thanks.

MVIP.STIP

Is it recommended for this alias to be writeable or read-only when menvcfg.STCE is off?

vstopi behavior refers to vstopei

The behavior of CSR vstopi refers to the value of CSR vstopei (section 7.3.3). But vstopei is present only when an IMSIC is implemented. What happens if an IMSIC is not implemented?

Is there an assumption that hstatus.VGEIN can only be non-zero if an IMSIC is present? Is this stated anywhere?

Thanks.

local interrupts in sip and vsip may be cleared when other CSRs change

Address the oversight reported in #70.