EvtInterruptEnable/Disable DIRQL

NTDEV
1

Hi

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) ?

Thanks

-------- KMDF src

PFN_WDF_INTERRUPT_ENABLE EvtInterruptEnable;
PFN_WDF_INTERRUPT_DISABLE EvtInterruptDisable;

m_EvtInterruptEnable = Configuration->EvtInterruptEnable;
//
// Helper functions to enable an interrupt.
// Sequence:
// (1) InterruptEnable
// (2) _InterruptEnableThunk
// (3) InterruptEnableInvokeCallback
//

FxInterrupt::InterruptEnable(
if (m_EvtInterruptEnable) {
_SynchronizeExecution(m_Interrupt, _InterruptEnableThunk, &params);
}

FxInterrupt::_InterruptEnableThunk(
p->ReturnVal = p->Interrupt->InterruptEnableInvokeCallback();

    //
    // DIRQL interrupt handling: invoke the callback.
    //
    status = m_EvtInterruptEnable(GetHandle(), m_Device->GetHandle());
2

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.

3

I don’t even understand the question… and I REALLY don’t understand Mr. Holan’s answer.

Does the IRQL gets raised to DIRQL

Raise to DIRQL when? In which callback? I feel,like I’m coming into the middle of a conversation…

Peter

4

Thanks Doron for the confirmation.

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.

5

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.

Peter

6

Peter

I was going through this old thread few days back as well

https://www.osronline.com/ShowThread.cfm?link=191845
“Some versions of x86 hals did cache (called lazy irql), but x64 inlined the spinlock APIs so there is no way to change the functionality/behavior”

Maybe x64/AMD64 is lazy irql as well now, I see below in WDK
NTKERNELAPI
KIRQL
KfRaiseIrql (
In KIRQL NewIrql
);

Thanks