Accessing large physical memory block (128M-1G)

NTDEV
1

Hi all,

There is a big block of physical memory (128M-1G) reserved for my driver
(x86 only) as buffer. The buffer needs to be accessed from the driver at
IRQL as high as DISPATCH level, less than 64KB each time. MmMapIoSpace
certainly won’t work here. I also tried MmAllocatePagesForMdl on the range,
but it returns NULL because OS is unaware of the RAM here.

So my question is what’s the best way to access this big physical memory
block?

Any suggestion will be appreciated.

Thanks in advance,
Michael Huang

2

Why do you need to reserve a big space, when all you’re accessing at any
given time is 64KB?

One certain limitation that you’ll run into (we have at several occasions
for different reasons) is that the kernel mapped space is not infinite.
There’s a certain amount of available space to map things into the kernel.
Generally, you can not map more than about 128 or 256MB of memory into
kernel space, no matter how much you’d LIKE to do so. This is simply
because there’s only so much space allowed to be used according to the
kernels rules. I’m not sure if it’s page-table entries or some other
administrative data that is the limiting factor here, but it’s certainly a
limit that is not extensible. Setting the /3G switch on the kernel will
further reduce the amount of available space to the kernel, in favour of
user space.

So even if you had a very good reason, you’re unlikely to achieve more than
maybe 256MB mapped into kernel space at any given time.

What exactly isn’t working when using MmMapIoSpace?

–
Mats

xxxxx@lists.osr.com wrote on 02/02/2005 03:52:20 PM:

Hi all,

There is a big block of physical memory (128M-1G) reserved for my driver
(x86 only) as buffer. The buffer needs to be accessed from the driver at
IRQL as high as DISPATCH level, less than 64KB each time. MmMapIoSpace
certainly won’t work here. I also tried MmAllocatePagesForMdl on the
range,
but it returns NULL because OS is unaware of the RAM here.

So my question is what’s the best way to access this big physical memory
block?

Any suggestion will be appreciated.

Thanks in advance,
Michael Huang

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000C016

3

Hi Mats,

Thanks for the reply. MmMapIoSpace does not work since Callers of
MmMapIoSpace must be running at IRQL = PASSIVE_LEVEL.

We need this space as a special RAM cache for a special app. I’m aware of
that a driver can’t map too much memory into kernel space due to the limited
number of system PTE. But my driver only needs to map less than 64KB each
time, it will be unmapped after using, can’t see why it can’t be done.

Thanks again.

Michael

“Mats PETERSSON” wrote in message
news:xxxxx@ntdev…
>
>
>
>
>
> Why do you need to reserve a big space, when all you’re accessing at any
> given time is 64KB?
>
> One certain limitation that you’ll run into (we have at several occasions
> for different reasons) is that the kernel mapped space is not infinite.
> There’s a certain amount of available space to map things into the kernel.
> Generally, you can not map more than about 128 or 256MB of memory into
> kernel space, no matter how much you’d LIKE to do so. This is simply
> because there’s only so much space allowed to be used according to the
> kernels rules. I’m not sure if it’s page-table entries or some other
> administrative data that is the limiting factor here, but it’s certainly a
> limit that is not extensible. Setting the /3G switch on the kernel will
> further reduce the amount of available space to the kernel, in favour of
> user space.
>
> So even if you had a very good reason, you’re unlikely to achieve more
> than
> maybe 256MB mapped into kernel space at any given time.
>
> What exactly isn’t working when using MmMapIoSpace?
>
> –
> Mats
>
>
> xxxxx@lists.osr.com wrote on 02/02/2005 03:52:20 PM:
>
>> Hi all,
>>
>> There is a big block of physical memory (128M-1G) reserved for my driver
>> (x86 only) as buffer. The buffer needs to be accessed from the driver at
>> IRQL as high as DISPATCH level, less than 64KB each time. MmMapIoSpace
>> certainly won’t work here. I also tried MmAllocatePagesForMdl on the
> range,
>> but it returns NULL because OS is unaware of the RAM here.
>>
>> So my question is what’s the best way to access this big physical memory
>> block?
>>
>> Any suggestion will be appreciated.
>>
>> Thanks in advance,
>> Michael Huang
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at http://www.
>> osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>> ForwardSourceID:NT0000C016
>
>

