Even though PCI Express is not fully supported under XP (up to PCI 2.3),
I was
wondering if there is some other method (third party, etc) to get PCI
Express support under Windows XP?
In particular, I need full Message Signal Interrupt (MSI) protocol
support.
Thanks!
There is no MSI on XP. You can only have one type of interrupts, and OS
doesn’t know anything about MSI.
mm
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jaursch, Bill
Sent: Friday, August 10, 2007 15:55
To: Windows System Software Devs Interest List
Subject: [ntdev] PCI Express MSI support under XP?
Even though PCI Express is not fully supported under XP (up to PCI 2.3),
I was
wondering if there is some other method (third party, etc) to get PCI
Express support under Windows XP?
In particular, I need full Message Signal Interrupt (MSI) protocol
support.
Thanks!
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
I have generated MSI interrupts and also IPI interrupts, and it’s very easy. I had to do it because the initial version of my chip came with the interrupt line disconnected, and I had to overcome that limitation to carry on testing my driver.
This comes with the usual caveats, eh ? You may have to guard yourself against the possibility that the hardware may behave differently with some processor or anothe.
First you download the Intel 64 and IA32 Architectures Software Developer’s Manual, Volume 3A (System Programming Guide, Part 1). Now go to Section 8 which is about the APIC. Subsection 8.11 tells you how to generate MSI interrupts. Subsection 8.6 tells you how to generate IPI interrupts.
It’s as simple as poking the right APIC location, and better, you specify which vector you want that interrupt to be dispatched to: you can get the interrupt delivered directly to your ISR. However, I strongly suggest that when you do it you have a PCI Express VMetro between your board and the bus, so that you can actually look at what’s going on!
Hope this helps, if not chuck it.
Alberto.
----- Original Message -----
From: Jaursch, Bill
To: Windows System Software Devs Interest List
Sent: Friday, August 10, 2007 3:55 PM
Subject: [ntdev] PCI Express MSI support under XP?
Even though PCI Express is not fully supported under XP (up to PCI 2.3), I was
wondering if there is some other method (third party, etc) to get PCI
Express support under Windows XP?
In particular, I need full Message Signal Interrupt (MSI) protocol support.
Thanks!
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
> I was wondering if there is some other method (third party, etc) to get PCI
Express support under Windows XP?
As Martin told you already, there is no support for MSI under XP - if you need something like that you have to bypass HAL layer and deal with APIC ( you have to write contents of the Message Data Register to the address contained in the Message Address Register). Once your code has to be hardware-specific, it is not a very good idea to do things like that in commercial products, although you can try it if you write your software for in-house use…
Anton Bassov
Thanks for all the feedback.
I have few confirmation questions to make sure I understand the issues with a potential solution:
Strictly speaking, no - an APIC on a Windows compatible system isn’t
motherboard specific. That being said, this whole business is highly
unfriendly and really ought never exist in a commercial product.
If you mean user mode applications, no. They should not depend on
anything this low level in the kernel, unless you essentially build such
knowledge in to them.
This does not belong in anything that will ever venture outside of the
lab.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@aeshen.com
Sent: Monday, August 13, 2007 13:35
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PCI Express MSI support under XP?
Thanks for all the feedback.
I have few confirmation questions to make sure I understand the issues
with a potential solution:
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
> Strictly speaking, no - an APIC on a Windows compatible system isn’t
motherboard specific.
Well, although the code does not have to be specific to some *particular* motherboard, it still has to be hardware-specific - please don’t forget that there are still quite a few PIC-based motherboards around…
Anton Bassov
Which aren’t APIC, definitely do not support MSI, and have no place in
this discussion. I think he knows that the code is hardware specific,
mostly because he said it in his post.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, August 13, 2007 17:54
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PCI Express MSI support under XP?
Strictly speaking, no - an APIC on a Windows compatible system isn’t
motherboard specific.
Well, although the code does not have to be specific to some
*particular* motherboard, it still has to be hardware-specific - please
don’t forget that there are still quite a few PIC-based motherboards
around…
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
Well, actually, there are differences between motherboards that support
APICs. It took me many months to add MSI support in Windows Vista, and
ultimately I wasn’t the only one working on it. You won’t find one body of
code that works on every chipset, though most of it is common.
The biggest problem you’ll have, and probably one that is prohibitive, is
that you can’t easily hook into the kernel’s interrupt handling code with an
edge-triggered interrupt from a PCI device. In fact, XP is only capable of
managing an interrupt that is associated with an I/O APIC (or PIC) input.
MSI devices aren’t using an interrupt controller input.
wrote in message news:xxxxx@ntdev…
>> Strictly speaking, no - an APIC on a Windows compatible system isn’t
>> motherboard specific.
>
> Well, although the code does not have to be specific to some particular
> motherboard, it still has to be hardware-specific - please don’t forget
> that there are still quite a few PIC-based motherboards around…
>
> Anton Bassov
>
Jake,
The solution I proposed pokes at the Local APIC, which exists inside the
processor. It doesn’t use the I/O Apic. The interrupt is only “MSI” in name,
it’s internal to the processor. You can likewise generate an IPI interrupt
through the same technique. Moreover, the qword you push to the processor
includes an interrupt vector, so, you get control directly at your isr. If
the processor has a local APIC and if the physical location is the same, it
should work independently of the chip set, in fact, independent of just
about anything outside the processor.
There’s one caveat, though: in order for this to work, your device must be
able to write to the processor’s physical memory address space. My chip can,
and this has been working flawlessly for a few months now. Still, as an
insurance against possible future issues, I added a Registry entry to my
driver which reverts to polling for dma and render completions.
Alberto.
----- Original Message -----
From: “Jake Oshins”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, August 15, 2007 1:21 AM
Subject: Re:[ntdev] PCI Express MSI support under XP?
> Well, actually, there are differences between motherboards that support
> APICs. It took me many months to add MSI support in Windows Vista, and
> ultimately I wasn’t the only one working on it. You won’t find one body
> of code that works on every chipset, though most of it is common.
>
> The biggest problem you’ll have, and probably one that is prohibitive, is
> that you can’t easily hook into the kernel’s interrupt handling code with
> an edge-triggered interrupt from a PCI device. In fact, XP is only
> capable of managing an interrupt that is associated with an I/O APIC (or
> PIC) input. MSI devices aren’t using an interrupt controller input.
>
> - Jake Oshins
> Windows Kernel Team
> (author of most of the MSI code in Windows)
>
>
> wrote in message news:xxxxx@ntdev…
>>> Strictly speaking, no - an APIC on a Windows compatible system isn’t
>>> motherboard specific.
>>
>> Well, although the code does not have to be specific to some particular
>> motherboard, it still has to be hardware-specific - please don’t forget
>> that there are still quite a few PIC-based motherboards around…
>>
>> 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
Jake,
The biggest problem you’ll have, and probably one that is prohibitive, is
that you can’t easily hook into the kernel’s interrupt handling code with an
edge-triggered interrupt from a PCI device. In fact, XP is only capable of
managing an interrupt that is associated with an I/O APIC (or PIC) input.
MSI devices aren’t using an interrupt controller input.
I always thought that interrupt handler (the one in IDT) itself does not know the actual source of interrupt - it just calls all ISR that check are associated with a given vector, and their task is to check the appropriate IO registers in order to find out whether devices that they are responsible for have actually interrupted. In other words, I thought interrupt dispatching is always the same, no matter if interrupt was raised via the local APIC (i.e. write to ICR or Message Address Register), or came from the hardware device (i.e vectored via IOAPIC), or just via INT n instruction.
Was I wrong?
Anton Bassov
No, you weren’t wrong. But you can’t convince Windows XP to insert an
interrupt handler for you in your IDT unless you have an associated
interrupt controller input. This means that, to get an ISR registered for
an MSI, you’d have to hack into the IDT. And while that’s possible (though
certainly not advisable) then it becomes very, very hard to do things like
scheduling a DPC, as the kernel’s ISR stub does a lot of useful work for
you. As an example, the kernel special cases DPC queing from an ISR so that
it doesn’t have to actually schedule a DPC interrupt. Getting this right
without using any of the kernel support routines is prohibitively difficult.
wrote in message news:xxxxx@ntdev…
> Jake,
>
>> The biggest problem you’ll have, and probably one that is prohibitive, is
>> that you can’t easily hook into the kernel’s interrupt handling code with
>> an
>> edge-triggered interrupt from a PCI device. In fact, XP is only capable
>> of
>> managing an interrupt that is associated with an I/O APIC (or PIC) input.
>> MSI devices aren’t using an interrupt controller input.
>
> I always thought that interrupt handler (the one in IDT) itself does not
> know the actual source of interrupt - it just calls all ISR that check
> are associated with a given vector, and their task is to check the
> appropriate IO registers in order to find out whether devices that they
> are responsible for have actually interrupted. In other words, I thought
> interrupt dispatching is always the same, no matter if interrupt was
> raised via the local APIC (i.e. write to ICR or Message Address Register),
> or came from the hardware device (i.e vectored via IOAPIC), or just via
> INT n instruction.
>
> Was I wrong?
>
> Anton Bassov
>
Alberto, you’ll find that some chipsets don’t forward the cycles from the
frontside bus to the Local APIC in the ways that you’re depending on.
Also, see my other post on ISR management. I know from other discussions
that you’re comfortable managing your own IDT entry. But there’s a lot of
complexity in that.
“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> Jake,
>
> The solution I proposed pokes at the Local APIC, which exists inside the
> processor. It doesn’t use the I/O Apic. The interrupt is only “MSI” in
> name, it’s internal to the processor. You can likewise generate an IPI
> interrupt through the same technique. Moreover, the qword you push to the
> processor includes an interrupt vector, so, you get control directly at
> your isr. If the processor has a local APIC and if the physical location
> is the same, it should work independently of the chip set, in fact,
> independent of just about anything outside the processor.
>
> There’s one caveat, though: in order for this to work, your device must be
> able to write to the processor’s physical memory address space. My chip
> can, and this has been working flawlessly for a few months now. Still, as
> an insurance against possible future issues, I added a Registry entry to
> my driver which reverts to polling for dma and render completions.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Jake Oshins”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, August 15, 2007 1:21 AM
> Subject: Re:[ntdev] PCI Express MSI support under XP?
>
>
>> Well, actually, there are differences between motherboards that support
>> APICs. It took me many months to add MSI support in Windows Vista, and
>> ultimately I wasn’t the only one working on it. You won’t find one body
>> of code that works on every chipset, though most of it is common.
>>
>> The biggest problem you’ll have, and probably one that is prohibitive, is
>> that you can’t easily hook into the kernel’s interrupt handling code with
>> an edge-triggered interrupt from a PCI device. In fact, XP is only
>> capable of managing an interrupt that is associated with an I/O APIC (or
>> PIC) input. MSI devices aren’t using an interrupt controller input.
>>
>> - Jake Oshins
>> Windows Kernel Team
>> (author of most of the MSI code in Windows)
>>
>>
>> wrote in message news:xxxxx@ntdev…
>>>> Strictly speaking, no - an APIC on a Windows compatible system isn’t
>>>> motherboard specific.
>>>
>>> Well, although the code does not have to be specific to some
>>> particular motherboard, it still has to be hardware-specific - please
>>> don’t forget that there are still quite a few PIC-based motherboards
>>> around…
>>>
>>> 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
>
>
Thanks, Jake, for the tip. I expect that the Registry Entry that I
implemented will insure me against not being able to reach the Local APIC!
Also, I do not intercept the IDT, there’s no need for that - all I do is to
put the correct vector in the quadword I store in the APIC’s space, and I
get control in my ISR, which I had installed with IoConnectInterrupt. I know
this isn’t quite clean, but it’s the best I could come up with given the
pressures I’m under and the realities of my chip!
Alberto.
----- Original Message -----
From: “Jake Oshins”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, August 15, 2007 1:19 PM
Subject: Re:[ntdev] Re:PCI Express MSI support under XP?
> Alberto, you’ll find that some chipsets don’t forward the cycles from the
> frontside bus to the Local APIC in the ways that you’re depending on.
>
> Also, see my other post on ISR management. I know from other discussions
> that you’re comfortable managing your own IDT entry. But there’s a lot of
> complexity in that.
>
> - Jake Oshins
> Windows Kernel Guy
>
>
> “Alberto Moreira” wrote in message news:xxxxx@ntdev…
>> Jake,
>>
>> The solution I proposed pokes at the Local APIC, which exists inside the
>> processor. It doesn’t use the I/O Apic. The interrupt is only “MSI” in
>> name, it’s internal to the processor. You can likewise generate an IPI
>> interrupt through the same technique. Moreover, the qword you push to
>> the processor includes an interrupt vector, so, you get control directly
>> at your isr. If the processor has a local APIC and if the physical
>> location is the same, it should work independently of the chip set, in
>> fact, independent of just about anything outside the processor.
>>
>> There’s one caveat, though: in order for this to work, your device must
>> be able to write to the processor’s physical memory address space. My
>> chip can, and this has been working flawlessly for a few months now.
>> Still, as an insurance against possible future issues, I added a Registry
>> entry to my driver which reverts to polling for dma and render
>> completions.
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Jake Oshins”
>> Newsgroups: ntdev
>> To: “Windows System Software Devs Interest List”
>> Sent: Wednesday, August 15, 2007 1:21 AM
>> Subject: Re:[ntdev] PCI Express MSI support under XP?
>>
>>
>>> Well, actually, there are differences between motherboards that support
>>> APICs. It took me many months to add MSI support in Windows Vista, and
>>> ultimately I wasn’t the only one working on it. You won’t find one body
>>> of code that works on every chipset, though most of it is common.
>>>
>>> The biggest problem you’ll have, and probably one that is prohibitive,
>>> is that you can’t easily hook into the kernel’s interrupt handling code
>>> with an edge-triggered interrupt from a PCI device. In fact, XP is only
>>> capable of managing an interrupt that is associated with an I/O APIC (or
>>> PIC) input. MSI devices aren’t using an interrupt controller input.
>>>
>>> - Jake Oshins
>>> Windows Kernel Team
>>> (author of most of the MSI code in Windows)
>>>
>>>
>>> wrote in message news:xxxxx@ntdev…
>>>>> Strictly speaking, no - an APIC on a Windows compatible system isn’t
>>>>> motherboard specific.
>>>>
>>>> Well, although the code does not have to be specific to some
>>>> particular motherboard, it still has to be hardware-specific -
>>>> please don’t forget that there are still quite a few PIC-based
>>>> motherboards around…
>>>>
>>>> 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
>>
>>
>
>
>
> —
> 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
Note that while what you say is correct for a real MSI interrupt, what you
get by poking at the local APIC isn’t really an MSI interrupt, at least not
what the bus would call it. The interrupt happens totally inside the
processor, and one of the fields you write to the APIC is your vector -
which you registered at init time with IoConnectInterrupt. Neither the ISR
nor the DPC that follows it know the difference between a real interrupt and
this local APIC kluge, except maybe by looking at the IRQL. I should put a
scope on my frontside bus to learn a bit better how this is actually
working!
Alberto.
----- Original Message -----
From: “Jake Oshins”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, August 15, 2007 1:17 PM
Subject: Re:[ntdev] PCI Express MSI support under XP?
> No, you weren’t wrong. But you can’t convince Windows XP to insert an
> interrupt handler for you in your IDT unless you have an associated
> interrupt controller input. This means that, to get an ISR registered for
> an MSI, you’d have to hack into the IDT. And while that’s possible
> (though certainly not advisable) then it becomes very, very hard to do
> things like scheduling a DPC, as the kernel’s ISR stub does a lot of
> useful work for you. As an example, the kernel special cases DPC queing
> from an ISR so that it doesn’t have to actually schedule a DPC interrupt.
> Getting this right without using any of the kernel support routines is
> prohibitively difficult.
>
> - Jake
>
>
> wrote in message news:xxxxx@ntdev…
>> Jake,
>>
>>> The biggest problem you’ll have, and probably one that is prohibitive,
>>> is
>>> that you can’t easily hook into the kernel’s interrupt handling code
>>> with an
>>> edge-triggered interrupt from a PCI device. In fact, XP is only capable
>>> of
>>> managing an interrupt that is associated with an I/O APIC (or PIC)
>>> input.
>>> MSI devices aren’t using an interrupt controller input.
>>
>> I always thought that interrupt handler (the one in IDT) itself does not
>> know the actual source of interrupt - it just calls all ISR that check
>> are associated with a given vector, and their task is to check the
>> appropriate IO registers in order to find out whether devices that they
>> are responsible for have actually interrupted. In other words, I thought
>> interrupt dispatching is always the same, no matter if interrupt was
>> raised via the local APIC (i.e. write to ICR or Message Address
>> Register), or came from the hardware device (i.e vectored via IOAPIC), or
>> just via INT n instruction.
>>
>> Was I wrong?
>>
>> 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
Jake,
This means that, to get an ISR registered for
an MSI, you’d have to hack into the IDT. And while that’s possible (though
certainly not advisable) then it becomes very, very hard to do things like
scheduling a DPC, as the kernel’s ISR stub does a lot of useful work for
you. As an example, the kernel special cases DPC queing from an ISR so that
it doesn’t have to actually schedule a DPC interrupt. Getting this right
without using any of the kernel support routines is prohibitively difficult.
To be honest, I don’t see anything particularly difficult here…
You just have to do the following in your ISR (please note that I *DEFINITELY* don’t advise registering your own handlers in IDT - I just explain what has to be done if you are just desperate to do it):
1.Save execution context and raise IRQL to your target level
If previous IRQL was below DPC level, write 2 to BYTE PTR FS [0x95]. This step is needed for proper functioning of HalRequestSoftwareInterrupt() that gets invoked when you queue a DPC -
if BYTE PTR FS [0x95]==2 and DISPATCH_LEVEL interrupt is requested, then HalRequestSoftwareInterrupt() writes 1 to BYTE PTR FS [0x96] and returns, without actually requesting interrupt via ICR
Enable interrupts with STI instruction (I assume you are wise enough to set up your IDT entry
as interrupt, rather than trap, gate, so that interrupts are disabled when your handler enters execution)
Do what ISRs normally do (i.e. control the device and queue a DPC)
Issue EOI. If previous IRQL was >= DISPATCH_LEVEL, restore IRQL and execution context, and
return with IRETD
Write 0 to BYTE PTR FS [0x95], and check BYTE PTR FS [0x96]. If it is 0, you can restore IRQL and execution context, and return with IRETD - you don’t have to bother yourself with flushing DPC queue (in order to understand why, look at the explanation of how HalRequestSoftwareInterrupt() works)
Set BYTE PTR FS [0x96] to 0 and IRQL to DISPATCH_LEVEL, and call KiDispatchInterrupt() in order to flush DPC queue
Restore IRQL and execution context, and return with IRETD
As you can see, there is nothing terribly complex here - the “only” problem is that the whole thing can get broken by a slightest system update…
Anton Bassov
Thank you for neatly making my point for me.
Anybody can read the Windows instruction stream and paste it into a driver.
Hell, we ship a perfectly serviceable debugger that lets you look at the
underbelly of the OS. The complications are in dovetailing with an
undocumented code path that has no external interfaces, particularly in a
way that doesn’t break tomorrow.
wrote in message news:xxxxx@ntdev…
> Jake,
>
>> This means that, to get an ISR registered for
>> an MSI, you’d have to hack into the IDT. And while that’s possible
>> (though
>> certainly not advisable) then it becomes very, very hard to do things
>> like
>> scheduling a DPC, as the kernel’s ISR stub does a lot of useful work for
>> you. As an example, the kernel special cases DPC queing from an ISR so
>> that
>> it doesn’t have to actually schedule a DPC interrupt. Getting this right
>> without using any of the kernel support routines is prohibitively
>> difficult.
>
> To be honest, I don’t see anything particularly difficult here…
>
> You just have to do the following in your ISR (please note that I
> DEFINITELY don’t advise registering your own handlers in IDT - I just
> explain what has to be done if you are just desperate to do it):
>
> 1.Save execution context and raise IRQL to your target level
>
> 2. If previous IRQL was below DPC level, write 2 to BYTE PTR FS [0x95].
> This step is needed for proper functioning of
> HalRequestSoftwareInterrupt() that gets invoked when you queue a DPC -
> if BYTE PTR FS [0x95]==2 and DISPATCH_LEVEL interrupt is requested, then
> HalRequestSoftwareInterrupt() writes 1 to BYTE PTR FS [0x96] and returns,
> without actually requesting interrupt via ICR
>
> 3. Enable interrupts with STI instruction (I assume you are wise enough to
> set up your IDT entry
> as interrupt, rather than trap, gate, so that interrupts are disabled when
> your handler enters execution)
>
> 4. Do what ISRs normally do (i.e. control the device and queue a DPC)
>
> 5. Issue EOI. If previous IRQL was >= DISPATCH_LEVEL, restore IRQL and
> execution context, and
> return with IRETD
>
> 6. Write 0 to BYTE PTR FS [0x95], and check BYTE PTR FS [0x96]. If it is
> 0, you can restore IRQL and execution context, and return with IRETD - you
> don’t have to bother yourself with flushing DPC queue (in order to
> understand why, look at the explanation of how
> HalRequestSoftwareInterrupt() works)
>
> 7. Set BYTE PTR FS [0x96] to 0 and IRQL to DISPATCH_LEVEL, and call
> KiDispatchInterrupt() in order to flush DPC queue
>
>
> 8. Restore IRQL and execution context, and return with IRETD
>
> As you can see, there is nothing terribly complex here - the “only”
> problem is that the whole thing can get broken by a slightest system
> update…
>
>
> Anton Bassov
>
>
>