Deutsch   English   Français   Italiano  
<vrqa4u$3ktca$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Sun, 23 Mar 2025 17:48:29 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <vrqa4u$3ktca$1@dont-email.me>
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>
 <536efe4d9fd254ac1dfd37f9d9a43838@www.novabbs.org>
 <utWDP.1370783$TBhc.860098@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Mar 2025 01:48:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="134859492fb1e605dc9ff2cb841b4e25";
	logging-data="3831178"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Eaoy/KH2OZDZQkTQL2zgW/mDVijdPHNQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8/vQ7Z3qYZq/ZdReR4wzXk1NNRM=
In-Reply-To: <utWDP.1370783$TBhc.860098@fx16.iad>
Content-Language: en-US
Bytes: 4468

On 3/23/2025 9:16 AM, EricP wrote:
> MitchAlsup1 wrote:
>> 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).
> 
> Supervisor return, whatever it is called - sysret, rei, svr -
> is traditionally another point where a number of OS race conditions
> can force it to briefly disable interrupts.
> 
> The classic case is when a DPC/SoftIrq may be posted by an Interrupt
> Service Routine (ISR) and causes the First Level Interrupt Handler (FLIH),
> which is the ISR nested first on the stack of priority interrupts,
> to exit into the OS rather than return to its prior thread.
> 
> The race condition occurs between the point when the FLIH ISR epilogue
> checks for pending a pending DPC, and not finding one decides to return
> to the prior thread. Between that check and the SVR instruction a higher
> priority interrupt occurs and posts a DPC.
> 
> Another race condition can be how does an epilogue know if it is a FLIH
> or nested one? A counter for each core incremented by the ISR prologue
> and checked by the epilogue would do but what if the nested interrupt
> catches a lower level prologue just before it increments the counter.

[...]

Fun with race conditions... check out some of this shit:

https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ

;^D