Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Thu, 20 Mar 2025 22:28:14 +0000
Organization: Rocksolid Light
Message-ID: <536efe4d9fd254ac1dfd37f9d9a43838@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org> <vreisc$dqb$1@reader1.panix.com> <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org> <vrh2u1$8vn$2@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1050581"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$dLyD.2t9.2aV.eiWWqmYOeDoW1Z0BPNmr7F0KgDsYX6yVq1bO8tRO
Bytes: 4162
Lines: 68

On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote:

> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
>
> But let me turn it around, what real-world problem does this
> interrupt prioritization scheme solve coupled with the inability
> to disable interrupts solve?

The OS does not have to "walk" its schedule queues in order to
context switch.

The SVR (SuperVisor Return) instruction checks the priority of
the thread that had been interrupted, and if it is of lower
priority than what is pending in the interrupt table, the
one on the interrupt table receives control while the lower
priority thread remains interrupted.

Thus, the return path from an ISR, just does an SVR. If a
DPC/softIRQ has been setup, or another interrupt has become
pending, HW chooses the path--acting as if HW returned control
to the interrupted thread, and then immediately took the inter-
rupt of highest priority still pending--without having executed
a single instruction in the interrupted thread.

>                               Is anyone complaining that the
> ability to disable interrupts is somehow a serious burden?

This thread started with the notion of MSI interrupts and the
inherent need to DI upon arrival at ISR dispatcher. This sub-
thread is investigating whether one can perform ISRs without
disabling interrupts. Thus, making IDisablement an unnecessary
part of interrupt servicing itself.

Your (and EricP)'s contribution is to annotate those instances
where one can arrive at an ISR IE and still want/need to DI and EI
independent of the control transfer from and back to interrupted
thread (even if control arrives reentrantly from interrupted thread).

Many computer designers copy/modify their interrupt architectures
from machines architected prior to the virtualization of Operating
Systems, virtualization of interrupts, HyperVisors, Paranoid threads
(like banking applications) that have survived into the present.

I went the other way, trying to develop a system whereby the path
across context switching domains is cheap and easy*. Not needing
to DI at entry to ISR or exception handlers (more or less) fell
out for free due to the way "the rest of the system" evolved.

(*) cheap for HW, and easy expressly for SW

Not being employed, and not having an OS guy to bounce ideas off
and discuss consequences of going this way or that way is not
available, so I lean on a few people hear to "beat me up" when
my ideas lead me astray.

18 months ago I had a real-time version of the architecture,
with the property that at any instant in time, each core was
executing the highest priority thread, cores had a means to
message back and forth as if it were a remote procedure call
which could return (synchronous; or not--asynchronous) without
an OS mediating these things. I abandoned it not because it
was not good for real time, but because there was no way to
make it Linux Friendly.

Where I am now, is my attempt at being Linux friendly.

>
> 	- Dan C.