Comments (4)
The mapping of APLIC interrupts to IMSIC interrupt identities at a RISC-V hart is very similar to how x86 computers map interrupts from their "I/O APIC" to a "local APIC" at an x86 core. The RISC-V APLIC and IMSIC perform roles similar to the x86 I/O APIC and local APIC, respectively. All of the options you listed are possible.
If you have more than one or two RISC-V harts (or you want to support that possibility in the future), I would say your best choice for utilization is to dynamically allocate IMSIC interrupt identities at each hart for the subset of APLIC interrupts that get assigned to that hart. I don't see a reason for these allocations to change more often than about once every 100 ms, and probably less often. But if a particular operating system written previously for x86 systems doesn't support such dynamic allocation, then I suppose you will face the same inefficiencies that the software does on x86 systems.
I can see only two reasons for needing new RISC-V-only handling that doesn't fit an existing software architecture. First, when porting from x86-world, you might want to improve the allocation of interrupt identities on your RISC-V system compared to what was previously done for x86. In that case, one might ask why the shared software architecture couldn't be upgraded to improve interrupt handling for both x86 and RISC-V.
Probably a more likely reason to need special RISC-V handling would be because the original software comes from a different type of system, such as an Arm machine, that does not have the same kind of MSI model. If porting Arm-world software is the problem, all I can tell you is that the authors of the RISC-V Advanced Interrupt Architecture intentionally rejected Arm's model for handling MSIs, judging the hardware overly complex for the task.
Before the AIA was ratified, the people who port Linux to RISC-V had a couple of years to complain if the AIA's model doesn't fit well with Linux, but I heard no such complaints. As far as I know, it hasn't been a significant obstacle for RISC-V Linux, perhaps due to Linux's origins on x86 machines.
Is there specific software you are trying to port to RISC-V that has an architecture you feel is incompatible with the RISC-V AIA?
from riscv-aia.
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.
For APLIC MSI mode, the Linux approach is to allocate a IMSIC ID for a APLIC interrupt source only when a client driver does request_irq(). In other words, APLIC interrupt source to IMSIC ID mapping is on-demand and not pre-allocated. Further, the IMSIC driver allocates ID for each CPU separately so for N CPUs and M IDs we have total NxM IDs to allocate from so the number of APLIC interrupt sources can be more than number of IDs on one CPU but it should be less than total IDs across all CPUs.
Please refer the latest Linux AIA drivers will be most likely merged in Linux-6.10.
(Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/)
from riscv-aia.
(Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/)
Any Github etc. branch for it? Sorry, I am not familiar at all with Linux development workflow.
UPDATE: https://github.com/avpatel/linux/tree/riscv_aia_v17
from riscv-aia.
If you have more than one or two RISC-V harts (or you want to support that possibility in the future), I would say your best choice for utilization is to dynamically allocate IMSIC interrupt identities at each hart for the subset of APLIC interrupts that get assigned to that hart.
Further, the IMSIC driver allocates ID for each CPU separately so for N CPUs and M IDs we have total NxM IDs to allocate from
Thanks for the answers. I will try to use dynamic per-hart IMSIC interrupt allocation in my system. It will need some redesign as it was originally designed for x86 and do not have any interrupt request hooks for interrupt controller driver interface, only enable/disable interrupt hook that should be able to be called with interrupts disabled.
from riscv-aia.
Related Issues (20)
- About the "sticky" property of sip. HOT 1
- Are priorities of virtual interrupts configurable to HS-mode through iprio array? HOT 3
- Can interrupt identity >63 cause a trap in non virtualized mode? HOT 2
- Does SEI in VS mode use default priority? HOT 2
- Why the priority of the third candidate of vstopi is 256? HOT 7
- About the possibility of IOMMU examining ie bit before sending notify MSI.
- local interrupts in sip and vsip may be cleared when other CSRs change
- mvien[1] HOT 1
- Conflict register model between MVIEN and HVIEN HOT 1
- MVIP.STIP HOT 2
- Optional setting of interrupt pending when writing sourcecfg? HOT 1
- Is there any requirement about the speed of arbitration or the interrupt infomation transfer? HOT 5
- ASCII doc broken text HOT 3
- Clarify "Access control by the state-enable CSRs" HOT 2
- How to define NMI in AIA architecture? HOT 1
- Does mstateen0[58]=0 take precedence over hstatus.VGEIN=0? HOT 1
- How to distinguish IPI and external interrupt if using IMSIC to accomplish IPI
- Should virtual supervisor domain be implemented in APLIC while hypervisor (virtual supervisor) is supported?
- What's the value of stopi.IPRIO when using mvien and mvip to generate a SEI that traps to S mode?
- How to arrange the address of M/S/VS-file in multi-socket and multi-die per socket system?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from riscv-aia.