doubt about calling thread context

OSR_Community_User · April 19, 2001, 1:00pm

Hello

I have a doubt about the usage of MmGetMdlVirtualAddress .
////////////////////////////
PVOID pVirtualAddr;
PMDL pMdl;

pVirtualAddr = (ULONG_PTR)MmGetMdlVirtualAddress(pIrp->MdlAddress);
pMdl = IoAllocateMdl((PVOID)pVirtualAddr, PAGE_SIZE, FALSE, FALSE, NULL);

IoBuildPartialMdl(pIrp->MdlAddress, pMdl, (PVOID)pVirtualAddr, nSegLen);

MmMapLockedPages(pMdl, KernelMode);
IoSetCompletionRoutine(,);
IoCallDriver(deviceobj,pIrp);
//////////////////////////////////////////////////////
In this above condition can I use the virtual address ( which is still
refers to user buffer I believe ) returned by MmGetMdlVirtualAddress
directly?

But from DDk documentation -
MmGetMdlVirtualAddress returns a virtual address that is not necessarily
valid in the current thread context. Lower-level drivers should not attempt
to use the returned virtual address to access memory, particularly
user-space memory.

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?
Or if not should I get the nonpaged system-space virtual address for the
buffer described by the MDL using the call MmGetSystemAddressForMdlSafe
before using the Virtual Address in IoAllocateMdl
I am not able not understand the logic behind this . Please help me out .

Srinivasa

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 19, 2001, 9:35pm

> What is the meaning of necessarily valid in current current thread context

when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 19, 2001, 10:04pm

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 9:57am

The value returned by MmGetMdlVirtualAddress (or a subsequent result derived
from this value,) is REQUIRED as input to some of the MDL-specific
functions. While it would be wrong to use the returned value as a pointer to
memory, it would be equally wrong to use the value returned by
MmGetSystemAddressForMdl where the return value for MmGetMdlVirtualAddress
is required.

Thus you will see DDK references such as:

“A driver can get the initial CurrentVa for the start of a packet-based DMA
transfer by calling MmGetMdlVirtualAddress. However, the value returned is
an index into the Mdl, rather than a valid virtual address. If the driver
must split a large transfer request into more than one DMA operation, it
must update CurrentVa and Length for each DMA operation.”

(MapTransfer)

The DDK refuses to speak plainly here. CurrentVA is used as an index into
the set of physical pages that describe the user data buffer. The user data
buffer may very well not be PAGE_ALIGNED. The initial value of CurrentVA -
which is to say the value returned by MmGetMdlVirtualAddress is used by
various functions to determine the offset into the physical pages where a
DMA transfer operation should start.

The value returned by MmGetSystemAddressForMdl may not share the same
alignment characteristics. Huge problem then if you substitute this value
instead of the required MmGetMdlVirtualAddress value.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Thursday, April 19, 2001 10:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 1:19pm

Thanks Mark .

then what would be the best way to get the contents of user buffer pointed
by the MDL in the IRP that is received by the driver ?

Obviously we wanted to tranmit the data from the user buffer ( which is from
application ) So through MDL we would be passing the Virtual address to the
driver ( Though after calling IoAllocateMdl and IoBuildPartialMdl calls).
But as per documentation we may have some problem if used that way .

I understand the point what you are trying to mention. Why microsoft don’t
mention that the use of that particular command is according to the context
of other commands that are used .

As you mentioned I had a problem when I tried to use
MmGetSystemAddressForMdl instead of MmGetMdlVirtualAddress .

Thanks and regards
Srinivas

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 6:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

The value returned by MmGetMdlVirtualAddress (or a subsequent result derived
from this value,) is REQUIRED as input to some of the MDL-specific
functions. While it would be wrong to use the returned value as a pointer to
memory, it would be equally wrong to use the value returned by
MmGetSystemAddressForMdl where the return value for MmGetMdlVirtualAddress
is required.

Thus you will see DDK references such as:

“A driver can get the initial CurrentVa for the start of a packet-based DMA
transfer by calling MmGetMdlVirtualAddress. However, the value returned is
an index into the Mdl, rather than a valid virtual address. If the driver
must split a large transfer request into more than one DMA operation, it
must update CurrentVa and Length for each DMA operation.”

(MapTransfer)

The DDK refuses to speak plainly here. CurrentVA is used as an index into
the set of physical pages that describe the user data buffer. The user data
buffer may very well not be PAGE_ALIGNED. The initial value of CurrentVA -
which is to say the value returned by MmGetMdlVirtualAddress is used by
various functions to determine the offset into the physical pages where a
DMA transfer operation should start.

The value returned by MmGetSystemAddressForMdl may not share the same
alignment characteristics. Huge problem then if you substitute this value
instead of the required MmGetMdlVirtualAddress value.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Thursday, April 19, 2001 10:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 1:31pm

If you actually need to access the contents of the user data directly from
your driver using a pointer, that is what MmGetSystemAddressForMdl gives
you: a kernel virtual address for the physical pages that contain the user
data. But if you are simply setting up MDLs to describe portions of the user
data, then you do not need anything other than the CurrentVA ‘index’
constructed by the opaque (non-pointer) use of the value returned by
MmGetMdlVirtualAddress. I think that you probably do not have to actually
access the buffer contents. Aren’t you just building a set of MDLs to pass
on down to the controller? Unless there is some content within the buffer
that you need to be aware of, you should never have to actually access the
user data. If that is all you are doing then you do not need
MmGetSystemAddressForMdl.

You should be aware that the first driver to call MmGetSystemAddressForMdl
on an MDL incurs a substantial overhead, as the system mapping for the user
buffer is not performed until some kernel component asks for it.
MmGetMdlVirtualAddress has no such overhead associated with it.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Friday, April 20, 2001 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks Mark .

then what would be the best way to get the contents of user buffer pointed
by the MDL in the IRP that is received by the driver ?

Obviously we wanted to tranmit the data from the user buffer ( which is from
application ) So through MDL we would be passing the Virtual address to the
driver ( Though after calling IoAllocateMdl and IoBuildPartialMdl calls).
But as per documentation we may have some problem if used that way .

I understand the point what you are trying to mention. Why microsoft don’t
mention that the use of that particular command is according to the context
of other commands that are used .

As you mentioned I had a problem when I tried to use
MmGetSystemAddressForMdl instead of MmGetMdlVirtualAddress .

Thanks and regards
Srinivas

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 6:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

The value returned by MmGetMdlVirtualAddress (or a subsequent result derived
from this value,) is REQUIRED as input to some of the MDL-specific
functions. While it would be wrong to use the returned value as a pointer to
memory, it would be equally wrong to use the value returned by
MmGetSystemAddressForMdl where the return value for MmGetMdlVirtualAddress
is required.

Thus you will see DDK references such as:

“A driver can get the initial CurrentVa for the start of a packet-based DMA
transfer by calling MmGetMdlVirtualAddress. However, the value returned is
an index into the Mdl, rather than a valid virtual address. If the driver
must split a large transfer request into more than one DMA operation, it
must update CurrentVa and Length for each DMA operation.”

(MapTransfer)

The DDK refuses to speak plainly here. CurrentVA is used as an index into
the set of physical pages that describe the user data buffer. The user data
buffer may very well not be PAGE_ALIGNED. The initial value of CurrentVA -
which is to say the value returned by MmGetMdlVirtualAddress is used by
various functions to determine the offset into the physical pages where a
DMA transfer operation should start.

The value returned by MmGetSystemAddressForMdl may not share the same
alignment characteristics. Huge problem then if you substitute this value
instead of the required MmGetMdlVirtualAddress value.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Thursday, April 19, 2001 10:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 1:58pm

As you said I don’t need to view the contents of what MDL is pointing to it
. But I was confused by the statement in the DDK documentation :

“MmGetMdlVirtualAddress returns a virtual address that is not necessarily
valid in the current thread context. Lower-level drivers should not attempt
to use the returned virtual address to access memory, particularly
user-space memory.”

I am trying to create a new MDL and using the Virtual Addresss returned by
MmGetMDlVirtualAddress and then call IoBuildPartialMdl to map from the old
MDL to new MDl created at driver level . Then later it is passed to lower
level driver ( Which I suppose Bus driver ) . When I send an MDL with user
buffer virtual address in it , the lower level driver will not touch the
contents of user buffer while transmitting on the bus . I may be wrong ,
please correct me .

Or when I call IoBuildPartialMdl while it is mapping does it map any
differently so that lower level drivers can use it ?

srinivasa

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 10:27 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

If you actually need to access the contents of the user data directly from
your driver using a pointer, that is what MmGetSystemAddressForMdl gives
you: a kernel virtual address for the physical pages that contain the user
data. But if you are simply setting up MDLs to describe portions of the user
data, then you do not need anything other than the CurrentVA ‘index’
constructed by the opaque (non-pointer) use of the value returned by
MmGetMdlVirtualAddress. I think that you probably do not have to actually
access the buffer contents. Aren’t you just building a set of MDLs to pass
on down to the controller? Unless there is some content within the buffer
that you need to be aware of, you should never have to actually access the
user data. If that is all you are doing then you do not need
MmGetSystemAddressForMdl.

You should be aware that the first driver to call MmGetSystemAddressForMdl
on an MDL incurs a substantial overhead, as the system mapping for the user
buffer is not performed until some kernel component asks for it.
MmGetMdlVirtualAddress has no such overhead associated with it.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Friday, April 20, 2001 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks Mark .

then what would be the best way to get the contents of user buffer pointed
by the MDL in the IRP that is received by the driver ?

Obviously we wanted to tranmit the data from the user buffer ( which is from
application ) So through MDL we would be passing the Virtual address to the
driver ( Though after calling IoAllocateMdl and IoBuildPartialMdl calls).
But as per documentation we may have some problem if used that way .

I understand the point what you are trying to mention. Why microsoft don’t
mention that the use of that particular command is according to the context
of other commands that are used .

As you mentioned I had a problem when I tried to use
MmGetSystemAddressForMdl instead of MmGetMdlVirtualAddress .

Thanks and regards
Srinivas

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 6:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

The value returned by MmGetMdlVirtualAddress (or a subsequent result derived
from this value,) is REQUIRED as input to some of the MDL-specific
functions. While it would be wrong to use the returned value as a pointer to
memory, it would be equally wrong to use the value returned by
MmGetSystemAddressForMdl where the return value for MmGetMdlVirtualAddress
is required.

Thus you will see DDK references such as:

“A driver can get the initial CurrentVa for the start of a packet-based DMA
transfer by calling MmGetMdlVirtualAddress. However, the value returned is
an index into the Mdl, rather than a valid virtual address. If the driver
must split a large transfer request into more than one DMA operation, it
must update CurrentVa and Length for each DMA operation.”

(MapTransfer)

The DDK refuses to speak plainly here. CurrentVA is used as an index into
the set of physical pages that describe the user data buffer. The user data
buffer may very well not be PAGE_ALIGNED. The initial value of CurrentVA -
which is to say the value returned by MmGetMdlVirtualAddress is used by
various functions to determine the offset into the physical pages where a
DMA transfer operation should start.

The value returned by MmGetSystemAddressForMdl may not share the same
alignment characteristics. Huge problem then if you substitute this value
instead of the required MmGetMdlVirtualAddress value.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Thursday, April 19, 2001 10:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 2:12pm

The MmGetMdlVirtualAddress value is really being used as an index into the
start of a physical page,and should be named something like
MmGetMdlUserBufferOffsetIndexIntoFirstPhysicalPageAndDontEverUseThisAsAPoint
erOrYouWillDieAHorribleAndJustlyDeservedDeath

Lower level drivers may indeed access the user’s data, but if they do they
will do so by calling MmGetSystemAddressForMdl or they will suffer the
consequences.

IoBuildPartialMdl uses the existing MDL plus your input values for
‘VirtualAddress’ (our ambiguous friend MmGetMdlVirtualAddress plus some
offset) and Length to create a new MDL. However it does not AND CANNOT
access the user buffer through the value of VirtualAddress.

The existing MDL already contains a complete description of the physical
pages that contain the user data. the MDLs created by IoBuildPartialMdl use
this existing description plus your input values to create subset
descriptions of the same physical pages.

In the ideal MDL path no driver ever accesses the user data buffer directly.
Instead only the MDL is accessed.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Friday, April 20, 2001 1:59 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

As you said I don’t need to view the contents of what MDL is pointing to it
. But I was confused by the statement in the DDK documentation :

“MmGetMdlVirtualAddress returns a virtual address that is not necessarily
valid in the current thread context. Lower-level drivers should not attempt
to use the returned virtual address to access memory, particularly
user-space memory.”

I am trying to create a new MDL and using the Virtual Addresss returned by
MmGetMDlVirtualAddress and then call IoBuildPartialMdl to map from the old
MDL to new MDl created at driver level . Then later it is passed to lower
level driver ( Which I suppose Bus driver ) . When I send an MDL with user
buffer virtual address in it , the lower level driver will not touch the
contents of user buffer while transmitting on the bus . I may be wrong ,
please correct me .

Or when I call IoBuildPartialMdl while it is mapping does it map any
differently so that lower level drivers can use it ?

srinivasa

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 10:27 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

If you actually need to access the contents of the user data directly from
your driver using a pointer, that is what MmGetSystemAddressForMdl gives
you: a kernel virtual address for the physical pages that contain the user
data. But if you are simply setting up MDLs to describe portions of the user
data, then you do not need anything other than the CurrentVA ‘index’
constructed by the opaque (non-pointer) use of the value returned by
MmGetMdlVirtualAddress. I think that you probably do not have to actually
access the buffer contents. Aren’t you just building a set of MDLs to pass
on down to the controller? Unless there is some content within the buffer
that you need to be aware of, you should never have to actually access the
user data. If that is all you are doing then you do not need
MmGetSystemAddressForMdl.

You should be aware that the first driver to call MmGetSystemAddressForMdl
on an MDL incurs a substantial overhead, as the system mapping for the user
buffer is not performed until some kernel component asks for it.
MmGetMdlVirtualAddress has no such overhead associated with it.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Friday, April 20, 2001 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks Mark .

then what would be the best way to get the contents of user buffer pointed
by the MDL in the IRP that is received by the driver ?

Obviously we wanted to tranmit the data from the user buffer ( which is from
application ) So through MDL we would be passing the Virtual address to the
driver ( Though after calling IoAllocateMdl and IoBuildPartialMdl calls).
But as per documentation we may have some problem if used that way .

I understand the point what you are trying to mention. Why microsoft don’t
mention that the use of that particular command is according to the context
of other commands that are used .

As you mentioned I had a problem when I tried to use
MmGetSystemAddressForMdl instead of MmGetMdlVirtualAddress .

Thanks and regards
Srinivas

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 6:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

The value returned by MmGetMdlVirtualAddress (or a subsequent result derived
from this value,) is REQUIRED as input to some of the MDL-specific
functions. While it would be wrong to use the returned value as a pointer to
memory, it would be equally wrong to use the value returned by
MmGetSystemAddressForMdl where the return value for MmGetMdlVirtualAddress
is required.

Thus you will see DDK references such as:

“A driver can get the initial CurrentVa for the start of a packet-based DMA
transfer by calling MmGetMdlVirtualAddress. However, the value returned is
an index into the Mdl, rather than a valid virtual address. If the driver
must split a large transfer request into more than one DMA operation, it
must update CurrentVa and Length for each DMA operation.”

(MapTransfer)

The DDK refuses to speak plainly here. CurrentVA is used as an index into
the set of physical pages that describe the user data buffer. The user data
buffer may very well not be PAGE_ALIGNED. The initial value of CurrentVA -
which is to say the value returned by MmGetMdlVirtualAddress is used by
various functions to determine the offset into the physical pages where a
DMA transfer operation should start.

The value returned by MmGetSystemAddressForMdl may not share the same
alignment characteristics. Huge problem then if you substitute this value
instead of the required MmGetMdlVirtualAddress value.

Mark Roddy
xxxxx@hollistech.com
www.hollistech.com
603 321 1032
WindowsNT Windows 2000 Consulting Services

-----Original Message-----
From: Srinivasa Rao Deevi [mailto:xxxxx@Transilica.com]
Sent: Thursday, April 19, 2001 10:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

Thanks alot MAX .

One more doubt , Even though the use of MmGetVirtualAddress has certain
limitations , the example programs for bulk transfers in USB still use this
and the virtual address returned by it is made available to the lower level
driver. I am not sure that how those drivers work in actual environments .
Because DDk docs says those virtual address which belongs to user space
should not be refered by any lower level drivers. I may be wrong but I am
having some problem when I am trying to implement in the same way (as in
bulk usb sample ).

Thanks and regards
srinivas

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 19, 2001 6:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context

What is the meaning of necessarily valid in current current thread context
when the virtual addresses that are described by the MDL when those pages
are locked by OS ?

This VA can be the user VA which is process-dependent.
If you want to have a kernel VA for the MDL - the VA which is guaranteed to
be the kernel one - use MmGetSystemAddressForMdlSafe, it will allocate
system PTEs pointing to it.
Single-page MDLs are usually “mapped” bu stupidly adding 0x80000000 to the
page’s physical address.

Max

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@transilica.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · April 20, 2001, 2:53pm

Thanks Mark . I understood the point .

regards
Srinivas

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, April 20, 2001 11:09 AM
To: NT Developers Interest List
Subject: [ntdev] Re: doubt about calling thread context