4

Well, manipulating the page tables is obviously done in the kernel at
higher than passive level, but I suspect the reason you can’t do it from
DISPATCH level is that the kernel has locks that force a second caller to
wait for the kernel to finish the first caller, in case of multiple
simultaneous calls to the paging code.

I suspect one way to make things work is to do something like this:

  1. Create a worker thread.
  2. When an access to your cache is required, check if the section is mapped
    in, and if not, pend the current IRP, and send a message to the worker
    thread.
  3. In the worker thread, map in the pages required (64K or bigger “lumps”).
    The size of a “lump” would depend on the access pattern that appears in
    your system. Obviously, you may have to “unmap” some region to maintain a
    limited load of mapped memory in the kernel.
  4. When the page is finally mapped in, “unpend” the IRP.

Note: Unmapping a section means that you also have to keep track of which
sections are currently in use, unless you know for sure that no section can
be access simultaneously with another section… This should be fairly easy
to do with some locked operations, and not very taxing on the system.

[I’m not that familiar with the workings of IRPs, as I’m working on display drivers, which don’t really do IRP’s much, so I may have made some assumptions on how things work, but I think some variation on the above theme should work].

–
Mats
xxxxx@lists.osr.com wrote on 02/02/2005 05:45:24 PM:

Hi Mats,

Thanks for the reply. MmMapIoSpace does not work since Callers of
MmMapIoSpace must be running at IRQL = PASSIVE_LEVEL.

We need this space as a special RAM cache for a special app. I’m aware of

that a driver can’t map too much memory into kernel space due to the
limited
number of system PTE. But my driver only needs to map less than 64KB each

time, it will be unmapped after using, can’t see why it can’t be done.

Thanks again.

Michael

“Mats PETERSSON” wrote in message
> news:xxxxx@ntdev…
> >
> >
> >
> >
> >
> > Why do you need to reserve a big space, when all you’re accessing at
any
> > given time is 64KB?
> >
> > One certain limitation that you’ll run into (we have at several
occasions
> > for different reasons) is that the kernel mapped space is not infinite.
> > There’s a certain amount of available space to map things into the
kernel.
> > Generally, you can not map more than about 128 or 256MB of memory into
> > kernel space, no matter how much you’d LIKE to do so. This is simply
> > because there’s only so much space allowed to be used according to the
> > kernels rules. I’m not sure if it’s page-table entries or some other
> > administrative data that is the limiting factor here, but it’s
certainly a
> > limit that is not extensible. Setting the /3G switch on the kernel will
> > further reduce the amount of available space to the kernel, in favour
of
> > user space.
> >
> > So even if you had a very good reason, you’re unlikely to achieve more
> > than
> > maybe 256MB mapped into kernel space at any given time.
> >
> > What exactly isn’t working when using MmMapIoSpace?
> >
> > –
> > Mats
> >
> >
> > xxxxx@lists.osr.com wrote on 02/02/2005 03:52:20 PM:
> >
> >> Hi all,
> >>
> >> There is a big block of physical memory (128M-1G) reserved for my
driver
> >> (x86 only) as buffer. The buffer needs to be accessed from the driver
at
> >> IRQL as high as DISPATCH level, less than 64KB each time. MmMapIoSpace
> >> certainly won’t work here. I also tried MmAllocatePagesForMdl on the
> > range,
> >> but it returns NULL because OS is unaware of the RAM here.
> >>
> >> So my question is what’s the best way to access this big physical
memory
> >> block?
> >>
> >> Any suggestion will be appreciated.
> >>
> >> Thanks in advance,
> >> Michael Huang
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at http://www.
> >> osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >> ForwardSourceID:NT0000C016
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000C062

5

Michael,

you wrote on Wednesday, February 2, 2005, 18:45:24:

MH> We need this space as a special RAM cache for a special app. I’m aware of
MH> that a driver can’t map too much memory into kernel space due to the limited
MH> number of system PTE. But my driver only needs to map less than 64KB each
MH> time, it will be unmapped after using, can’t see why it can’t be done.

What about /MAXMEM or /BURNMEMORY in boot.ini?

–
Ralf.

6

Hi Ralf,

