I do not have access to remote windbg right now, so below my question.
Does the IRQL gets raised to DIRQL irrespective of whether KMDF driver supplies (the optional) EvtInterruptEnable/Disable () handlers?
Seems it would be better to only Raise (and lower later) IRQL only if those handlers are supplied by the driver ?
I have 32 MSIX and assuming raise/lower irql ops are still expensive on AMD64, such a thing would lessen the transition time (D0<–>Dx) ?
DIRQL is only raised if the driver has provided an Enable or Disable callback. DIRQL is raised by _SynchronizeExecution calling KeSynchronizeExecution Calls to _SynchronizeExecution are guarded by a NULL check of the respective driver supplied callback.
Peter
After/Before D0Entry/D0Exit, Fx will connect/disconnect interrupt, Raise IRQL to DIRQL, call EvtInterruptEnable/Disable, lower to PASSIVE and then eventually call PostInterruptsEnabled/Disabled()
Team had report that with multiple(32) MSI-X, they were getting PostInterruptsEnabled() very late.
Told team to supply NULL InterruptEnable/Disable() handler(), which would rule out any Fx issue. They still reported delay. Told team to test with INTx or 1 MSI-X and probably issue is in my driver itself.
In meantime, just wanted to re-confirm from here, if I supplied NULL handlers to EvtInterruptEnable/Disable(), of course Fx will not raise(/lower) IRQL, which would be unnecessary. Hence my question.
Sorry if above again just sounds like MSDN re-hash and didn’t answer the question.
–MSDN
Before calling the EvtInterruptEnable callback function, the framework raises the processor’s IRQL to the device’s DIRQL and acquires the spin lock that the driver specified in the interrupt object’s WDF_INTERRUPT_CONFIG structure.
Thank you for taking the time to explain. I understand now what you’re asking.
assuming raise/lower irql ops are still expensive on AMD64
You know, just FYI, they aren’t necessarily expensive. Exactly how IRQL is handled varies a great deal from version to version of Windows. I don’t know what they’re doing in 2004 for AMD64. At one point, they were doing “lazy IRQL” where the IRQL was,logically changed but not reprogrammed in the hardware unless an interrupt that should have been masked actually occurred.