DPC分析 基于ReactOS0.33

    windows的过程，有如linux的软中断。以前Linux内核中自旋锁同步分析提到过，Linux通过IN_HARDIRQ/IN_SOFTIRQ来屏蔽软中断的执行，windows其实也类似，偷梁换柱的用IRQL来代替这些概念:IRQL高于DPC_LEVEL时，DPC过程无法执行，因为可能是中断过程正在执行；当通过KfLowerIrql降低IRQL请求级别到DPC_LEVEL及以下时开始执行DPC过程。降的再狠点，降到APC_LEVEL之下，还能执行APC请求。

    ReactOS中关于DPC的执行流程相比与其他模块极其简单，因此本文只罗列大概流程，并不贴出代码。首先关于DPC对象的产生，设备对象初始化时可能会调用KiInitializeDpc，该函数仅仅设置执行DPC的过程和相应的参数，然后就结束了。设备对象可能会把该Dpc对象保存在自己的设备扩展部中，供以后使用。以后是指什么？当然是指发生中断而进入中断处理函数时，会调用KeInsertQueueDpc把Dpc对象插入到CPU控制模块Prcb!DpcData队列：

KDPC对象

typedef struct _KDPC{    UCHAR Type;    UCHAR Importance;    USHORT Number;    LIST_ENTRY DpcListEntry;    PKDEFERRED_ROUTINE DeferredRoutine;    PVOID DeferredContext;    PVOID SystemArgument1;    PVOID SystemArgument2;//指向所挂入的KDPC_DATA结构，Prcb//上有两个KDPC_DATA(DPC)请求队列，一个是//普通的一个是DPC线程化的    volatile PVOID  DpcData;} KDPC, *PKDPC, *RESTRICTED_POINTER PRKDPC;

KeInsertQueueDpc代码片段：

KeRaiseIrql(HIGH_LEVEL, &OldIrql);CurrentPrcb = KeGetCurrentPrcb();//获得当前CPU的Prcb.../*    从Prcb的两个DpcData队列中选一个，将请求的Dpc挂到其中    */    /* Check if this is a threaded DPC and threaded DPCs are enabled */    if ((Dpc->Type == ThreadedDpcObject) && (Prcb->ThreadDpcEnable))    {        /* Then use the threaded data */        DpcData = &Prcb->DpcData[DPC_THREADED];    }    else    {        /* Otherwise, use the regular data */        DpcData = &Prcb->DpcData[DPC_NORMAL];    }...KiAcquireSpinLock(&DpcData->DpcLock);//同个CPU的互斥，因为要插入队列..Dpc->SystemArgument1 = SystemArgument1;        Dpc->SystemArgument2 = SystemArgument2;        DpcData->DpcQueueDepth++;        DpcData->DpcCount++;        DpcConfigured = TRUE;        /* Check if this is a high importance DPC */        if (Dpc->Importance == HighImportance)        {            /* Pre-empty other DPCs */            InsertHeadList(&DpcData->DpcListHead, &Dpc->DpcListEntry);        }        else        {            /* Add it at the end */            InsertTailList(&DpcData->DpcListHead, &Dpc->DpcListEntry);        }//插入队列结束，释放互斥锁KiReleaseSpinLock(&DpcData->DpcLock);...//最后发出DPC请求，当然DPC不会立马得到执行/*            正式发出请求，等到cpu从高IRQL降到DPC以下时，            内核扫描并执行队列中的DPC函数，如处理完            中断后调用KfLowerIrql时，据说扫描并执行DPC队列            也是线程切换的时机，这么说KiSwapContext是在DPC级别的            切换完了，IRQL再降级，才有机会执行APC            */            HalRequestSoftwareInterrupt(DISPATCH_LEVEL);

DPC的产生和请求都有了，那什么时候才是投递执行的时候？前面说了要等到IRQL下降，一般由调用者主动调用KfLowerIrql降低IRQL，借此机会DPC过程得以执行.

KfLowerIrql的内部实现是HalpLowerIrql，所以有必要进去浏览一下：

VOID HalpLowerIrql(KIRQL NewIrql, BOOLEAN FromHalEndSystemInterrupt){//执行Dpc/线程切换/Apc/的大好时机  ULONG Flags;  UCHAR DpcRequested;  if (NewIrql >= DISPATCH_LEVEL)    {      KeSetCurrentIrql (NewIrql);      APICWrite(APIC_TPR, IRQL2TPR (NewIrql) & APIC_TPR_PRI);      return;    }  Ke386SaveFlags(Flags);  if (KeGetCurrentIrql() > APC_LEVEL)    {      KeSetCurrentIrql (DISPATCH_LEVEL);      APICWrite(APIC_TPR, IRQL2TPR (DISPATCH_LEVEL) & APIC_TPR_PRI);      DpcRequested = __readfsbyte(FIELD_OFFSET(KIPCR, HalReserved[HAL_DPC_REQUEST]));      if (FromHalEndSystemInterrupt || DpcRequested)        {        //以前在中断处理中发出的Dpc请求，现在要关闭          __writefsbyte(FIELD_OFFSET(KIPCR, HalReserved[HAL_DPC_REQUEST]), 0);          _enable();  //投递Dpc          KiDispatchInterrupt();          if (!(Flags & EFLAGS_INTERRUPT_MASK))            {              _disable();            }}      KeSetCurrentIrql (APC_LEVEL);    }  if (NewIrql == APC_LEVEL)    {      return;    }  if (KeGetCurrentThread () != NULL &&       KeGetCurrentThread ()->ApcState.KernelApcPending)    {    //投递APC      _enable();      KiDeliverApc(KernelMode, NULL, NULL);      if (!(Flags & EFLAGS_INTERRUPT_MASK))        {          _disable();        }    }  KeSetCurrentIrql (PASSIVE_LEVEL);}

投递Dpc还是在KiDispatchInterrupt中完成。这里有个疑问，希望路过的大神解答就是：ReactOS处理中断用了线程的堆栈，而处理Dpc使用Dpc专用堆栈，据说说linux中断处理过程没有进程的上下文，莫非linux中断用的是tss中设置的esp0?

这个函数，除了执行dpc还有一个重要的作用，切换线程

call @KiRetireDpcList@4...call @KiSwapContextInternal@0

以前一直不知道线程切换是在哪个IRQL级别上，这回算是知道了~

最后KiRetireDpcList函数的实现很简单，就是如果有Dpc请求就遍历Prcb的Dpc队列，并执行其中的DPC过程。