assume a Kernel thread which working at IRQL == DISPATCH_LEVEL is
currently been served. meanwhile , an Interrupt as arrived and an ISR as
been called. after the ISR as finish and the interrupt as been served, the
O/S should return to DISPATCH_LEVEL (or there are other interrupts higher to
serve) and continue running the Kernel thread I described. my questions is ,
how a windows O/S manage to return back to the highest (non-interrupt) IRQL
and serve back this thread ?
Step 1 : saving IRQL before change
Step 2 : verify if new IRQL as lower then 2(DISPATCH_LEVEL)
Step 3/5 : in case lower , change IRQL to new IRQL
Step 4 : in case higher then DISPATCH_LEVEL , change the IMR(Interrupt Mask
register) at the PIC to avoid receiving interrupts which are lower or equal
to the specific raised IRQL.
my question is , why is it possible to raise IRQL to higher then
DISPATCH_LEVEL , I was amazed to see a change of the IMR while a driver
raised IRQL.
Is there somthing I just dont understand here ? is there any reason that a
driver will raise the IRQL to an Hardware Interrupt level ?
assume a Kernel thread which working at IRQL == DISPATCH_LEVEL is
currently been served. meanwhile , an Interrupt as arrived and an ISR
as been called. after the ISR as finish and the interrupt as been
served, the O/S should return to DISPATCH_LEVEL (or there are other
interrupts higher to serve) and continue running the Kernel thread I
described. my questions is , how a windows O/S manage to return back
to the highest (non-interrupt) IRQL and serve back this thread ?
How? It does an “iret”.
This question as alittle bit more complicated
…
my question is , why is it possible to raise IRQL to higher then
DISPATCH_LEVEL , I was amazed to see a change of the IMR while a
driver raised IRQL.
Is there somthing I just dont understand here ? is there any reason
that a driver will raise the IRQL to an Hardware Interrupt level ?
Sure. What if you have a spinlock protecting data that is shared with
your interrupt handler? Your interrupt handler runs at the hardware
IRQL. Unless my understanding is incorrect, this is exactly what
KeSynchronizeExecution and KeAcquire/KeReleaseInterruptSpinLock do.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 3/2/06, Tim Roberts wrote: > > Alex Green wrote: > > > I have number of questions regards IRQL. > > 1. assume a Kernel thread which working at IRQL == DISPATCH_LEVEL is > > currently been served. meanwhile , an Interrupt as arrived and an ISR > > as been called. after the ISR as finish and the interrupt as been > > served, the O/S should return to DISPATCH_LEVEL (or there are other > > interrupts higher to serve) and continue running the Kernel thread I > > described. my questions is , how a windows O/S manage to return back > > to the highest (non-interrupt) IRQL and serve back this thread ? > > > How? It does an “iret”.
I Understand that iret will return the EIP to the original location. but who will return the IRQL to the original IRQL ? is this done automaticlly ? or the OS resposiblity ?
> 2. This question as alittle bit more complicated > > … > > my question is , why is it possible to raise IRQL to higher then > > DISPATCH_LEVEL , I was amazed to see a change of the IMR while a > > driver raised IRQL. > > > > Is there somthing I just dont understand here ? is there any reason > > that a driver will raise the IRQL to an Hardware Interrupt level ? > > > Sure. What if you have a spinlock protecting data that is shared with > your interrupt handler? Your interrupt handler runs at the hardware > IRQL. Unless my understanding is incorrect, this is exactly what > KeSynchronizeExecution and KeAcquire/KeReleaseInterruptSpinLock do.
Yes you understand it correctly, I had this information missing probobly because I was never shared resources with my interrupt handler and allways register for DPC.
On 3/2/06, *Tim Roberts* > wrote: > > > How? It does an “iret”. > > > I Understand that iret will return the EIP to the original location. > but who will return the IRQL to the original IRQL ? > is this done automaticlly ? or the OS resposiblity ?
The kernel code that cleans up after interrupt handler will reset the IRQL just before it does the iret.
– Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
