Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: MSI interrupts
Date: Thu, 13 Mar 2025 00:50:47 -0400
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <vqto79$335c6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 13 Mar 2025 05:50:50 +0100 (CET)
Injection-Info: dont-email.me; posting-host="134c048fe25441bee20a3d0d36ac0fa1";
	logging-data="3249542"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180eYojezokPDo7Ki3HT8dHiTuV+iQWSQc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oLsH6W+2ni01dfPoNLxCng3mC28=
Content-Language: en-US

Planning on having the Q+ CPU respond directly to MSI interrupts. My 
thought is to integrate an interrupt controller directly into the CPU 
which will have several queues to prioritize interrupts. The controller 
will take care of detecting the highest priority interrupt to process, 
performing priority inversion occasionally, and detect stuck interrupts.

Setting up an MSI interrupt protocol for Q+.

The controller will sit on the CPU's main response collect bus.
Interrupt messages contain the interrupter's bus/device/function + a 
cause code. They may also contain a target core number.

Planning on distributing the interrupt control to peripheral devices 
instead of having a system level interrupt controller.