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过程。

DPC分析 基于ReactOS0.33

相关文章

DPC分析基于ReactOS0.33