Thanks for the reply. We had this space reserved already, not by /MAXMEM or
/BURNMEMORY in boot.ini though. My question is how to access it in DISPATCH
level, less than 64KB each time.

Michael

“Ralf Buschmann” wrote in message news:xxxxx@ntdev…
> Michael,
>
> you wrote on Wednesday, February 2, 2005, 18:45:24:
>
> MH> We need this space as a special RAM cache for a special app. I’m aware
> of
> MH> that a driver can’t map too much memory into kernel space due to the
> limited
> MH> number of system PTE. But my driver only needs to map less than 64KB
> each
> MH> time, it will be unmapped after using, can’t see why it can’t be done.
>
> What about /MAXMEM or /BURNMEMORY in boot.ini?
>
> –
> Ralf.
>
>

7

I think it will matter how you “reserved” this memory. If it isn’t
non-paged, nothing you do will let you access it at DISPATCH_LEVEL, and
if it is, I would think that MmGetSystemAddressForMdlSafe would work.
But perhaps I’m confused about what you’re trying to do.

Michael Huang wrote:

Hi Ralf,

Thanks for the reply. We had this space reserved already, not by /MAXMEM or
/BURNMEMORY in boot.ini though. My question is how to access it in DISPATCH
level, less than 64KB each time.

Michael

“Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>
>>Michael,
>>
>>you wrote on Wednesday, February 2, 2005, 18:45:24:
>>
>>MH> We need this space as a special RAM cache for a special app. I’m aware
>>of
>>MH> that a driver can’t map too much memory into kernel space due to the
>>limited
>>MH> number of system PTE. But my driver only needs to map less than 64KB
>>each
>>MH> time, it will be unmapped after using, can’t see why it can’t be done.
>>
>>What about /MAXMEM or /BURNMEMORY in boot.ini?
>>
>>–
>>Ralf.
>>
>>
>
>
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

8

So - you have an area of physical memory pre-allocated for your device
outside of NT and you want to get virtual access to a 64KB chunk - How about
building a MDL and using MmGetSystemAddressForMdlSafe (or
MmMapLockedPagesSpecifyCache if you need non-cached access). Both of these
can be done at DISPATCH.

(I think you also need to make sure you set the MDL_IO_SPACE flag in the MDL
flags; otherwise the routine will expect the pages to be known by NT.)

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
Sent: Wednesday, February 02, 2005 2:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)

Hi Ralf,

Thanks for the reply. We had this space reserved already, not by /MAXMEM or
/BURNMEMORY in boot.ini though. My question is how to access it in DISPATCH
level, less than 64KB each time.

Michael

“Ralf Buschmann” wrote in message news:xxxxx@ntdev…
> Michael,
>
> you wrote on Wednesday, February 2, 2005, 18:45:24:
>
> MH> We need this space as a special RAM cache for a special app. I’m aware

> of
> MH> that a driver can’t map too much memory into kernel space due to the
> limited
> MH> number of system PTE. But my driver only needs to map less than 64KB
> each
> MH> time, it will be unmapped after using, can’t see why it can’t be done.
>
> What about /MAXMEM or /BURNMEMORY in boot.ini?
>
> –
> Ralf.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Thanks Simon,

That’s exactly what I want to accomplished, but how could I build a MDL
pointing to the 64KB in that range? I know I could get an MDL by MmCreateMdl
or IoAllocateMdl, but don’t know how to let the MDL pointing to that
specific 64KB, also don’t know what Base addr or VirtualAddress needed to be
passed to MmCreateMdl or IoAllocateMdl call.

Could you shed a light here? Thanks a lot.

Michael

