Understanding VirtualSetAttributes
Posted by Kurt Kennett
Virtual Memory is fantastic. It allows you to create this personalized ‘view’ of the memory space of a computer, and rearrange where things are physically to suit your desires. This is especially good for the organization of registers of memory-mapped peripherals. By allocating a range of virtual memory, and mapping that memory onto a physical register bank, you get a pointer to a C-like structure containing fields that correspond to each register.
This procedure is fairly straightforward, and allows easy access to the hardware registers of many types of CPUs and peripherals in a Windows CE system. Usually this is accomplished via one of two mechanisms:
1) VirtualAlloc() + VirtualCopy() / VirtualFree()
a. A range of virtual address space is allocated that can map the physical space needed.
b. The virtual to physical mapping is set up for those pages
c. When necessary, the range of virtual pages is released and the mapping destroyed.
-OR-
2) MmMapIoSpace() / MmUnmapIoSpace()
a. This effectively does both of the (a) and (b) steps above in one function call, with fixups on the address if it is not page-aligned.
The functions in (1) are exported to all drivers and applications. The functions in (2) are implemented as part of the CEDDK (CE Driver Development Kit), and are customizable for any particular platform.
With some new processor systems, it becomes optional and sometimes necessary to set ‘attributes’ on virtual memory pages that map specific portions of physical memory. This is done to set qualities on the physical resources that are mapped. For example, TLB (Translation Lookaside Buffer) entries for a set of virtually mapped pages may need to be configured with specific attributes in order to allow a particular bus on the system to access the memory. If an operating system has segmented data and code areas, it can set the ‘no execute’ bit to make sure the CPU doesn’t fetch instructions from data regions. Another example is ARM’s TrustZone technology, which uses a ‘secure’ bit to establish privilege on certain memory regions. One of the most common examples is a display buffer, where you do not want to cache writes to a frame buffer, but want to use a hardware write buffer instead.
To allow this type of customization, the VirtualSetAttributes() function is provided. This allows us to manually call the function after the sequence in (1) above, or automatically in the function provided by an OEM in (2). Using the mechanism in (2) is more desirable, as it leads to more portable code (less specificity with regard to setting attributes for an end system in driver code). However, using (2) does not easily allow for multiple register banks to be allocated in one virtual page (leading to waste of virtual address space). Depending on your needs, you can use whichever method you desire.
By default the memory system is generic and does not know which buses are used to access a particular piece of physical memory. Because of this, if the default flags are used, a peripheral bus might not be accessed properly. You can set the attributes properly for your particular system by using the VirtualSetAttributes(). For example:
/* allocate dwBytes of virtual address space */
void *pVirtMem = VirtualAlloc(NULL,
dwBytes,
MEM_RESERVE,
0);
/* map the memory to physical address 0x10000000 (arbitrary) */
VirtualCopy(pVirtMem,
(void *)(0x10000000>>8),
dwBytes,
PAGE_PHYSICAL | PAGE_READWRITE | PAGE_NOCACHE);
/* set the attributes on the pages */
VirtualSetAttributes(pVirtMem,
dwBytes,
0x13,
0x13,
NULL);
The attributes on the set of pages mapping the physical address would now have the bits 0x13 set, to allow for possible use of a specific bus that holds the physical peripheral. The use of 0x13 is arbitrary here, because these flags are CPU-architecture specific. Consult the appropriate documentation for your CPU architecture to learn what each bit does in your page table entry. You might accidentally change the physical page number, which could cause some unexpected behavior! Caveats, and more information on the arguments to the virtual memory functions discussed here, can be found on MSDN help.
