Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Raising IRQL on one core blocks threads on other cores?

2»

Comments

  • Daniel_TerhellDaniel_Terhell Member Posts: 1,355

    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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member MODERATED Posts: 5,181

    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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE