• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            milkyway的窩

            最初想法的誕生地

             

            VirtualAlloc/Copy and MmMapIospace

            Tuesday, March 20, 2007 12:35 PM by Kurt Kennett

            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 Kurt Kennett

            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


            posted on 2007-04-17 13:38 milkyway 閱讀(2906) 評論(0)  編輯 收藏 引用 所屬分類: wince(別人的文章技巧總結)

            導航

            統計

            公告

            隨筆皆原創,文章乃轉載. 歡迎留言!

            常用鏈接

            留言簿(37)

            隨筆分類(104)

            隨筆檔案(101)

            文章分類(51)

            文章檔案(53)

            wince牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            色偷偷91久久综合噜噜噜噜 | 久久无码一区二区三区少妇| 国产精品免费久久| 中文字幕无码久久精品青草| 久久综合九色综合网站| 精品综合久久久久久97超人| 国产2021久久精品| 亚洲av成人无码久久精品| 99久久99久久精品免费看蜜桃| 精品久久久久久无码中文字幕 | 久久精品aⅴ无码中文字字幕不卡| 久久香综合精品久久伊人| 久久久久久国产精品无码下载| 欧美va久久久噜噜噜久久| 人人狠狠综合88综合久久| 精品九九久久国内精品| 蜜臀久久99精品久久久久久小说 | 久久99国产精品成人欧美| 无码人妻少妇久久中文字幕蜜桃| 久久久久久av无码免费看大片| 久久综合国产乱子伦精品免费| 久久国产综合精品五月天| 99久久99久久| 99久久无色码中文字幕| 中文字幕无码免费久久| 国产精品久久久久久久久软件 | 久久久久亚洲爆乳少妇无| 中文字幕无码免费久久| 亚洲欧美久久久久9999| 久久久国产精品| 四虎影视久久久免费观看| 狠狠色丁香婷婷综合久久来来去 | 国产精品久久久久久五月尺| 欧美与黑人午夜性猛交久久久| 精品熟女少妇aⅴ免费久久| 久久精品这里只有精99品| 久久久久久国产a免费观看不卡| 久久久无码精品午夜| 天堂无码久久综合东京热| 久久免费看黄a级毛片| 亚洲色大成网站www久久九|