Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
In wdm.h, some IRQL are defined, and i use them in function KeRaiseIrql , this is not a problem. The Problem is that when i have a new device installed on PCIe, and there must be interrupt from this hardware device. is it the device driver to define new IRQL? or OS will define it after bootup?
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
Windows assigns the device an IRQL “automatically” when it wires-up the device to the IDT... which happens when your driver connects to interrupts from the device.
There’s nothing you need to do to make this happen, other than write your driver the usual way.
Peter
Peter Viscarola
OSR
@OSRDrivers
Thx @Peter_Viscarola_(OSR)
How can i know what the IRQL value is?
i want to do some KeRaiseIrql to the level to block the interrupt from this particular device.
You don’t. When you want to raise to your device IRQL you use KeAcquireInterruptSpinLock ... or WdfInterruptAcquireLock.
These not only raise the IRQL but also acquire the spin lock that’s used to serialize execution of your ISR.
Peter
Peter Viscarola
OSR
@OSRDrivers
Are you actually trying to synchronize things here? Remember that raising the IRQL only affects the one CPU on which you are running. Interrupts can still be fired on another CPU. That's why we use a spin lock.
If you really want to stop the device from interrupting, you have to find and disable the "interrupt enable" bit in the device's registers.
Tim Roberts, [email protected]
Software Wizard Emeritus
thx @Tim_Roberts and @Peter_Viscarola_(OSR) so spin lock will lock the bus ? i recall that the book windows internal says something about a type of lock that can lock the bus. am i right about spin lock?
You say "the bus" as if there was only one. No, the spin lock is a CPU thing. When a process grabs a spin lock, any other process that tries to grab it will block.
Tim Roberts, [email protected]
Software Wizard Emeritus
In SMP , When a process running on processor A grabs a spin lock, any other process running on processor B that tries to grab it will block too ?
Yes, that's the point.
Tim Roberts, [email protected]
Software Wizard Emeritus
Not just SMP, but any MP environment - but that is beyond the scope of Windows - except that NUMA technically breaks the symmetric part to some extent
Well, it is not going to "block" in a sense that the term "blocking" is normally used in OS-level lingo. What it is going to do is to spin in an idle do-nothing loop until the lock gets released. No context switches are going to take place on a given CPU meanwhile, because it is going to spin at elevated IRQL. Therefore, spinlocks have to be used judiciously, which is particularly true for the large systems with the large number of logical processors....
Anton Bassov
The very first thing that comes up to my mind when I see the lines like that is our discussion of this topic with Alberto - he believed that one might lock a bus with some "bus-level lock" that might span across multiple instructions .......
Anton Bassov
thx @anton_bassov