VirtualCopy can be a bit confusing to use.
http://msdn2.microsoft.com/en-us/library/aa908789.aspx
Let's look at the parameters. I've commented with -- after each of them.
lpvDest
[in] Pointer to the destination memory, which must be reserved.
-- This means that the destination range of VIRTUAL memory must already be reserved by a call to VirtualAlloc(). You must have allocated a range of virtual memory that you are going to map to some physical range.
lpvSrc
[in] Pointer to committed memory.
-- This is the range of *either* VIRTUAL *or* PHYSICAL memory that you want to map the range specified by the 'lpvDest' parameter to.
If you specify a VIRTUAL address and omit the PAGE_PHYSICAL flag from the fdwProtect parameter, then you are simply saying "Copy the mapping at the lpvSrc address to the lpvDest address". This just means that there will be two ranges of virtual memory that point to the same physical range.
If you specify a PHYSICAL address (shifted right 8 bits) and include the PAGE_PHYSICAL flag in the fdwProtect parameter, then you are saying "Map the range at the lpvDest address to this specific physical address". This sets your new range of virtual memory to point to a piece of physical memory.
cbSize
[in] Size, in bytes, of the region. The allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+cbSize. This means that a 2-byte range straddling a page boundary causes both pages to be included in the allocated region.
-- pretty straight forward here.
fdwProtect
[in] Type of access protection. If the pages are being committed, any one of a number of flags can be specified, along with the PAGE_GUARD and PAGE_NOCACHE, protection modifier flags. The following table shows the flags that can be specified.
-- 'Reserving' a page means you're allocating a range of virtual memory but not pointing it at anything yet. 'Commiting' a page means you are actually taking up physical storage somewhere - be it in RAM or in physical addres space. For the purposes of our discussion here, you would normally map registers and i/o space with PAGE_NOCACHE. If you used a physical address (shifted right 8 bits) in the lpvSrc parameter, then you would also specify the PAGE_PHYSICAL flag.
quetion:
If I want to access some physical memory in my driver, can I do like these way?
Method (1) define static map relationship in OEMAddressTable and reserve difined virtual address in config.bib first, then use VirtualAlloc() and VirtualCopy() without the page_physical parameter.
or (2) directly use MmMapIoSpace() or VirtualAlloc+Copy() with the page_physical parameter
answer:
Yes, either of those would work I believe. #2 is the preferred/recommended method
Monday, March 26, 2007 12:07 PM by
Wow! Lots of interest in VirtualCopy! Ok, I'll try to be super-clear here.
VirtualCopy *copies* or *sets* a range of virtual addresses.
- You use it to *copy* an existing Virtual->Physical mapping (no matter where it is).
OR
- You use it to *set* a mapping to a range of physical addresses.
In *either* case, the virtual memory you want to create the new map in must already be allocated (via VirtualAlloc()).
OEMAddressTable is a static (unchanging, available at startup without doing any work or setup) table of virtual -> physical mappings. The kernel is the only thing that has default access to the resources mapped by this table. If you are operating outside the OAL (i.e. in any kind of driver or application), you must use VirtualCopy() to copy or create memory page mappings. As mentioned above, you can copy any existing mapping as long as you have access to it. This includes a static mapping done by the OEMAddressTable. Some people will map all resources in the OEMAddressTable (so the kernel has access to everything), then just copy those mappings in drivers when they need to. This is not a best practice because it makes driver code less portable -- it is better to read the physical address of a component from the registry, then use the value found there to map to it. If you do this your driver code does not have to change if it is moved to a different platform or extended to use multiple components in different physical locations.
A mapping does not have to exist in OEMAddressTable in order for you to access the physical resources mapped. You can create a new mapping unknown to the OEMAddressTable by using VirtualCopy with the PAGE_PHYSICAL flag.
MmMapIoSpace is a CEDDK function -- it simply does the appropriate calls to VirtualAlloc/VirtualCopy. You could write your own MmMapIoSpace if you wanted to. Some people have in the past - calling the function "VirtualMemCopyPhysical" or something like that. Some platforms need to modify the MmMapIoSpace to set Virtual mapping attributes when pages are mapped (hence the original purpose for this blog entry).
Using flags like PAGE_EXECUTE_READWRITE with VirtualCopy are a 'request'. If the platform/CPU does not have a differentiation between executable pages and non-executable pages, the EXECUTE property will not be able to be set. For example, the X86 CPUs can explicitly state that memory is executable, but can't be read or written to. The ARM processors have no notion of this - you can read it or read and write it.
In Windows CE 5.0 and earlier, virtual allocations below 2MB come out of the address space of the process calling it, while allocations above 2MB come out of the shared address space.
Sue