Hi all,
I’m new to the Windows driver development. My understanding with the IRQL
is, each processor can run at different IRQLs. And we can find the current
Irql of the processor, by executing KeGetCurrentIrql from the thread running
in the processor.
But when I disassemble ‘hal!KeGetCurrentIrql’, I see its retrieving the
information from ds:[0FFDFF024h].
My question is,
Is the IRQL information for all the processor is stored as linked list at
0FFDFF024h. Or is it different? How they are managing IRQL information of
all the processor?
–
Regards,
T.V.Gokul.
Assuming APIC HAL, IRQL is just an index into the array of values to be written to CPU’s TPR, so that they may use a common array to store these values… However, please note that the fact of all CPUs referring to the same physical address does not necessarily imply that it is actually the same physical location - it depends on whether a given address corresponds to RAM/memory-mapped device or to on-chip memory. For example, every CPU has its own local APIC that it accesses as a physical memory at the base address of 0xFEE00000. Therefore, when CPUs X and Y write to the physical address of, say, 0xFEE0080 (which is local APIC’s TPR) it does not mean that they write to the same memory location…
Anton Bassov
Except that the OP claims the address referenced is 0FFDFF024h.
On Sat, May 10, 2008 at 12:32 PM, wrote:
> Assuming APIC HAL, IRQL is just an index into the array of values to be
> written to CPU’s TPR, so that they may use a common array to store these
> values… However, please note that the fact of all CPUs referring to the
> same physical address does not necessarily imply that it is actually the
> same physical location - it depends on whether a given address corresponds
> to RAM/memory-mapped device or to on-chip memory. For example, every CPU has
> its own local APIC that it accesses as a physical memory at the base
> address of 0xFEE00000. Therefore, when CPUs X and Y write to the physical
> address of, say, 0xFEE0080 (which is local APIC’s TPR) it does not mean that
> they write to the same memory location…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
“Mark Roddy” wrote in message news:xxxxx@ntdev…
Except that the OP claims the address referenced is 0FFDFF024h.
This address is used for the UP HAL (when there’s only one CPU anyway)
–PA
On Sat, May 10, 2008 at 12:32 PM, wrote:
Assuming APIC HAL, IRQL is just an index into the array of values to be written to CPU’s TPR, so that they may use a common array to store these values… However, please note that the fact of all CPUs referring to the same physical address does not necessarily imply that it is actually the same physical location - it depends on whether a given address corresponds to RAM/memory-mapped device or to on-chip memory. For example, every CPU has its own local APIC that it accesses as a physical memory at the base address of 0xFEE00000. Therefore, when CPUs X and Y write to the physical address of, say, 0xFEE0080 (which is local APIC’s TPR) it does not mean that they write to the same memory location…
Anton Bassov
—
–
Mark Roddy
> Except that the OP claims the address referenced is 0FFDFF024h.
… which implies that he speaks about the index into the array that holds values to be written to TPR and not about the value in TPR itself. You can arrive to this conclusion based solely upon the last three hex digits that represent an offset into the page - if it was TPR, the page base virtual address might be anything the OS chooses, but the offset would still have to be 0x80. This array may reside in main memory so that it is physically the same for all CPUs. However, this index has to be stored the CPU’s local memory, for understandable reasons, so that the virtual address 0FFDFF024h is backed not by a physical address in the main memory but by some CPU-specific physical address that may be numerically the same for all CPUs but still refer to different locations ( physical address of local APIC is a typical example of such address)
Schematically KeRaiseIrql() and KeGetCurrentIrql() work the following way:
KeRaiseIrql()
{
_asm
{
;new IRQL is in ECX
MOV EAX, [GLOBAL_ARRAY+ECX]; load the value to be written to TPR into EAX
MOV [LocalApicBaseAddres+0x80], EAX; update TPR
; retrieve previous IRQL from CPU-specific location and store it in EAX - we are going to return it
MOV EAX, [0FFDFF024h]
MOV[0FFDFF024h],ECX ;save current IRQL in CPU-specific location
RET
}
}
KeGetCurrentIrql()
{
// get index that we have saved earlier in CPU-specific location and return it
_asm MOV EAX, [0FFDFF024h]
}
Anton Bassov
> But when I disassemble ‘hal!KeGetCurrentIrql’, I see its retrieving the
information from ds:[0FFDFF024h].
I think this is the Task Priority Register of the local APIC.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> I think this is the Task Priority Register of the local APIC.
Cannot be the one…
Local APIC maps into a single page, so that its base virtual address has to be xxxxx000. TPR is located at the offset 0x80 from the APIC base address, so its address has to be xxxxx080 . However, the address the OP speaks about is just at the offset 0x24 from the beginning of its page. Therefore, we can conclude that it just cannot correspond to TPR…
Anton Bassov
I wonder what is the full asm listing of OP version of KeGetCurrentIrql. In
my case it is (XP SP2, MPS):
.text:80012428 mov eax, ds:0FFFE0080h
.text:8001242D shr eax, 4
.text:80012430 movzx eax, ds:byte_8001D298[eax]
.text:80012437 retn
Which is something predictable, because the default address of local APIC is
0xFEE00000, so the code is retreiving the vector priority from APIC[TPR]
(which is 0FFFE0080h) and then mapping it into IRQL which is returned in
eax.
–
V.
This posting is provided “AS IS” with no warranties, and confers no
rights.
wrote in message news:xxxxx@ntdev…
>> I think this is the Task Priority Register of the local APIC.
>
> Cannot be the one…
>
> Local APIC maps into a single page, so that its base virtual address has
> to be xxxxx000. TPR is located at the offset 0x80 from the APIC base
> address, so its address has to be xxxxx080 . However, the address the OP
> speaks about is just at the offset 0x24 from the beginning of its page.
> Therefore, we can conclude that it just cannot correspond to TPR…
>
> Anton Bassov
>
Sorry, I did a mistake, in the sentence “because the default address of
local APIC is
0xFEE00000”. The correct address is 0xFFFE0000.
–
V.
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev…
>I wonder what is the full asm listing of OP version of KeGetCurrentIrql. In
>my case it is (XP SP2, MPS):
>
> .text:80012428 mov eax, ds:0FFFE0080h
> .text:8001242D shr eax, 4
> .text:80012430 movzx eax, ds:byte_8001D298[eax]
> .text:80012437 retn
>
> Which is something predictable, because the default address of local APIC
> is 0xFEE00000, so the code is retreiving the vector priority from
> APIC[TPR] (which is 0FFFE0080h) and then mapping it into IRQL which is
> returned in eax.
>
> –
> V.
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
> wrote in message news:xxxxx@ntdev…
>>> I think this is the Task Priority Register of the local APIC.
>>
>> Cannot be the one…
>>
>> Local APIC maps into a single page, so that its base virtual address has
>> to be xxxxx000. TPR is located at the offset 0x80 from the APIC base
>> address, so its address has to be xxxxx080 . However, the address the OP
>> speaks about is just at the offset 0x24 from the beginning of its page.
>> Therefore, we can conclude that it just cannot correspond to TPR…
>>
>> Anton Bassov
>>
>
>
>
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> But when I disassemble ‘hal!KeGetCurrentIrql’, I see its retrieving the
>> information from ds:[0FFDFF024h].
>
> I think this is the Task Priority Register of the local APIC.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
Some sources on the web say that it is KPCR.Irql, and is used in UP systems.
–PA
Thanks for all your inputs.
One more question related to this topic. IIRC, the IRQLs are also stored in
the PCR; in such case, why should we need to query the (LOCAL) APIC for
getting the IRQL? Is it just a implementation method?
Moreover, will there be any waiting cycles or performance hit, on accessing
Local APIC (even if we are not an IN/OUT opcodes)? Like Local APIC raising
the HOLD signal of the processor?
One other curious question, where can we find these informations like,
(memory mapped) address range of LOCAL APIC & other hardwares?
I understand this is one of the FAQ/redundant question in this forum, but I
dint find these in-depth informations from the book I used to read!
Sorry for digressing the topic of this thread.
On Sat, May 10, 2008 at 10:02 PM, wrote:
> Assuming APIC HAL, IRQL is just an index into the array of values to be
> written to CPU’s TPR, so that they may use a common array to store these
> values… However, please note that the fact of all CPUs referring to the
> same physical address does not necessarily imply that it is actually the
> same physical location - it depends on whether a given address corresponds
> to RAM/memory-mapped device or to on-chip memory. For example, every CPU has
> its own local APIC that it accesses as a physical memory at the base
> address of 0xFEE00000. Therefore, when CPUs X and Y write to the physical
> address of, say, 0xFEE0080 (which is local APIC’s TPR) it does not mean that
> they write to the same memory location…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Regards,
T.V.Gokul.
> One other curious question, where can we find these informations like, (memory mapped)
address range of LOCAL APIC & other hardwares?
Volume 3 of Intel Developer’s Manual is the main source of info. In addition to that, you may also want to check other documentation that is available from Intel site (IOAPIC Manual, MP Specifications, etc)…
Anton Bassov
Thanks a lot Anton.
On Mon, May 12, 2008 at 10:44 AM, wrote:
> > One other curious question, where can we find these informations like,
> (memory mapped)
> >address range of LOCAL APIC & other hardwares?
>
> Volume 3 of Intel Developer’s Manual is the main source of info. In
> addition to that, you may also want to check other documentation that is
> available from Intel site (IOAPIC Manual, MP Specifications, etc)…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Regards,
T.V.Gokul.