There are (mostly older) systems with chipsets that cause ALL interrupts to occur on CPU 0 instead of being evenly spread among CPUs. Regardless, if an interrupt occurs on the CPU that you are spinning and there’s a DPC involved, it won’t run until the spinning DPC is done so that may lock up the GUI / system.
//Daniel
um no?
If there is an interrupt on the cpu that is running a dpc thread, the
interrupt service will run and then the dpc will resume. Also a dpc is not
a hardware interrupt, it cannot by itself block other cpus.
Mark Roddy
That’s what I think I said. The spinning DPC will resume. Perhaps an exception to this is if a HighImportance DPC is queued, then it should run immediately.
//Daniel
finding any machine in 2020 that has only 2 cores seems hard, but I think that many current desktop grade systems do route all interrupts to cpu 0 even in 2020.
in any case it will be a highly platform specific behavior that will certainly change between each physical machine and between VMs on different hypervisors and with differences in the physical machines that they run on too
Perhaps an exception to this is if a HighImportance DPC is queued, then it should run immediately.
Absolutely not. There is never DPC preemption.
All setting the Importance of a DPC does is influence (a) whether the DPC Object is queue at the head or the tail of the DPC List, and (b) If the DPC is targeted to a processor other than the current processor, whether a IPC is sent to the remote processor to inform it that it now has something on the DPC list that needs to be processed.
Peter
Absolutely not. There is never DPC preemption.
That’s what I would expect too, but here’s what the docs say about HighImportance:
Place the DPC at the beginning of the DPC queue, and begin processing the queue immediately.
If KeInsertQueueDpc is executed by the ISR, cannot it process the DPC queue before the ISR returns ?
//Daniel
If KeInsertQueueDpc is executed by the ISR, cannot it process the DPC queue before the ISR returns
No. How could this work. The ISR is running at DIRQL and holding the interrupt spin lock… we need to run the DPC at IRQL DISPATCH_LEVEL and not holding the lock.
How could DPC preemption work, given everything we know about DPCs?
Peter
Place the DPC at the beginning of the DPC queue, and begin processing the queue immediately.
… IF the kernel is not already processing the queue. That’s the missing clause here.
It difficult to write what is exactly correct in this situation concisely. I would write it to read
“Place the DPC at the beginning of the DPC list, and cause the list to be evaluated the next time the IRQL is about to drop below IRQL DISPATCH_LEVEL. If the DPC is queued to a processor other than the current processor, an IPI is sent to that processor, thus causing the DPC list on that processor to serviced subsequent to the IPI.”
Peter
the docs say about HighImportance:
Place the DPC at the beginning of the DPC queue, and begin processing the queue immediately.
Regardless of its priority, a DPC cannot preempt ANY code that runs at IRQL>APC_LEVEL. Full stop. Otherwise,it would simply violate the most fundamental principles of Windows design.
In order to understand why, consider what happens if you hold a spinlock and your code gets preempted by DPC, - if the target DPC tries to acquire the lock in question, the deadlock is guaranteed.
In fact, raising IRQL to DISPATCH_LEVEL is just a way of saying “This code must not get preempted by anyone, apart from ISR, because I may hold a lock”…
Anton Bassov
There are (mostly older) systems with chipsets that cause ALL interrupts to occur on CPU 0 instead of being evenly spread among CPUs.
Something tells me that you must be speaking about the chipsets from VIA Technologies…
Anton Bassov
If the DPC is queued to a processor other than the current processor, an IPI is sent to that processor
It’s interesting to realize that the system needs to be able to queue a DPC no matter what it was previously doing. The DPC queue cannot use a spinlock of some sort, what should it do if an interrupt occurs while the lock was already held ? Still I don’t see why the IPI is required. Why shouldn’t any CPU be able to access the DPC queue on any other CPU ?
Something tells me that you must be speaking about the chipsets from VIA Technologies.
Possibly, from what I see, it’s becoming more a thing of the past. They are great for uninterrupted live audio, if you set affinity of your threads to a CPU >=1.
//Daniel
Why shouldn’t any CPU be able to access the DPC queue on any other CPU ?
It can. That’s not the reason for the IPI. DPCs with Medium and Low importance can also be queued to a non-local processor. The IPI is only generated for High Importance DPCs, as a way to cause the “remote” processor to immediately evaluate the DPC List. Otherwise, the remote processors DPC List wouldn’t be evaluated until the next time there was a raise and subsequent lowering of IRQL above DISPATCH_LEVEL.
Peter
The DPC queue cannot use a spinlock of some sort,
Of course it can…
The only thing you have to do is to elevate IRQL to the level above DIRQL when accessing this lock, and everything will work just fine.
Therefore, it cannot be a"regular" spinlock, i.e the one that you lock with KeAcquireSpinlock()
what should it do if an interrupt occurs while the lock was already held ?
As long as current IRQL is above DIRQL there is simply no chance for an ISR to run until IRQL gets lowered. Therefore, there is no
problem here whatsoever…
Why shouldn’t any CPU be able to access the DPC queue on any other CPU ?
Of course it should - otherwise it would be simply unable to queue a DPC to some other processor’s queue
Still I don’t see why the IPI is required.
As Peter explained to you already, it does so simply in order to make the target CPU check it’s DPC queue.
OTOH, I was under the impression that high-and-medium-priority DPCs are always enqueued to the current processor’s queue, so that only a low-priority one may end up in some other processor’s one. If this is the case, then there is no urgency with it whatsoever, so that requesting an IPI seems to be a bit to the extreme…
Anton Bassov
OTOH, I was under the impression that high-and-medium-priority DPCs are always enqueued to the current processor’s queue,
Nope. Importance and Target Processor are separate parameters.
When the docs say “begin processing the queue immediately” read “generate an IPI if the target processors is other than the current processor.”
Peter