After this lesson, you will be able to:
■ Allocate and use buffers in device drivers.
■ Use embedded pointers in an application.
■ Verify the validity of embedded pointers in a device driver.
Estimated lesson time: 30 minutes.
Understanding Memory Access
Windows Embedded CE works in a virtual memory context and hides the physical memory, as illustrated in Figure 6-8. The operating system relies on the Virtual Memory Manager (VMM) and the processor's Memory Management Unit (MMU) for the translation of the virtual addresses into physical addresses and for other memory access management tasks.
Figure 6-8 Virtual memory regions in kernel space and user space
Physical addresses are not directly addressable by the CPU except during initialization before the kernel has enabled the MMU, yet this does not imply that the physical memory is no longer accessible. In fact, every fully allocated virtual memory page must map to some actual physical page on the target device. Processes in separate virtual address spaces only require a mechanism to map the same physical memory areas into an available virtual memory region to share data. The physical address is the same across all processes running on the system. Only the virtual addresses differ. By translating the physical address per process into a valid virtual address, processes can access the same physical memory region and share data across process boundaries.
As mentioned earlier in this chapter, kernel-mode routines, such as ISRs, can call OALPAtoVA to map a physical address (PA) into a cached or uncached virtual address (VA). Because OALPAtoVA maps the physical address to a virtual address in the kernel space, user-mode processes, such as ISTs, cannot use this function. The kernel space is inaccessible in user mode. However, threads in user-mode processes, such as ISTs, can call the MmMapIoSpace function to map a physical address to a nonpaged, cached or uncached virtual address in the user space. The MmMapIoSpace call results in the creation of a new entry in the MMU Table (TBL) if no match was found or it returns an existing mapping. By calling the MmUnmapIoSpace function, the user- mode process can release the memory again.
Applications and user-mode drivers cannot access physical device memory directly. User-mode processes must call HalTranslateBusAddress to map the physical device memory range for the bus to a physical system memory address before calling MmMapIoSpace. To convert a bus address into a virtual address in a single function call, use the TransBusAddrToVirtual function, which in turn calls HalTranslateBusAddress and MmMapIoSpace.
Allocating Physical Memory
It's possible to allocate a portion of memory so you can use it in a driver or the kernel. There are two ways to do this:
■ Dynamically, by calling the AllocPhysMem function AllocPhysMem allocates contiguous physical memory in one or more pages that you can map to virtual memory in the user space by calling MmMapIoSpace or OALPAtoVA, depending on whether the code is running in user mode or kernel mode. Because physical memory is allocated in units of memory pages, it is not possible to allocate less than a page of physical memory. The size of the memory page depends on the hardware platform. A typical page size is 64 KB.
■ Statically, by creating a RESERVED section in the Config.bib file You can statically reserve physical memory by using the MEMORY section of a run-time image's BIB file, such as Config.bib in the BSP folder. Figure 6-9 illustrates this approach. The names of the memory regions are for informational purposes and are only used to identify the different memory areas defined on the system. The important pieces of information are the address definitions and the RESERVED keyword. According to these settings, Windows Embedded CE excludes the reserved regions from system memory so that they can be used for DMA by peripherals and data transfers. There is no risk of access conflicts because the system does not use reserved memory areas.
Figure 6-9 Definition of reserved memory regions in a Config.bib file
Application Caller Buffers
In Windows Embedded CE 6.0, applications and device drivers run in different process spaces. For example, Device Manager loads stream drivers into the kernel process (Nk.exe) or into the user-mode driver host process (Udevice.exe), whereas each application runs in its own individual process space. Because pointers to virtual memory addresses in one process space are invalid in other process spaces, you must map or marshal pointer parameters if separate processes are supposed to access the same buffer region in physical memory for communication and data transfer across process boundaries.
Using Pointer Parameters
A pointer parameter is a pointer that a caller can pass as a parameter to a function. The DeviceIoControl parameters lpInBuf and lpOutBuf are perfect examples. Applications can use DeviceIoControl to perform direct input and output operations. A pointer to an input buffer (lpInBuf) and a pointer to an output buffer (lpOutBuf) enable data transfer between the application and the driver. DeviceIoControl is declared in Winbase.h as follows:
WINBASEAPI BOOL WINAPI DeviceIoControl (HANDLE hDevice,
DWORD dwIoControlCode,
__inout_bcount_opt(nInBufSize)LPVOID lpInBuf,
DWORD nInBufSize,
__inout_bcount_opt(nOutBufSize) LPVOID lpOutBuf,
DWORD nOutBufSize,
__out_opt LPDWORD lpBytesReturned,
__reserved LPOVERLAPPED lpOverlapped);
Pointer parameters are convenient to use in Windows Embedded CE 6.0 because the kernel automatically performs full access checks and marshaling on these parameters. In the DeviceIoControl declaration above, you can see that the buffer parameters lpInBuf and lpOutBuf are defined as in/out parameters of a specified size, while lpBytesReturned is an out-only parameter. Based on these declarations, the kernel can ensure that an application does not pass in an address to read-only memory (such as a shared heap, which is read-only to user-mode processes, but writable to the kernel) as an in/out or out-only buffer pointer or it will trigger an exception. In this way, Windows Embedded CE 6.0 ensures that an application cannot gain elevated access permissions to a memory region through a kernel-mode driver. Accordingly, on the driver's side, you do not have to perform any access checks for the pointers passed in through the XXX_IOControl stream interface function (pBufIn and pBufOut).
Using Embedded Pointers
Embedded pointers are pointers that a caller passes to a function indirectly through a memory buffer. For example, an application can store a pointer inside the input buffer passed in to DeviceIoControl through the parameter pointer lpInBuf. The kernel will automatically check and marshal the parameter pointer lpInBuf, yet the system has no way to identify the embedded pointer inside the input buffer. As far as the kernel is concerned, the memory buffer simply contains binary data. Windows Embedded CE 6.0 provides no mechanisms to specify explicitly that this block of memory contains pointers.