“Graham, Simon” wrote in message
news:xxxxx@ntdev…
> So - you have an area of physical memory pre-allocated for your device
> outside of NT and you want to get virtual access to a 64KB chunk - How
> about
> building a MDL and using MmGetSystemAddressForMdlSafe (or
> MmMapLockedPagesSpecifyCache if you need non-cached access). Both of these
> can be done at DISPATCH.
>
> (I think you also need to make sure you set the MDL_IO_SPACE flag in the
> MDL
> flags; otherwise the routine will expect the pages to be known by NT.)
>
> /simgr
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
> Sent: Wednesday, February 02, 2005 2:41 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)
>
> Hi Ralf,
>
> Thanks for the reply. We had this space reserved already, not by /MAXMEM
> or
> /BURNMEMORY in boot.ini though. My question is how to access it in
> DISPATCH
> level, less than 64KB each time.
>
> -----------
> Michael
>
> “Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>> Michael,
>>
>> you wrote on Wednesday, February 2, 2005, 18:45:24:
>>
>> MH> We need this space as a special RAM cache for a special app. I’m
>> aware
>
>> of
>> MH> that a driver can’t map too much memory into kernel space due to the
>> limited
>> MH> number of system PTE. But my driver only needs to map less than 64KB
>> each
>> MH> time, it will be unmapped after using, can’t see why it can’t be
>> done.
>>
>> What about /MAXMEM or /BURNMEMORY in boot.ini?
>>
>> –
>> Ralf.
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

10

Well, ignoring for the moment the fact that you CAN apparently call
MmMapIoSpace at DISPATCH (which surprised me too by the way), it doesn’t
matter what you specify for virtual address – you are going to use the
systemaddress anyway, not the user address which is what this parameter is
for.

So:

PMDL MyMdl = IoAllocateMdl(NULL,64*1024,FALSE,FALSE,NULL)

Should get you the mdl. Once it’s initialized, you can setup the physical
page array using the MmGetMdlPfnArray() routine and inserting the physical
page numbers of the 64KB region you want to map into it.

BTW; I don’t know how often you plan on doing this, BUT setting up and
tearing down virtual mappings is a fairly expensive process given that you
have to shoot down the TLB on every processor for both - this means you
invalidate all the TLBs (and take the overhead of sending IPIs to every
processor) twice each time you do this. If you plan on doing this a lot, you
should also plan on caching as many of these mappings as you can (consistent
with not using up all the system resources of course).

This comment applies to using MmMapIoSpace as well btw - you’d better look
into the pattern of 64KB chunks you need access to and come up with a scheme
that minimises the number of times you have to do it…

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
Sent: Thursday, February 03, 2005 11:33 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)

Thanks Simon,

That’s exactly what I want to accomplished, but how could I build a MDL
pointing to the 64KB in that range? I know I could get an MDL by MmCreateMdl

or IoAllocateMdl, but don’t know how to let the MDL pointing to that
specific 64KB, also don’t know what Base addr or VirtualAddress needed to be

passed to MmCreateMdl or IoAllocateMdl call.

Could you shed a light here? Thanks a lot.

Michael

“Graham, Simon” wrote in message
news:xxxxx@ntdev…
> So - you have an area of physical memory pre-allocated for your device
> outside of NT and you want to get virtual access to a 64KB chunk - How
> about
> building a MDL and using MmGetSystemAddressForMdlSafe (or
> MmMapLockedPagesSpecifyCache if you need non-cached access). Both of these
> can be done at DISPATCH.
>
> (I think you also need to make sure you set the MDL_IO_SPACE flag in the
> MDL
> flags; otherwise the routine will expect the pages to be known by NT.)
>
> /simgr
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
> Sent: Wednesday, February 02, 2005 2:41 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)
>
> Hi Ralf,
>
> Thanks for the reply. We had this space reserved already, not by /MAXMEM
> or
> /BURNMEMORY in boot.ini though. My question is how to access it in
> DISPATCH
> level, less than 64KB each time.
>
> -----------
> Michael
>
> “Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>> Michael,
>>
>> you wrote on Wednesday, February 2, 2005, 18:45:24:
>>
>> MH> We need this space as a special RAM cache for a special app. I’m
>> aware
>
>> of
>> MH> that a driver can’t map too much memory into kernel space due to the
>> limited
>> MH> number of system PTE. But my driver only needs to map less than 64KB
>> each
>> MH> time, it will be unmapped after using, can’t see why it can’t be
>> done.
>>
>> What about /MAXMEM or /BURNMEMORY in boot.ini?
>>
>> –
>> Ralf.
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

Simon,

Thanks a lot. I have tried MmMapIoSpace and it works great so far on my
Win2k test machine. So I’ll take the method you detailed in the reply as a
backup plan if somehow MmMapIoSpace turns out broken at IRQL >PASSIVE level.

Thanks again,

Michael

