• <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 閱讀(2907) 評論(0)  編輯 收藏 引用 所屬分類: wince(別人的文章技巧總結)

            導航

            統計

            公告

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

            常用鏈接

            留言簿(37)

            隨筆分類(104)

            隨筆檔案(101)

            文章分類(51)

            文章檔案(53)

            wince牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            性做久久久久久免费观看 | 精品国产日韩久久亚洲| 伊人久久五月天| 久久亚洲美女精品国产精品| 人妻无码αv中文字幕久久| 久久99精品久久久久久久久久| 久久99国产精品久久99| 精品久久久久久无码人妻蜜桃| 国产精品99久久久久久宅男小说| 无码国内精品久久人妻蜜桃| 久久国产精品无码HDAV| 精品久久人人妻人人做精品| 综合久久一区二区三区| 精品国产VA久久久久久久冰 | 国产精品成人无码久久久久久| 久久久久久毛片免费看 | 久久久久久国产精品免费免费| 久久久久久午夜成人影院| 久久国产免费直播| 无码日韩人妻精品久久蜜桃| 99久久99久久久精品齐齐| 欧美久久亚洲精品| 日本道色综合久久影院| 五月丁香综合激情六月久久 | 久久精品免费观看| 久久久久久午夜成人影院 | 国产亚州精品女人久久久久久 | 久久久久av无码免费网| 国产成人久久精品二区三区| 99久久国产综合精品女同图片 | 精品久久亚洲中文无码| 久久精品国产亚洲一区二区三区| 丁香五月网久久综合| 色8久久人人97超碰香蕉987| 欧美久久久久久精选9999| 久久精品视频网| 丰满少妇高潮惨叫久久久| 久久综合香蕉国产蜜臀AV| 亚洲国产精品成人久久| 久久精品国产亚洲AV无码娇色| 久久综合国产乱子伦精品免费|