Calling KeAcquireSpinLock at DISPATCH_LEVEL

NTDEV
1

Hi,

Microsoft documentation specifies:

“Never call KeAcquireSpinLock from code that is running at IRQL =
DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does not
change the current IRQL”

If we are already at DISPATCH level and we call KeAcquireSpinLock, does
it means the warning is just for the wasted time of raising the IRQL or
is there any other danger there ?

From what I saw so far calling KeAcquireSpinLock did not do any damage
at DISPATCH_LEVEL.

Thanks,

Shay

2

Where did you find that documentation? It certainly is bogus.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@emc.com” wrote in message
news:xxxxx@ntdev:

> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does not
> change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call KeAcquireSpinLock, does
> it means the warning is just for the wasted time of raising the IRQL or
> is there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do any damage
> at DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay

3

Here is a link to the MSDN document:

http://msdn.microsoft.com/en-us/library/ms810029.aspx

Look for " never call keacquirespinlock from code"

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 07, 2010 11:10 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Where did you find that documentation? It certainly is bogus.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@emc.com” wrote in message
news:xxxxx@ntdev:

> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does
not
> change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call KeAcquireSpinLock,
does
> it means the warning is just for the wasted time of raising the IRQL
or
> is there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do any damage
> at DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay

—
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

4

That must be an error in the documentation, suggest it should read:

“Never call KeAcquireSpinLock from code that is running at IRQL =
DPC_LEVEL…”

Nick Clarke
www.redsoftsys.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@emc.com
Sent: 07 October 2010 16:30
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Here is a link to the MSDN document:

http://msdn.microsoft.com/en-us/library/ms810029.aspx

Look for " never call keacquirespinlock from code"

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 07, 2010 11:10 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Where did you find that documentation? It certainly is bogus.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@emc.com” wrote in message
news:xxxxx@ntdev:

> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does
not
> change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call KeAcquireSpinLock,
does
> it means the warning is just for the wasted time of raising the IRQL
or
> is there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do any damage
> at DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay

—
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

____________________________________
This email has been scanned by Netintelligence
http://www.netintelligence.com/email

 Information from ESET Smart Security, version of virus signature
database 5512 (20101007)

The message was checked by ESET Smart Security.

http://www.eset.com

 Information from ESET Smart Security, version of virus signature
database 5512 (20101007) __________

The message was checked by ESET Smart Security.

http://www.eset.com

5

From the title: “Microsoft Corporation ***July 2004***”

Never trust old publications and always re-check MSDN page for the function.

6

Which is why you really need the documentation released for the WDK. I note
in your link it’s last entry in “Applies to:” is LongHorn, which became
Vista and Server 2008. The current WDK is at version 7600.16385.1. I do not
find that bogus statement in the last release of the WDK documentation which
is WDK 7600.091209.01.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@emc.com
Sent: Thursday, October 07, 2010 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Here is a link to the MSDN document:

http://msdn.microsoft.com/en-us/library/ms810029.aspx

Look for " never call keacquirespinlock from code"

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 07, 2010 11:10 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Where did you find that documentation? It certainly is bogus.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@emc.com” wrote in message
news:xxxxx@ntdev:

> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does
not
> change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call KeAcquireSpinLock,
does
> it means the warning is just for the wasted time of raising the IRQL
or
> is there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do any damage
> at DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay

—
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

7

You are correct, it does no damage. What it is trying to say is that it is inefficient to call KeAcquireSpinLock if you know you are already at DISPATCH_LEVEL (ie in a dpc or have acquired another spinlock already) since KeAcquireSpinLock will attempt to change the IRQL, while KeAcquireSpinLockAtDpcLevel will not attempt to change the IRQL. Note that you must 100% know that you are at dispatch_level for this optimization to work. For instance, while completion routines usually run at dispatch_level, there is no guarantee that they will and can be called at passive_level.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@emc.com
Sent: Thursday, October 07, 2010 8:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Hi,