“Graham, Simon” wrote in message
news:xxxxx@ntdev…
> Well, ignoring for the moment the fact that you CAN apparently call
> MmMapIoSpace at DISPATCH (which surprised me too by the way), it doesn’t
> matter what you specify for virtual address – you are going to use the
> systemaddress anyway, not the user address which is what this parameter is
> for.
>
> So:
>
> PMDL MyMdl = IoAllocateMdl(NULL,64*1024,FALSE,FALSE,NULL)
>
> Should get you the mdl. Once it’s initialized, you can setup the physical
> page array using the MmGetMdlPfnArray() routine and inserting the physical
> page numbers of the 64KB region you want to map into it.
>
> BTW; I don’t know how often you plan on doing this, BUT setting up and
> tearing down virtual mappings is a fairly expensive process given that you
> have to shoot down the TLB on every processor for both - this means you
> invalidate all the TLBs (and take the overhead of sending IPIs to every
> processor) twice each time you do this. If you plan on doing this a lot,
> you
> should also plan on caching as many of these mappings as you can
> (consistent
> with not using up all the system resources of course).
>
> This comment applies to using MmMapIoSpace as well btw - you’d better look
> into the pattern of 64KB chunks you need access to and come up with a
> scheme
> that minimises the number of times you have to do it…
>
> /simgr
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
> Sent: Thursday, February 03, 2005 11:33 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)
>
> Thanks Simon,
>
> That’s exactly what I want to accomplished, but how could I build a MDL
> pointing to the 64KB in that range? I know I could get an MDL by
> MmCreateMdl
>
> or IoAllocateMdl, but don’t know how to let the MDL pointing to that
> specific 64KB, also don’t know what Base addr or VirtualAddress needed to
> be
>
> passed to MmCreateMdl or IoAllocateMdl call.
>
> Could you shed a light here? Thanks a lot.
> --------
> Michael
>
> “Graham, Simon” wrote in message
> news:xxxxx@ntdev…
>> So - you have an area of physical memory pre-allocated for your device
>> outside of NT and you want to get virtual access to a 64KB chunk - How
>> about
>> building a MDL and using MmGetSystemAddressForMdlSafe (or
>> MmMapLockedPagesSpecifyCache if you need non-cached access). Both of
>> these
>> can be done at DISPATCH.
>>
>> (I think you also need to make sure you set the MDL_IO_SPACE flag in the
>> MDL
>> flags; otherwise the routine will expect the pages to be known by NT.)
>>
>> /simgr
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Huang
>> Sent: Wednesday, February 02, 2005 2:41 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Accessing large physical memory block (128M-1G)
>>
>> Hi Ralf,
>>
>> Thanks for the reply. We had this space reserved already, not by /MAXMEM
>> or
>> /BURNMEMORY in boot.ini though. My question is how to access it in
>> DISPATCH
>> level, less than 64KB each time.
>>
>> -----------
>> Michael
>>
>> “Ralf Buschmann” wrote in message news:xxxxx@ntdev…
>>> Michael,
>>>
>>> you wrote on Wednesday, February 2, 2005, 18:45:24:
>>>
>>> MH> We need this space as a special RAM cache for a special app. I’m
>>> aware
>>
>>> of
>>> MH> that a driver can’t map too much memory into kernel space due to the
>>> limited
>>> MH> number of system PTE. But my driver only needs to map less than 64KB
>>> each
>>> MH> time, it will be unmapped after using, can’t see why it can’t be
>>> done.
>>>
>>> What about /MAXMEM or /BURNMEMORY in boot.ini?
>>>
>>> –
>>> Ralf.
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@stratus.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

12

Michael Huang wrote:

Win2k test machine. So I’ll take the method you detailed in the reply as a
backup plan if somehow MmMapIoSpace turns out broken at IRQL >PASSIVE level.

I can confirm for you that MmMapIoSpace is indeed callable at IRQL
DISPATCH_LEVEL.

The recommendation has traditionally been that this function only be
called at IRQL PASSIVE_LEVEL. However, the function is indeed not
pageable, and there are apparently a number of existing drivers that
call it at IRQL DISPATCH_LEVEL.

So… Calling at IRQL DISPATCH_LEVEL looks like a safe bet,

Peter
OSR