DPC分析 基于ReactOS0.33

前端之家收集整理的这篇文章主要介绍了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过程。

猜你在找的React相关文章