Microsoft documentation specifies:
“Never call KeAcquireSpinLock from code that is running at IRQL = DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does not change the current IRQL”

If we are already at DISPATCH level and we call KeAcquireSpinLock, does it means the warning is just for the wasted time of raising the IRQL or is there any other danger there ?
From what I saw so far calling KeAcquireSpinLock did not do any damage at DISPATCH_LEVEL.

Thanks,
Shay

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

8

Let me add to what Doron just said. On many machines, in many
circumstances, changing IRQL involves touching hardware that is external to
the processor core, and many times more expensive than most functions.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

You are correct, it does no damage. What it is trying to say is that it is
inefficient to call KeAcquireSpinLock if you know you are already at
DISPATCH_LEVEL (ie in a dpc or have acquired another spinlock already) since
KeAcquireSpinLock will attempt to change the IRQL, while
KeAcquireSpinLockAtDpcLevel will not attempt to change the IRQL. Note that
you must 100% know that you are at dispatch_level for this optimization to
work. For instance, while completion routines usually run at dispatch_level,
there is no guarantee that they will and can be called at passive_level.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@emc.com
Sent: Thursday, October 07, 2010 8:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Hi,

Microsoft documentation specifies:

“Never call KeAcquireSpinLock from code that is running at IRQL =
DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does not
change the current IRQL”

If we are already at DISPATCH level and we call KeAcquireSpinLock, does it
means the warning is just for the wasted time of raising the IRQL or is
there any other danger there ?

From what I saw so far calling KeAcquireSpinLock did not do any damage at
DISPATCH_LEVEL.

Thanks,

Shay

—
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

9

I’m probably missing something…

If it is so expensive, why isn’t this optimization done in kernel? Check
current IRQL and change only if necessary.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Friday, October 08, 2010 12:02 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Let me add to what Doron just said. On many machines, in many
circumstances, changing IRQL involves touching hardware that
is external to
the processor core, and many times more expensive than most functions.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Doron Holan” wrote in message
> news:xxxxx@ntdev…
>
> You are correct, it does no damage. What it is trying to say
> is that it is
> inefficient to call KeAcquireSpinLock if you know you are already at
> DISPATCH_LEVEL (ie in a dpc or have acquired another spinlock
> already) since
> KeAcquireSpinLock will attempt to change the IRQL, while
> KeAcquireSpinLockAtDpcLevel will not attempt to change the
> IRQL. Note that
> you must 100% know that you are at dispatch_level for this
> optimization to
> work. For instance, while completion routines usually run at
> dispatch_level,
> there is no guarantee that they will and can be called at
> passive_level.
>
>
>
> d
>
>
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@emc.com
> Sent: Thursday, October 07, 2010 8:04 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
>
>
>
>
>
> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel,
> which does not
> change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call
> KeAcquireSpinLock, does it
> means the warning is just for the wasted time of raising the
> IRQL or is
> there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do
> any damage at
> DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay
>
>
>
>
> —
> 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
>

10

>

I’m probably missing something…

If it is so expensive, why isn’t this optimization done in kernel?
Check
current IRQL and change only if necessary.

I think it only really hurts when you virtualise, I forgot Jake was
the Hyper-V guy so that’s probably what he was implying anyway. From
Windows 2003sp2 and anything newer, the hardware register (TPR) is no
longer used so the problem takes care of itself.

Reading the hardware register to check IRQL is just as expensive as
writing it so you’d have to cache it somewhere (per CPU). In my drivers
for Xen I actually patched the windows kernel to do exactly that - only
update TPR if it is different (actually, on AMD architectures I write
TPR via another means that doesn’t involve a VMEXIT).

James

11

Retrieving the IRQL is as expensive as setting it

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 07, 2010 3:32 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

I’m probably missing something…

