Hi all,
I have a doubt on Interrupt handling.
1.My understanding was that, when an interrupt occurs, processor picks up
the ISR address from the Interrupt descriptor table and executes it. When we
register a interrupt handler does it actually modify interrupt descriptor
table?
2.In the OSR article “Of PICs and APICs”, I read that OS calls all the
interrupt handlers registered for that particular interrupt number,
How can the OS call multiple interrupt handlers?
Thanks and regards,
Madhu
Madhusudan Narayan wrote:
I have a doubt on Interrupt handling.
1.My understanding was that, when an interrupt occurs, processor picks
up the ISR address from the Interrupt descriptor table and executes
it. When we register a interrupt handler does it actually modify
interrupt descriptor table?
Possibly, but not necessarily. The IDT entries all point into NT kernel
code. The kernel code looks in its own internal tables to discover if
some driver has called IoConnectInterrupt and calls the ISR. Thus, the
address in the IDT is not really your ISR. It’s a very short piece of
kernel code that calls your ISR.
I don’t know if the kernel makes IDT entries for all possible interrupts
at boot time, or if it just adds itself when it learns of an interrupt.
If it is the former, then the IDT won’t change as you register and
unregister for interrupts.
2.In the OSR article “Of PICs and APICs”, I read that OS calls all the
interrupt handlers registered for that particular interrupt number,
How can the OS call multiple interrupt handlers?
Why do you think this would be hard? Every time someone calls
IoConnectInterrupt for a particular IRQ, an entry is added to the list
of handlers for that IRQ. The kernel’s ISR just runs through that list,
calling each of the handlers in turn, until one of them returns “true”
indicating that the interrupt belonged to them.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I think that the IDT entry points to some thunk code, which in turn calls
all ISRs registered for this vector one by one.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Madhusudan Narayan” wrote in message
news:xxxxx@ntdev…
> Hi all,
>
> I have a doubt on Interrupt handling.
>
> 1.My understanding was that, when an interrupt occurs, processor picks up
> the ISR address from the Interrupt descriptor table and executes it. When we
> register a interrupt handler does it actually modify interrupt descriptor
> table?
>
> 2.In the OSR article “Of PICs and APICs”, I read that OS calls all the
> interrupt handlers registered for that particular interrupt number,
> How can the OS call multiple interrupt handlers?
>
>
>
> Thanks and regards,
> Madhu
>
>1.My understanding was that, when an interrupt occurs, processor picks up
the ISR address from the Interrupt descriptor table and executes it.
This is wrong…
IDT keeps the addresses of interrupt handlers, rather than of ISRs. Typical interrupt handler is just a stub that saves execution context, finds the address of ISR, raises IRQL to the DIRQL, and then
transfers execution to ISR. As you can see, quite a few things have to be done before ISR can start execution. If interrupt vector is shared (IOAPIC allows you to map mutiple IRQs to the same interrupt vector), interrupt handler calls all ISRs that correspond to given vector, until the very first call that returns TRUE
Hopefully, by now you already know answers to the remaining questions…
Anton Bassov
Hi Anton,
I if have a kernel mode driver which just wants to be notified of the
interrupt, and registers an ISR for the same vector that some specific
driver XYZ has registered for.
Now if interrupt handler calls the ISR registered by the driver XYZ, and
that ISR returns true, the ISR that I have registered will not be called at
all.
My ISR just wants to know whether that particular interrupt has occured. Is
there any way to do that?
regards,
Madhu
On 12/24/06, xxxxx@hotmail.com wrote:
>
> >1.My understanding was that, when an interrupt occurs, processor picks up
> > the ISR address from the Interrupt descriptor table and executes it.
>
> This is wrong…
>
> IDT keeps the addresses of interrupt handlers, rather than of ISRs.
> Typical interrupt handler is just a stub that saves execution context, finds
> the address of ISR, raises IRQL to the DIRQL, and then
> transfers execution to ISR. As you can see, quite a few things have to be
> done before ISR can start execution. If interrupt vector is shared (IOAPIC
> allows you to map mutiple IRQs to the same interrupt vector), interrupt
> handler calls all ISRs that correspond to given vector, until the very first
> call that returns TRUE
>
>
> Hopefully, by now you already know answers to the remaining questions…
>
> Anton Bassov
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Not really, not within the defined architecture. The model is that one
driver in a device node, typically the function driver, owns the interrupt
and that sharing is between device nodes not within device nodes. That said,
if you can guarantee that your ISR is in front of the real owner you will be
ok. On the other hand, this is a peculiar requirement and perhaps whatever
it is you are trying to do that has lead you to conclude that getting
notified of a particular interrupt is the right solution has some other more
legitimate solution.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Wednesday, December 27, 2006 12:07 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Need a clarification on Interrupt handling
Hi Anton,
I if have a kernel mode driver which just wants to be notified of the
interrupt, and registers an ISR for the same vector that some specific
driver XYZ has registered for.
Now if interrupt handler calls the ISR registered by the driver XYZ, and
that ISR returns true, the ISR that I have registered will not be called at
all.
My ISR just wants to know whether that particular interrupt has occured. Is
there any way to do that?
regards,
Madhu
On 12/24/06, xxxxx@hotmail.com wrote:
>1.My understanding was that, when an interrupt occurs, processor picks up
> the ISR address from the Interrupt descriptor table and executes it.
This is wrong…
IDT keeps the addresses of interrupt handlers, rather than of ISRs. Typical
interrupt handler is just a stub that saves execution context, finds the
address of ISR, raises IRQL to the DIRQL, and then
transfers execution to ISR. As you can see, quite a few things have to be
done before ISR can start execution. If interrupt vector is shared (IOAPIC
allows you to map mutiple IRQs to the same interrupt vector), interrupt
handler calls all ISRs that correspond to given vector, until the very first
call that returns TRUE
Hopefully, by now you already know answers to the remaining questions…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@hotmail.com wrote:
> 1.My understanding was that, when an interrupt occurs, processor picks up
> the ISR address from the Interrupt descriptor table and executes it.
>This is wrong…
IDT keeps the addresses of interrupt handlers, rather than of ISRs. Typical interrupt handler is just a stub that saves execution context, finds the address of ISR, raises IRQL to the DIRQL, and then
transfers execution to ISR.
You can’t really say “this is wrong”; it is just a matter of
terminology. In the general computing world, an ISR is a routine that
gets executed when an interrupt occurs. The kernel’s interrupt handlers
qualify under that definition. It is only in the NT world that ISR has
taken on the additional specific meaning of “a callback routine
registered using IoConnectInterrupt”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
I see what you mean, but when we speak about NT-based system we have no option, other than using 2 terms (i.e. ISR and interrupt handler) that have a different meaning in this context, although in any other context they are synonimous . When we speak about NT-based system saying that addresses of ISRs are in IDT is simply wrong…
Anton Bassov
> Hi Anton,
I if have a kernel mode driver which just wants to be notified of the
interrupt, and registers an ISR for the same vector that some specific
driver XYZ has registered for.
Now if interrupt handler calls the ISR registered by the driver XYZ, and
that ISR returns true, the ISR that I have registered will not be called at all.
My ISR just wants to know whether that particular interrupt has occured. Is
there any way to do that?
regards,
Madhu
Madhu.
If your ISR does not get called, in means that this particular interrupt has nothing to do with your device. Therefore, the system does not provide any way to do what you want - if you really need it, you have no option, other than going around the OS and hooking IDT.
However, before you do it, just ask yourself a question - do I really need it??? There is a good chance that, after a bit of thinking, you will decide that this is not what you need. If you don’t mind telling us a little bit more about your objective, probably, we would be able to propose you some legitimate solution
Anton Bassov
Anton,
There is display driver, and it responds to plug/unplug of display devices.
I need to log in addition to other events, plug/unplug events(which
generates interrupts). So I thought of writing a kernel mode driver which
“sniffs” every interrupt generated by the display adapter.
This logging will not always be done. This driver might start recording
events on a hotkey and stops recording on some other hotkey. I’ll be using
this recorded information to reproduce a particular sequence of events.
Is there anyway I can do it?
regards,
Madhu
On 12/28/06, xxxxx@hotmail.com wrote:
>
>
> > Hi Anton,
>
> > I if have a kernel mode driver which just wants to be notified of the
> > interrupt, and registers an ISR for the same vector that some specific
> > driver XYZ has registered for.
> > Now if interrupt handler calls the ISR registered by the driver XYZ,
> and
> > that ISR returns true, the ISR that I have registered will not be called
> at all.
> > My ISR just wants to know whether that particular interrupt has occured.
> Is
> > there any way to do that?
>
>
> > regards,
> > Madhu
>
> Madhu.
>
> If your ISR does not get called, in means that this particular interrupt
> has nothing to do with your device. Therefore, the system does not provide
> any way to do what you want - if you really need it, you have no option,
> other than going around the OS and hooking IDT.
>
> However, before you do it, just ask yourself a question - do I really need
> it??? There is a good chance that, after a bit of thinking, you will decide
> that this is not what you need. If you don’t mind telling us a little bit
> more about your objective, probably, we would be able to propose you some
> legitimate solution
>
> Anton Bassov
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Madhu,
Unfortumately, I cannot propose a precise solution, because I am not familiar with display architecture, but I can tell you how these problems are normally handled…
Forget about interrupts - normally the whole thing is done simply by writing PnP-compliant filter driver, and filter drivers dont implement ISRs (ISRs are normally used only by port and miniport drivers). Your filter will be informed about device removal by IRP_MN_SURPRISE_REMOVAL, and when device is inserted, its AddDevice() routine will be called. Therefore, there is no problem with logging insertion/removal events from your filter driver - dealing with interrupts is not needed here
This is a general idea. For more precise advice, you have to wait for Tim’s response - he is an expert on display architecture
Anton Bassov