Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 59

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 59)

Requests are always completedthrough this function, which writes the 32-bitstatus word into the target (requesting) thread’smemory.As this is the basis for all inter-threadcommunication, performance is paramount,and so the memory model usually implementsthis operation as a special case of writing toanother thread’s memory space.274MEMORY MODELS7.4 The memory modelsUp to this point we have looked at a number of the problems faced whenreconciling the need for Symbian OS to be open to third-party software,and yet robust against badly written or malicious programs. However, Ihave so far avoided providing the precise details of how these issues areresolved in EKA2.

The reason for this is that the best solution depends onthe design of the memory management hardware – and there are two verydifferent designs of the level 1 memory sub-system employed in ARMprocessors. This has led to two different memory model implementationsfor devices running Symbian OS on ARM processors.We developed the first implementation on EKA1, in the early days ofSymbian OS, for version 3 of the ARM Architecture (ARMv3). The reasonthis is known as the moving memory model will become apparent as Iexplain its motivation and design.

We developed and optimized this firstimplementation gradually, all the way through to version 5 of the ARMArchitecture (ARMv5) and use it on both EKA1 and EKA2.For version 6 of their architecture (ARMv6), ARM made a radicaldeparture from their previous MMU and cache designs. At this point itmade sense for Symbian OS to replace the moving model with a newdesign, the multiple memory model, which would make the most ofthe ARMv6 features and provide enhanced performance, reliability androbustness for Symbian OS.For both of these memory models, we will look at the hardwarearchitecture, describe how this is utilized to provide the memory modelservices and present the memory map, which depicts the way that thevirtual address space is allocated to the OS.For completeness, I will also briefly describe the two other memorymodels provided with EKA2: the direct memory model, enabling EKA2 torun without the use of an MMU, and the emulator memory model, whichwe use to provide a memory environment on the emulator that matcheshardware as close as possible.7.4.1 The moving modelWe developed this memory model specifically for ARM processors up toand including those supporting ARMv5 architecture.7.4.1.1 HardwareThe ARM Architecture Reference Manual1 provides a detailed descriptionof the memory sub-system in ARMv5.

Here I will describe those featuresthat have a significant impact on the memory model design.1ARM Architecture Reference Manual, by Dave Seal. Addison-Wesley Professional.THE MEMORY MODELS275Virtual address mappingIn ARMv5, the top-level page directory has 4096 entries, each of whichis 4 bytes, making the directory 16 KB in size. Many operating systemsthat provide individual process address spaces use the simple techniqueof allocating a different page directory for each process – and then thecontext switch between processes is a straightforward change to theMMU’s base register (the TTBR). However, on devices with limited RAM,we considered allocating 16 KB per process excessive and so we neededan alternative scheme for managing multiple address spaces.ProtectionARMv5 provides two systems for protecting memory from unwantedaccesses.The first of these systems is the page table permissions: each page ofmemory that is mapped has bits to specify what kind of access is allowedfrom both user and supervisor modes.

For example, a page can be markedas read-only to all modes, or no-access in user modes but read/write forsupervisor modes. Obviously, memory that is not referenced in the currentaddress map cannot be accessed either.The second protection system is called domains. ARMv5 supports upto 16 domains. Each entry in the page directory contains a field to specifyin which domain this address range lies. Thus, every mapped page livesin exactly one domain. The MMU has a register that controls the currentaccess to each domain, with three settings: access to the domain is notallowed and always generates a fault, access to the domain is alwaysallowed and page table permissions are ignored, or access to the domainis policed by the page table permissions.Using domains allows large changes to the memory map and effectiveaccess permissions to be made by small changes to the page directoryentries and to the domain access control register (DACR).CachesThe ARMv5 cache design uses a virtually indexed and virtually taggedcache – this means that the virtual address is used to look up the setof cache lines that may contain the data being requested, and also toidentify the exact cache cell that contains the data.

The benefits are thatno address translation is required if the data is in the cache, theoreticallyreducing power requirements. In practice, the MMU must still check theTLB to determine the access permissions for the memory.However, as I discussed earlier, in a system that is managing multipleaddress spaces we expect the same virtual address to sometimes referto two different physical addresses (depending on which process iscurrent). This form of multiple mapping is sometimes referred to as ahomonym – the same virtual address may ‘‘mean’’ more than one thing.There are also situations where we might wish to use two different276MEMORY MODELSvirtual addresses to refer to the same physical memory, for example whensharing memory between processes or with a peripheral.

This other formof multiple mapping is called a synonym – different virtual addresses havethe same ‘‘meaning’’.Figure 7.9 illustrates the problem of homonyms in ARMv5. Only oneof the data items can be cached for the virtual address at any point intime because the MMU uses the virtual address to identify that item inthe cache. We can only support the use of multiple overlapping addressspaces by removing the virtual address and data from the cache duringPage DirectoryPage TablesPage table 1RAM PagePhysicaladdress 1(PA1)Data1contextswichVirtual Address(VA)Page table 2Physicaladdress 2(PA2)Data2TLBCacheVAIndexSet 1Set 2Set 3Set 4...tag: VAFigure 7.9Data?Homonyms in ARMv5Entry 1Entry 2Entry 3...VA -> PA?THE MEMORY MODELS277a context switch between the processes, ensuring that any updates arecopied back to main memory.

Otherwise the second process will onlyever see (and access) the first process’s memory.In addition, the TLB cannot contain both of the mappings, and so thememory model also invalidates the TLB during a process context switch.As a result, a context switch that changes the virtual memory map impactsboth performance and power consumption.The problem of synonyms on such hardware is illustrated in Figure 7.10.This is slightly more complex, as the different virtual addresses will bothappear in the cache in different places. This can result in confusing effects,because writing through one address may not be visible if read backthrough the other.

This can only be solved by ensuring that the memorymodel does not map the same physical memory with two virtual addressesat the same time, and that if the virtual address needs to be changed thenthe cache data must be flushed.Page DirectoryPage TablesRAM PageVirtual Address 1(VA1)Page table 1PhysicalAddress (PA)DataPage table 2Virtual Address 2(VA2)CacheVA1VA2IndexSet 1Set 2Set 3Set 4...tag: VA1TLBDataEntry 1Entry 2Entry 3...VA1 -> PAVA2 -> PAtag: VA2Data?Figure 7.10 Synonyms in ARMv5As with almost all new high-specification CPUs, the code and datacaches are separated – this is sometimes referred to as a Harvard cache.

(InChapter 17, Real Time, I discuss the performance implications of differentcache types.) Aside from general benefits that the Harvard cache is knownto provide, the moving memory model specifically uses it to ensure thatthe instruction cache does not need to be managed on a context switch.278MEMORY MODELS7.4.1.2 Memory model conceptThe moving memory model uses a single page directory for the wholeOS, and provides multiple overlapped process address spaces by movingblocks of memory (changing their virtual address) during a context switch.This is how the memory model derives its name.Simple arithmetic shows that each page directory entry maps 1 MB ofaddress space.

Changing the domain specified in the entry provides easycontrol of the access policy for this memory range. The memory modelcan move this address range, whilst simultaneously changing the accesspermissions by writing a new entry in the page directory and resetting theold entry (two 32-bit writes).For example, suppose we have a page table that maps a set ofpages, each with ‘‘user no-access, supervisor read/write’’ permissions.Now we create a page directory entry in the second position in apage directory, allocate it to domain 0 and set the DACR to ignorepermissions for this domain. We can now access the pages using theaddress range 0x00100000-0x001fffff with full access from bothuser and supervisor modes as the permission bits are being ignored.

Характеристики

Список файлов книги