If it is so expensive, why isn’t this optimization done in kernel? Check current IRQL and change only if necessary.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Friday, October 08, 2010 12:02 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Let me add to what Doron just said. On many machines, in many
circumstances, changing IRQL involves touching hardware that is
external to the processor core, and many times more expensive than
most functions.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Doron Holan” wrote in message
> news:xxxxx@ntdev…
>
> You are correct, it does no damage. What it is trying to say is that
> it is inefficient to call KeAcquireSpinLock if you know you are
> already at DISPATCH_LEVEL (ie in a dpc or have acquired another
> spinlock
> already) since
> KeAcquireSpinLock will attempt to change the IRQL, while
> KeAcquireSpinLockAtDpcLevel will not attempt to change the IRQL. Note
> that you must 100% know that you are at dispatch_level for this
> optimization to work. For instance, while completion routines usually
> run at dispatch_level, there is no guarantee that they will and can be
> called at passive_level.
>
>
>
> d
>
>
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@emc.com
> Sent: Thursday, October 07, 2010 8:04 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
>
>
>
>
>
> Hi,
>
>
>
> Microsoft documentation specifies:
>
> “Never call KeAcquireSpinLock from code that is running at IRQL =
> DISPATCH_LEVEL, because KeAcquireSpinLock raises the current IRQL to
> DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel, which does
> not change the current IRQL”
>
>
>
> If we are already at DISPATCH level and we call
> KeAcquireSpinLock, does it
> means the warning is just for the wasted time of raising the
> IRQL or is
> there any other danger there ?
>
> From what I saw so far calling KeAcquireSpinLock did not do
> any damage at
> DISPATCH_LEVEL.
>
>
>
> Thanks,
>
> Shay
>
>
>
>
> —
> 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
>

—
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

12

So why it isn’t cached as James does?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, October 08, 2010 12:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Retrieving the IRQL is as expensive as setting it

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, October 07, 2010 3:32 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

I’m probably missing something…

If it is so expensive, why isn’t this optimization done in
kernel? Check current IRQL and change only if necessary.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
> Sent: Friday, October 08, 2010 12:02 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
>
> Let me add to what Doron just said. On many machines, in many
> circumstances, changing IRQL involves touching hardware that is
> external to the processor core, and many times more expensive than
> most functions.
>
>
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Group
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------------------------
> “Doron Holan” wrote in message
> > news:xxxxx@ntdev…
> >
> > You are correct, it does no damage. What it is trying to
> say is that
> > it is inefficient to call KeAcquireSpinLock if you know you are
> > already at DISPATCH_LEVEL (ie in a dpc or have acquired another
> > spinlock
> > already) since
> > KeAcquireSpinLock will attempt to change the IRQL, while
> > KeAcquireSpinLockAtDpcLevel will not attempt to change the
> IRQL. Note
> > that you must 100% know that you are at dispatch_level for this
> > optimization to work. For instance, while completion
> routines usually
> > run at dispatch_level, there is no guarantee that they will
> and can be
> > called at passive_level.
> >
> >
> >
> > d
> >
> >
> >
> >
> >
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> > xxxxx@emc.com
> > Sent: Thursday, October 07, 2010 8:04 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
> >
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > Microsoft documentation specifies:
> >
> > “Never call KeAcquireSpinLock from code that is running at IRQL =
> > DISPATCH_LEVEL, because KeAcquireSpinLock raises the
> current IRQL to
> > DISPATCH_LEVEL. Instead, use KeAcquireSpinLockAtDpcLevel,
> which does
> > not change the current IRQL”
> >
> >
> >
> > If we are already at DISPATCH level and we call
> > KeAcquireSpinLock, does it
> > means the warning is just for the wasted time of raising the
> > IRQL or is
> > there any other danger there ?
> >
> > From what I saw so far calling KeAcquireSpinLock did not do
> > any damage at
> > DISPATCH_LEVEL.
> >
> >
> >
> > Thanks,
> >
> > Shay
> >
> >
> >
> >
> > —
> > 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
> >
>
> —
> 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
>

13

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, October 08, 2010 12:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

I think it only really hurts when you virtualise, I forgot Jake was
the Hyper-V guy so that’s probably what he was implying anyway.

It would make sense but two spinlock functions are there since the first
NT version, long before Hyper-V was born.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

14

> >

> I think it only really hurts when you virtualise, I forgot Jake
was
> the Hyper-V guy so that’s probably what he was implying anyway.

It would make sense but two spinlock functions are there since the
first
NT version, long before Hyper-V was born.

Hyper-V is pretty new on the scene. VMWare has been around since the
late 90’s.

James

15

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, October 08, 2010 1:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Hyper-V is pretty new on the scene. VMWare has been around since the
late 90’s.

Still much younger than NT itself.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

16

>

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Friday, October 08, 2010 1:03 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
>
> Hyper-V is pretty new on the scene. VMWare has been around since the
> late 90’s.

Still much younger than NT itself.

How does it’s age compare to the warnings in the DDK docs about IRQL
though?

James

17

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, October 08, 2010 1:16 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

How does it’s age compare to the warnings in the DDK docs about IRQL
though?

You said it hurts only for virtualization. I say NT were there before
virtualization (in Windows world…) and still there is a spinlock
function to be called at DISPATCH_LEVEL so this optimization had to have
some other reason than virtualization.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

18

Some versions of x86 hals did cache (called lazy irql), but x64 inlined the spinlock APIs so there is no way to change the functionality/behavior

d

dent from a phpne with no keynoard

-----Original Message-----
From: Michal Vodicka
Sent: October 07, 2010 4:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Friday, October 08, 2010 1:16 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
>
> How does it’s age compare to the warnings in the DDK docs about IRQL
> though?

You said it hurts only for virtualization. I say NT were there before
virtualization (in Windows world…) and still there is a spinlock
function to be called at DISPATCH_LEVEL so this optimization had to have
some other reason than virtualization.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

—
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

19

Jake was Mr Hardware at Microsoft long before Hyper-V. Things like MSI
interrupts, and figuring out why some peripheral’s were having problems
were being done by Jake, before virtualization was much of anything.

As Jake and Doron have been saying the cost of accessing the IRQL was
high because in many cases it hit hardware even back in the early NT
days, this is not a virtualization issue.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michal Vodicka” wrote in message
news:xxxxx@ntdev:

> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> > Sent: Friday, October 08, 2010 1:16 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
> >
> > How does it’s age compare to the warnings in the DDK docs about IRQL
> > though?
>
> You said it hurts only for virtualization. I say NT were there before
> virtualization (in Windows world…) and still there is a spinlock
> function to be called at DISPATCH_LEVEL so this optimization had to have
> some other reason than virtualization.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]

20

Well, my question was why it was done this way from the beginning and
why a cache wasn’t used when necessary, instead. It never made sense to
me why to export something which looks like implementation detail which
should be handled internally. Such an API can lead to code like this:

if (KeGetCurrentIrql() == DISPATCH_LEVEL) {
KeAcquireSpinLockAtDpcLevel(…);
}
else {
KeAcquireSpinLock(…);
}

which is worse than calling KeAcquireSpinLock unconditionally at
platforms where accessing IRQL is expensive.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, October 08, 2010 1:29 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL

Jake was Mr Hardware at Microsoft long before Hyper-V.
Things like MSI
interrupts, and figuring out why some peripheral’s were
having problems
were being done by Jake, before virtualization was much of anything.

As Jake and Doron have been saying the cost of accessing the IRQL was
high because in many cases it hit hardware even back in the early NT
days, this is not a virtualization issue.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michal Vodicka” wrote in message
> news:xxxxx@ntdev:
>
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> James Harper
> > > Sent: Friday, October 08, 2010 1:16 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Calling KeAcquireSpinLock at DISPATCH_LEVEL
> > >
> > > How does it’s age compare to the warnings in the DDK docs
> about IRQL
> > > though?
> >
> > You said it hurts only for virtualization. I say NT were
> there before
> > virtualization (in Windows world…) and still there is a spinlock
> > function to be called at DISPATCH_LEVEL so this
> optimization had to have
> > some other reason than virtualization.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> 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
>