AIX

AIX

Connect with fellow AIX users and experts to gain knowledge, share insights, and solve problems.

 View Only
  • 1.  Kernel to User Space Memory Mapping

    Posted Sat September 24, 2005 01:06 PM

    Originally posted by: SystemAdmin


    To avoid memory copying, I would like to map a memory area allocated in kernel space into user space. I have done this in my Solaris and Linux device drivers, but I haven't found any way to do it on AIX. Does anyone know a way of doing it? I was hoping to use the mmap call on my driver for this purpose but using an ioctl is also possible. The required action is
    1) A process issues a map request (as an mmap call or an ioctl)
    2) The driver maps a portion of kernel memory to the calling process's address space.

    Is this a doable thing for AIX platforms ?

    Thanks

    Kutluk T.


  • 2.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 09:09 AM

    Originally posted by: BruceSpencer


    The following URL has some information

    http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/understanding_mem_mapping.htm

    Also found the following in a "Migrating Solaris Apps to AIX" guide.

    [b]Memory mapped files[/b]
    Memory mapping is used to map a file into memory for faster I/O. The call to map
    a file is mmap and the arguments to mmap are:
    mmap( baseAddr, length, protection, flags, fileDescriptor,
    offSet )

    baseAddr Desired address to map the file to
    length Number of bytes to map. The OS will round to the nearest page
    size
    protection Access permissions for mapped region
    flags Attributes of mapped region
    fileDescriptor File descriptor of opened file to map into memory
    offSet Offset from the baseAddr to where the file will be mapped

    [i]The mmap call is available on Solaris as well but the behavior is slightly different
    on AIX.[/i] The flags argument allows you to specify certain attributes like
    MAP_FIXED or MAP_VARIABLE. The MAP_FIXED flag specifies that the region
    being mapped should be mapped to the baseAddr if possible. Otherwise, you will
    receive an error. The MAP_VARIABLE flag specifies that the OS should attempt
    to honor the baseAddr address, otherwise return some address that would
    accommodate the request.

    The first issue is a behavior difference between Solaris and AIX. If a process
    maps a file using MAP_FIXED at a specified address, e.g. 0x80000000, and later
    attempts to either map a different or the same file to the same specified address,
    i.e. 0x80000000, Solaris will return without error. AIX will fail with:

    ENOMEM There is not enough address space to map length bytes, or
    the application has not requested X/Open UNIX95 Specification compliant
    behavior and the MAP_FIXED flag was set and part of the address-space
    range (baseAddr, baseAddr+length) is already allocated.

    Obviously, mapping to the same address without unmapping (munmap) is a
    problem and should be corrected by the application.

    A second related issue is how memory mapped files are laid out in memory.
    Consider an application wanting to memory map two files. The first file mapped
    uses MAP_FIXED at address 0x80000000. The second file mapped uses the
    address 0x0. Mapping at 0x0 indicates the operating system should pick the
    address for you. In this particular case, the second file ended up being mapped
    directly after the first mapped file. However, the application at a later time
    attempts to grow the first mapped file region. The application munmap the file and
    attempts to mmap at 0x80000000 with the new/larger size. mmap fails. Whats
    wrong? The problem is with the second mapped file and where it had been
    mapped. The second file was mapped using 0x0 so AIX decided to map it right
    after the first file mapped at 0x80000000. When AIX attempted to map the large
    file, AIX determined that the region available at 0x80000000 would not
    accommodate the new size and fails.

    A third and generally unacceptable issue is unmapping files. On AIX, you can
    unmap as large a region as you want and turn around and mmap the region again
    without errors. Consider the above example of two files being memory mapped
    contiguously. One could munmap the region starting at 0x80000000 all the way to
    the end of the second mapped region since both regions are contiguous. Not a
    wise thing to do, but AIX will permit this type of operation. AIX does not keep track
    of the original size of the mapped region when unmapping. This can lead to
    trouble when the area unmapped is less than the area that was mapped.
    munmap will succeed as long as the size to map is less than or equal to the area
    that was previously unmapped. An attempt to map a region with a large size at
    the same address will fail because a portion of the desired region has not been
    unmapped.



  • 3.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 01:28 PM

    Originally posted by: SystemAdmin


    Thanks for your reply.

    My problem is not exacly mapping a file into memory but mapping a portion of the kernel memory (allocated via the xmalloc call) to the address space of a requesting process.

    The way I did this on Solaris is to use the dev_map entry point for Solaris device drivers and open/mmap the driver file to map the the memory (using some some non-ddi/dki Solaris calls) or open/mmap the /dev/kmem file which represents the kernel memory as in AIX. The latter method fails on AIX so I guess this suggests that /dev/kmem on AIX does not support mmap'ing.

    The allocated data needs to be allocated in global kernel memory and has to be suitable for mapping to the address space of any process that requests so.

    Thanks


  • 4.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 03:17 PM

    Originally posted by: garyrhook


    I haven't done an exhaustive search on when this feature was added, but in AIX 5.3 you can use the vm_galloc kernel service (from your DD/kext) and then use the vm_gatt/vm_gdet system calls to get access from user space. 64-bit kernel only, which is what you really want to focus on, strategically speaking, I think.


  • 5.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 03:21 PM

    Originally posted by: garyrhook


    Nuts. vm_g[b]u[/b]att and vm_g[b]u[/b]det. Search info center for vm_galloc and you'll find both of these in the search results.

    http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/infocenter/base/aix53.htm


  • 6.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 05:06 PM

    Originally posted by: SystemAdmin


    Thanks for your reply.

    vm_galloc and vm_guatt do exactly what I want. But I need to use this mechanism for both 32 and 64 bit kernels. Is there an alternative mechanism to provide the same service with 32 bit kernels ?


  • 7.  Re: Kernel to User Space Memory Mapping

    Posted Tue September 27, 2005 02:24 PM

    Originally posted by: Nicolette


    You can get a good feel for the addresses available with mmap and shmat by looking at the InfoCenter document "Understanding Memory Mapping" which can be found at: http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/understanding_mem_mapping.htm

    A determining factor for which command you will use to map memory is what you are going to use the memory for. See also the article "List of Memory Mapping Services" at
    http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/ls_mem_mapping_srvcs.htm

    To view the memory usage of programs use commands such as svmon as described in the "Performance Guide" located at:
    http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixbman/prftungd/memperf1.htm

    Naturally if you are going to create a heap, you would use the malloc() routine, but for device drivers it is likely you would use mmap(). If you have already read this information and are still having questions, give us more details on how you want to use the memory and we will get you the recommendations from our language group.