ReactOS实现的兼容NT内核分析--KfLowerIrql函数
本文代码来自ReactOS-0.3.6。 当硬件中断完成后将要返回的时候,将要调用KfLowerIrql来使当前cpu的irql降低到中断发生前的irql,但是真的就是直接降低到原来优先级就完事了吗?我们看看代码(桩代码,待会分析真正的): VOID HalpLowerIrql(KIRQL NewIrql) { if (NewIrql >= PROFILE_LEVEL)//如果原来的优先级过高,啥也不说,直接恢复irql,然后返回 { KeGetPcr()->Irql = NewIrql; return; } HalpExecuteIrqs(NewIrql);//这个函数没什么用,可能是原来的实现吧,这个函数处理未决挂起的硬件中断 if (NewIrql >= DISPATCH_LEVEL)//如果原来irql在dispatch之上,那么返回,由此可知上面函数仅仅是个桩 { KeGetPcr()->Irql = NewIrql; return; } KeGetPcr()->Irql = DISPATCH_LEVEL;//从dispatch开始,因为到此处,原来irql肯定小于dispatch if (((PKIPCR)KeGetPcr())->HalReserved[HAL_DPC_REQUEST]) { ((PKIPCR)KeGetPcr())->HalReserved[HAL_DPC_REQUEST] = FALSE; KiDispatchInterrupt(); } KeGetPcr()->Irql = APC_LEVEL;//往下依次处理irql递减的回调 if (NewIrql == APC_LEVEL) { return; } if (KeGetCurrentThread() != NULL && KeGetCurrentThread()->ApcState.KernelApcPending) { KiDeliverApc(KernelMode,NULL,NULL); } KeGetPcr()->Irql = PASSIVE_LEVEL; } 从上面函数可知,并不是直接恢复原来的irql,而是依次按照优先级处理未决的虚拟中断。一不做二不休,姑且看一看那个没有什么用的函数: VOID HalpExecuteIrqs(KIRQL NewIrql) { ULONG IrqLimit,i; IrqLimit = min(PROFILE_LEVEL - NewIrql,NR_IRQS); /* * For each irq if there have been any deferred interrupts then now * dispatch them. */ for (i = 0; i < IrqLimit; i++) { if (HalpPendingInterruptCount[i] > 0) { KeGetPcr()->Irql = (KIRQL)IRQ_TO_DIRQL(i); while (HalpPendingInterruptCount[i] > 0) { /* * For each deferred interrupt execute all the handlers at DIRQL. */ HalpPendingInterruptCount[i]--; //HalpHardwareInt[i]();//不知为什么被注释了,这样不挺好吗? } //KeGetPcr()->Irql--; //HalpEndSystemInterrupt(KeGetPcr()->Irql); } } } HalpLowerIrql 很重要,整个系统的每个部分都有它的身影,实际上,就是它实现了虚拟中断控制器的重要部分,可畏的是,nt内核竟然实现的如此巧妙,以至于程序员不需要面 对真正的硬件处理而只需要面对irql就可以了,下面我们看看ms在x86下的kflowerirql源代码: VOID FASTCALL KfLowerIrql (KIRQL NewIrql) { KIRQL oldIrql = KeGetCurrentIrql(); if (NewIrql > oldIrql) { DPRINT1 ("NewIrql %x CurrentIrql %x/n",NewIrql,oldIrql); KEBUGCHECK (0); } HalpLowerIrql (NewIrql,FALSE);//Kf函数仅仅是Hal的包装函数,实现一些检查,不通过就蓝! } VOID HalpLowerIrql(KIRQL NewIrql,BOOLEAN FromHalEndSystemInterrupt) { 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])); //读取一个位,以检测是否有软件中断发生,这个位是在Request软件中断的函数里面设置的。 if (FromHalEndSystemInterrupt || DpcRequested) { __writefsbyte(FIELD_OFFSET(KIPCR,HalReserved[HAL_DPC_REQUEST]),0); _enable(); KiDispatchInterrupt();//分发dpc过程,实际上就是一个一个执行。最后再看看有没有需要切换的线程 if (!(Flags & EFLAGS_INTERRUPT_MASK)) { _disable(); } } KeSetCurrentIrql (APC_LEVEL); } if (NewIrql == APC_LEVEL) { return; } if (KeGetCurrentThread () != NULL && KeGetCurrentThread ()->ApcState.KernelApcPending)//注意,apc在费任意线程上下文进行,所以apc级别往下就不能什么都揉在一起了,就要按照进程分别对待了。 { _enable(); KiDeliverApc(KernelMode,NULL); if (!(Flags & EFLAGS_INTERRUPT_MASK)) { _disable(); } } KeSetCurrentIrql (PASSIVE_LEVEL); } 对 比一下两个kflowerirql,都是一级一级 往下跳变,根本不是直接就降到原来的优先级的。软件毕竟不是硬件,可以真正神不知鬼不觉地实现抢占,它只是在用户的角度,在passtive级别的角度来 说是异步抢占的,在高级别他必须显式地执行代码来实现异步抢占,细粒度观察其实还是同步执行的。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |