Hi all.
I have a serious problem that I can not translate virtual address into
physical address.
First, To create user and kernel shared memory space, I use
ZwCreateSection() and ZwMapViewOfSection() API
and it appear to make user and kernel shared memory space, correctly.
Then, I want to the physical address of the virtual address that is
generated with ZwMapViewOfSection() API.
(Of course, I don’t intend to apply the liner physical address to DMA)
So, I use MmGetPhysicalAddress to get the physical address.
However, MmGetPhysicalAddress() returns ZERO it not seems like correct
physical address.
How I get correct physical address of the virtual address that is
produced with ZwMapViewOfSection() API ?
Regards,
Kazushi
First, there is not a single physical address the pages in the section
are not guaranteed to be physically contiguous. You should be able to
take the virtual address and use IoCreateMdl to map it into the kernel,
and get the physical page addresses if needed.
If you do need to have physically contiguous memory, create it in the
kernel, then have your driver map it to user space as needed. Basically
replace the ZwCreateSection and ZwMapViewOfSection calls with your own
API’s based on IOCTL’s. OSR has a good article on sharing things this
way http://www.osronline.com/article.cfm?id=39
Note another advantage of this approach is that you can clean things up
when the handle from the application closes, your method does not have a
builtin cleanup mechanism.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: kazushi takahashi [mailto:xxxxx@gmail.com]
Posted At: Tuesday, June 15, 2010 8:44 AM
Posted To: ntdev
Conversation: Failed to MmGetPhysicalAddress()
Subject: Failed to MmGetPhysicalAddress()
Hi all.
I have a serious problem that I can not translate virtual address into
physical address.
First, To create user and kernel shared memory space, I use
ZwCreateSection() and ZwMapViewOfSection() API and it appear to make
user and
kernel shared memory space, correctly.
Then, I want to the physical address of the virtual address that is
generated
with ZwMapViewOfSection() API.
(Of course, I don’t intend to apply the liner physical address to DMA)
So, I
use MmGetPhysicalAddress to get the physical address.
However, MmGetPhysicalAddress() returns ZERO it not seems like correct
physical address.
How I get correct physical address of the virtual address that is
produced
with ZwMapViewOfSection() API ?
Regards,
Kazushi
__________ Information from ESET Smart Security, version of virus
signature
database 5197 (20100615) __________
The message was checked by ESET Smart Security.
http://www.eset.com
“The *MmGetPhysicalAddress* routine returns the physical address *corresponding
to a valid nonpaged virtual address*”
Mark Roddy
On Tue, Jun 15, 2010 at 8:43 AM, kazushi takahashi wrote:
> MmGetPhysicalAddress
Don’t forget that pageable virtual address does not have to be backed up by the physical one all the time unless the target buffer is locked in RAM…
Anton Bassov
Hi all.
Thank you for your advices.
Additionally, I find some questions in your replies.
Basically replace the ZwCreateSection and ZwMapViewOfSection calls with your own
API’s based on IOCTL’s. OSR has a good article on sharing things this
way http://www.osronline.com/article.cfm?id=39
I can get useful information thanks to your reply and I have a question.
In this document, I should use my own API’s that call MmAllocatePagesForMdl()
and MmMapLockedPagesSpecifyCache() and so on.
But, as far as I know, I think this method has the big disadvantage
that it can not share
huge memory space (for instance, several hundred) between user and
kernel space.
Is it correct ?
Additionally, I don’t want the physically contiguous address.
Nevertheless, Should I use the own IOCTL API’s? I can not judge.
Would you give me more advices?
Regards,
Kazushi
> Hundreds of what, I guess megabytes?
Yes, hundreds of megabytes.
You asked how to get the physical address,
but you say you do not want contiguous, so why do you need
the physical address.
Actually, I just want a huge memory area which is shared between
kernel and user space (the shared space area links to physical pages
without fail)
It is not important that the physical pages are contiguous whether or
not. This is because; even if the shared area consists of
non-contiguous physical pages, x86 function (actually, I try to use
VMX function) is able to reconstruct as contiguous pages.
Would you give me more advices?
First a huge memory area shared between the kernel and user is not
locked to physical. Locking that much memory to physical has
significant problems if you are doing it on a 32-bit OS since the kernel
will have those addresses exposed and the total kernel address space in
32-bits is 1 or 2 GB.
Now you are throwing in the VMX stuff, most people use VMX under the
kernel. I can only guess you are trying to do something on the order of
the Linux KVM approach.
Tell us what you are doing and maybe we can point out ways around your
requirements.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: kazushi takahashi [mailto:xxxxx@gmail.com] Posted At:
Tuesday, June 15, 2010 11:52 AM Posted To: ntdev
Conversation: Failed to MmGetPhysicalAddress()
Subject: Re: Failed to MmGetPhysicalAddress()
> Hundreds of what, I guess megabytes?
Yes, hundreds of megabytes.
> You asked how to get the physical address, but you say you do not
> want contiguous, so why do you need the physical address.
Actually, I just want a huge memory area which is shared between
kernel and user space (the shared space area links to physical pages
without fail) It is not important that the physical pages are
contiguous whether or not. This is because; even if the shared area
consists of non-contiguous physical pages,
x86 function (actually, I try to use VMX function) is able to
reconstruct as contiguous pages.
Would you give me more advices?
__________ Information from ESET Smart Security, version of virus
signature database 5199 (20100615) __________
The message was checked by ESET Smart Security.
http://www.eset.com