Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 62
Текст из файла (страница 62)
Figure 7.15 shows how these features allow the TLBand cache to contain multiple process memory contexts simultaneously,even when the processes map the same virtual address.Page Directory 1Page TablesPage table 1RAM PagePhysicaladdress 1(PA1)Data1contextswichVirtual Address(VA)Page Directory 2Page table 2Physicaladdress 2(PA2)Data2TLBCacheVAIndexSet 1Set 2Set 3Set 4...tag: PA1tag: PA2Data1Data2Entry 1Entry 2Entry 3...ASID1:VA -> PA1ASID2:VA -> PA1Figure 7.15 Homonyms in ARMv6When compared with the moving memory model, this design:• Still provides up to 2 GB of per-process virtual address space• Requires moderate additional memory overhead for each process(4 or 8 KB)290MEMORY MODELS• Has no requirement to flush the caches or TLBs on a context switch• Does not make loaded program code globally visible• Marks memory that holds data so that it cannot be executed as code.The performance improvement that comes as a result of eliminatingthe cache flush on context switch is the most significant benefit of thismemory model.
It also ensures that this is a better memory model forthe future, as we will see continuing increases in cache size and CPU tomemory performance ratio.The last two points in the previous list improve the robustness of theOS as a whole, but also increase the protection provided for platformsecurity, which you can read more about in Chapter 8, Platform Security.Revisiting the synonym problemAlthough the multiple memory model is an improvement on the movingmemory model, it is not without its own complexities. The most awkwardissue is related to the solution for the synonym problem – providinga second or alias virtual address for the same physical address.
Theproblem stems from the use of the virtual address as the initial index intothe cache to select the small set of lines from which to determine anexact match using the physical address. Figure 7.16 primarily illustratesthe ideal situation with a synonym mapping – where the cache resolvesboth virtual addresses to the same cache line and data.However, the cache indexing is done using the lower bits of the virtualaddress. For obvious reasons, the bottom 12 bits of the virtual addressand physical address are always identical (when using 4 KB pages).
Whatcould happen if the cache uses 13 bits for the index?Suppose that the page at physical address 0x00010000 was mappedby two virtual addresses: 0x10000000 and 0x20001000. Then we writeto the memory at 0x10000230, which results in an entry in the cache inthe index set for 0x230 (low 13 bits) with the physical tag 0x00010230.If we now try to read the address 0x20001230 (which according to ourmapping is the same memory), this will look up entries in the cache indexset for 0x1230 and not find the previous entry. As a result the cachewill end up containing two entries which refer to the original physicaladdress.
The dotted entry in the cache in Figure 7.16 illustrates this effect.This is the very problem we thought we had eliminated.If the cache is small enough or the index sets within the cache largeenough (commonly known as the cache associativity), then no more than12 bits are used for the virtual index. In this case, the problem does notarise as there is a unique set within the cache for every physical address.If 13 or more bits of the virtual address are used for the cache index,then there can be multiple index sets in which a physical address maybe found – which one depends on the virtual address used to map it.
TheTHE MEMORY MODELSPage DirectoryPage Tables291RAM PageVirtual Address 1(VA1)Page table 1PhysicalAddress (PA)DataPage table 2Virtual Address 2(VA2)CacheVA1VA2Different colouredvirtual addressesare still a problemIndexSet 1Set 2Set 3Set 4...tag: PATLBDataEntry 1Entry 2Entry 3...VA1 -> PAVA2 -> PAtag: PADataFigure 7.16 Synonyms in ARMv6one or more bits of virtual address that select which of these sets are saidto determine the color of the page.The solution adopted by EKA2 for this problem is to ensure that allvirtual to physical mappings share the same color – that is, all of thevirtual addresses used to map a given physical page must have the samevalues for the bits that determine the color of the page.
Thus every cachelookup using any of these virtual addresses will resolve to the same entryin the cache.7.4.2.3 DesignIn some respects the design of the multiple memory model is morestraightforward, as there is never the need to work out where somememory happens to be at a given moment in time. If you know whichprocess has the memory and you have the virtual address, it is just amatter of inspecting the process’s page directory to locate the memory – remembering, of course, that the addresses in the page directoryare physical addresses and translation to a virtual address is required toinspect the page table.In this model, the concept of a chunk is less fundamental to the overalldesign.
The design does not require such an object to exist – but as the292MEMORY MODELSmain interface between the memory model and the kernel is in terms ofchunks due to their significance for the moving memory model, they stillform an integral part of this memory model.Address spacesThe kernel process owns the global page directory, which is referencedby TTBR1. All of the pages mapped by this page directory are marked asglobal, which means that the MMU will create global TLB entries thatcan be used by any process.The memory model allocates an ASID for each user-mode process.ARMv6 only supports 256 distinct ASIDs and thus limits the OS torunning at most 256 concurrent processes.
This is considered to besufficient! This also provides a limit for the number of per-process, orlocal, page directories – so these are conveniently allocated in a simplearray. Memory is only committed for a local page directory when theASID is in use by a process. When a process is running, TTBR0 is set tothe local page directory for the process.Depending on its type, the memory model will allocate a chunk inthe global page directory or in the local one.
Examples of memory that isallocated in the global directory:• The global directory maps the XIP ROM as all processes must see thiscode• All processes share the locale data so this is allocated in the globaldirectory• Any thread that is running in supervisor mode should have access tokernel data and this is allocated in the global chunk.Examples of memory that is allocated in the local directory:• Stack and heap chunks that are private to the process• Shared chunks that may also be opened by other processes• Program code that is loaded into RAM.The last two of these examples are memory that the operating systemcan map into more than one process.
Unlike the moving memory model,however, chunks that can be shared between user processes always havethe same base address in all processes. The multiple memory modelachieves this by using a single address allocator for all memory that canbe shared. This also ensures that shared memory does not suffer from thecoloring problem as the virtual address is common to all processes.In the moving memory model, the DProcess objects maintain acollection of the chunks that they currently have access to.
This is alsoTHE MEMORY MODELS293necessary to ensure that on a context switch the chunk is made accessibleto the program, as well as to allow address lookup when the processis not in context. In the multiple model, this collection still exists butonly provides a means to track the number of times a given chunk hasbeen opened within the process so that it can be removed from thememory map only after the last reference is closed. The process’s localpage directory maps the chunk to provide access when the program isrunning, and to provide lookup for the memory model with the processis not in context.The model also keeps an inverse mapping from a shared chunk tothe processes that have opened it, so that the memory model can reflectadjustments to the chunk size in all affected page directories.ProtectionProviding process memory protection with the multiple model is simplerthan with the moving model, which required domains to make it efficient.Multiple page directories provide most of the protection: memorythat is private to a process is not present in the memory map whenanother process is running.
The use of ASIDs and the physically taggedcache ensure that all cache data and mappings are only applied to theowning process. Thus, unlike the moving memory model, the multiplemodel applies full access permissions to memory mapped by the localpage directory.The model applies supervisor-only permissions to kernel data mappedby the global page directory, so that only supervisor modes can access this.The model sets the never-execute permission on all data memory, suchas stacks and heaps.
This prevents buffer-over-run attacks being used tolaunch malicious code in the device.Non-XIP user-mode program code is now mapped in the local pagedirectory rather than globally. This allows the memory model to restrict thevisibility of such code to just the processes that have explicitly loaded it.The result is that the memory access matches the ideal situationdescribed in Section 7.2.1.3.Memory mapFigures 7.17 and 7.18 show how the multiple memory model dividesvirtual address space.
I have depicted the case in which the local pagedirectory is 8 KB in size. Again, these diagrams are not to scale.A final word on chunksSome might suggest that the chunk is a very high-level interface to providethe primary means of describing and controlling the memory allocatedand mapped by a process, and that a simpler, lower-level interface wouldprovide flexibility with less complexity.The development of the disconnected chunk illustrates the need forincreasing flexibility and support for alternative allocation strategies.294MEMORY MODELS100000000fff00000exception vectorsextra kernel mappings(I/O, RAM loaded device drivers)globalpagedirectoryc9200000c8000000c4000000c3000000kernel data, heap and stackspage tablesprimary I/O mappings setup up by bootstrapmemory management – see detailed mapc0000000RAM drivea0000000user global area90000000ROM8000000070000000RAM loaded code –size depends on physical RAMuser shared datalocalpagedirectory4000000038000000DLL static data –size depends on physical RAMuser local data0040000000000000unmapped NULL pointer trapFigure 7.17 Full memory map for the multiple memory modelWithin the multiple memory model there is an attempt to escape fromthe notion that all memory belongs to a chunk in the handling of programcode that is loaded into memory.However, because the moving memory model depends on the use ofchunks to describe all of its memory, while Symbian OS supports ARMv5,chunks will continue to be the primary means of describing the memorythat is mapped by a process, and as the abstract interface between generickernel software and the memory model.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
