ReactOS实现的兼容NT内核分析--KfLowerIrql函数

前端之家收集整理的这篇文章主要介绍了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级别的角度来 说是异步抢占的,在高级别他必须显式地执行代码来实现异步抢占,细粒度观察其实还是同步执行的。

猜你在找的React相关文章