Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleider: ir. Niels Penneman

Virtualisatie van Android Henri De Veene Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleider: ir. Niels Penneman Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2011-2012

Voorwoord Mijn interesse voor het onderwerp van deze masterproef komt voort uit mijn interesse in Linux en in het algemeen openbronsoftware. Gelet op het feit dat smartphones en tablets met Android de laatste jaren alomtegenwoordig geworden zijn en dat virtualisatie aan een opmars bezig is, zowel in de serverwereld als in de wereld van mobiele toestellen, was dit het ideale onderwerp voor mijn masterproef. De masterproef is echter niet van een leien dakje verlopen en ik wil daarom de mensen bedanken die mij het afgelopen jaar gesteund hebben. Eerste en vooral zou ik mijn begeleider Niels Penneman en mijn promotor prof. Bjorn De Sutter willen bedanken voor alle hulp tijdens de maanden dat ik op het Technicum kwam werken en voor alle opbouwende feedback op mijn werk. Uiteraard wil ik hen ook bedanken om mij de kans te geven om mijn masterproef dit jaar nog af te werken, zelfs na het tijdverlies door mijn ongeval. Ik wil natuurlijk ook mijn ouders, broers en zussen bedanken voor het geduld dat ze hebben moeten uitoefenen, niet enkel dit jaar maar gedurende de afgelopen vijf jaar. Het was niet altijd even gemakkelijk maar ze zijn mij altijd blijven steunen en geloven. Een speciale dankjewel gaat naar mijn oudste zus Elise om mijn thesis volledig te controleren op taalfouten! Mijn vriendin Karen wil ik natuurlijk ook bedanken. Het was niet gemakkelijk om mij telkens opnieuw zien te verdwijnen in de examenperiodes. Toch heeft ze me ook altijd gesteund in al mijn werk. Als laatste wil ik nog mijn vrienden van de scouts, The Woods,... bedanken om in de gaten te houden dat ik niet zou veranderen in een computer. Bedankt allemaal! Henri De Veene 21 juni 2012 i

Toelating tot bruikleen De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef. Henri De Veene 21 juni 2012 ii

Virtualisatie van Android door Henri De Veene Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2011-2012 Universiteit Gent Faculteit Ingenieurswetenschappen en Architectuur Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleiders: ir. Niels Penneman, dr. Jonas Maebe Samenvatting In deze masterproef wordt het werk voorgesteld dat uitgevoerd werd om Android te ondersteunen met een ARM hypervisor. De ARM architectuur en de werking van de initiële hypervisor worden eerst besproken om de lezer inzicht te laten krijgen in de huidige problemen. Daarna wordt in meer detail uitgelegd wat de problemen zijn en hoe deze opgelost werden. Ten slotte worden de conclusies gemaakt en de wordt een overzicht gegeven van het werk dat in de toekomst nog moet gebeuren om het werk te voltooien. Trefwoorden: virtualisatie, hypervisor, Android, OMAP, ARM iii

Virtualizing Android Henri De Veene Supervisor(s): prof. Bjorn De Sutter, prof. Koen De Bosschere, Niels Penneman Abstract This article presents the work that has been done to improve an ARM hypervisor in order to support Android. The work can be subdivided in several areas: adding support for the Thumb- 2 instructionset, improving the memory management system, improving virtual hardware support and adding unittest functionality. Keywords Hypervisor, ARM, OMAP, Android, virtualization IMPROVEMENTS and progress in the technical field made the development of high-performance mobile devices possible, which incorporate a number of different functionalities. This, however, is achieved by combining several dedicated processing units together which leads to an inefficient device because the different processing units will never be fully in use, all at the same time. With virtualization it is possible to eliminate this inefficiency by letting all the software share a single powerful processing unit. This requires a hypervisor which manages the different software components to run together without the possibility of interference between the different components. In a collaboration between The University of Manchester and Ghent University a hypervisor for the ARM architecture is being developed. The hypervisor does not yet support Android, which is the subject of this Master s thesis. I. Android Google Android is currently the most popular mobile operating system. It is an opensource operating system and uses the Linux-kernel, which is also opensource software. Because Android is an excellent OS to support with the hypervisor because it is opensource software which can make development easier. The most popular version of Android uses version 2.6.37 of the Linux-kernel. This is important because it has much better support for the OMAP System-on-Chip (SoC) than the Linux version which has been used to develop the hypervisor prior to this Master s thesis. The OMAP SoC includes the ARM Cortex-A8 processor and is part of the BeagleBoard hardware on which the hypervisor is currently being developed. II. The hypervisor The hypervisor is a type 1 hypervisor which uses the technique full virtualization for its virtual machines [1]. This means that the virtual hardware behaves the same way as the real hardware and no modifications need to be made to the guestsoftware, as opposed to paravirtualization. To achieve full virtualization, the hypervisor uses dynamic binary translation (DBT). This technique replaces sensitive instructions in guest code with supervisor calls (SVC). A sensitive instruction is an instruction that depends on the configuration of the hardware [2]. Because guestcode is executed in user mode an exception will be thrown when executing an SVC instruction. This exception is catched by the hypervisor which will then emulate the replaced instruction. With DBT, the hypervisor can control the hardware and guarantee the proper execution of a guest OS. The hypervisor uses shadow page tables to share the physical memory between serveral guest operating systems. Each guest maintains its own page tables, but these are not used for address translation. Instead the hypervisor copies the structure of the guest page table to the shadow page table and configures the hardware to use this table for address translation. With shadow page tables, the hypervisor can control which regions of the physical memory are used by which guest OS. III. Shortcomings There are three major areas in which the hypervisor does not yet suffice to support the Android operating system. Firstly: the support for the Thumb-2 lacks support for conditional execution of instructions. This instruction set is used by the just-intime compiler of Android and should thus be fully supported. Secondly: the memory management has some problems preventing Linux 2.6.37 from booting. And thirdly: not all the hardware used by Linux 2.6.37 has been virtualized. IV. Unittesting When testing certain parts of the hypervisor, in particular concerning corner cases, it is not favorable to run an entire operating system. This approach has two problems: it will be slow and execution may not be deterministic. For these reasons, the unittest functionality was added to the hypervisor. Unittests will be small compared to an OS and are used to test only a few features. Unittests

can also be saved, to use in a later stage of the development of the hypervisor to test for regression bugs. V. Thumb-2 support An important improvement that has been made to the hypervisor is the support for conditional execution of instructions in Thumb-2 code. In contrast with ARM instructions, which can (almost) all be executed conditionally by default, Thumb-2 instructions can not because they do not contain a condition code field. However, using the Thumb-2- only IT instruction it is possible to make up to four following instructions conditional. These instructions are called the IT block. The initial implementation of the DBT did not take the IT instructions into account, which can cause SVC instructions, inside an IT block, not to be executed. The hypervisor then loses control over the virtual machine. This problem was solved by taking the ITSTATE field into account when replacing sensitive instructions. This field holds all the information needed to execute instructions conditionally in Thumb-2 code. Now, only sensitive instructions that will actually be executed will be replaced by the improved DBT. Another improvement is the improved support for interworking branches, which are used to swich instruction sets in the code. VI. Memory management The memory management of the hypervisor is mainly the focus of development at The University of Manchester. However, to be able to virtualize Android some changes needed to be made to succesfully boot the Linux-kernel. The changes include the implementation of extra cases when the guest OS adds page table entries and the fixing of bugs causing the hypervisor to crash. These changes are not very substantial but the problems underlying these changes were sometimes very hard to detect. Mainly because of the limited debug opportunities. There were more problems discovered with the memory management, but these could be (temporarily) bypassed. These problems are described in the thesis and were reported to the people working on the memory management system. outdated Linux-kernel with very limited support for the OMAP3530 SoC. In this Master s thesis extra virtual hardware has been added to the VM. But, it was also necessary to add dummy modules and registers because Linux seems to use hardware that is not described in the OMAP manual. When this happened, the behaviour of the real hardware was mimicked in the hypervisor. Mostly, this means that a load retuns zero and a store is ignored. In one particular case, a load had to return another value because Linux expects this behaviour. VIII. Results It is now possible to boot Linux 2.6.37 to the command line interface with the hypervisor. However, it is not possible to input commands because of a problem with global interrupts. The unittest framework is able to boot tests using the hypervisor. IX. Conclusion The work in this Master s thesis improved the hypervisor substantially but, considering the timeframe and the work that had to be done, it was not possible to fully support Android. However, this work can serve as a basis for further development towards supporting Android and other mobile operating systems. With the addition of unittesting framework it is now possible to avoid regression bugs by being able to test the hypervisor more systematic and more directed. This can improve the development speed. References [1] J.E. Smith and R. Nair., Virtual machines: versatile platforms for systems and processes. Morgan Kaufmann, 2005. [2] Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable thirdgeneration architectures. Commun. ACM, 17(7):412421, July 1974 VII. Hardware As mentioned before, the guest OS runs in a virtual machine. This VM consists of virtual copies of the real hardware. The actual virtual hardware was however very limited in the hypervisor. This was due to the hypervisor being developed with an

Inhoudsopgave Voorwoord Toelating tot bruikleen Inhoudsopgave i ii vii 1 Inleiding 1 1.1 Probleemstelling................................ 2 1.2 Doelstelling................................... 3 1.3 Overzicht van de masterproef......................... 4 2 Gerelateerd werk 5 2.1 Virtualisatie................................... 5 2.1.1 Efficiënt virtualiseren.......................... 6 2.1.2 Paravirtualisatie en volledige virtualisatie............... 7 2.1.3 Type 1 en type 2 hypervisors..................... 8 2.2 ARM architectuur............................... 9 2.2.1 De ARM processoren.......................... 9 2.2.2 Uitvoeringstoestand van de processor................. 10 2.2.3 Voorwaardelijke uitvoering....................... 11 2.2.4 Thumb-2 instructieset......................... 12 2.2.5 Geheugenbeheer............................. 15 2.2.6 Het ontwikkelplatform......................... 17 2.3 Android..................................... 19 2.3.1 De architectuur van Android...................... 20 2.3.2 Verschillende versies van Android................... 21 2.4 De hypervisor.................................. 21 2.4.1 Type 1 met volledige virtualisatie................... 22 2.4.2 Dynamische binaire vertaling..................... 22 2.4.3 Gevirtualiseerd geheugenbeheer.................... 24 2.4.4 Gevirtualiseerde hardware....................... 26 2.5 Besluit...................................... 27 vi

3 Unittest functionaliteit 29 3.1 Gastbesturingssysteem............................. 29 3.2 Uitbreidbaarheid................................ 30 4 Thumb-2 ondersteuning 31 4.1 Voorwaardelijke uitvoering........................... 31 4.1.1 Probleem met initiële DBT algoritme................. 31 4.1.2 Aanpassingen DBT algoritme..................... 32 4.2 Overige aanpassingen.............................. 35 4.3 Resultaten.................................... 36 4.4 Besluit...................................... 37 5 Gevirtualiseerd geheugenbeheer 38 5.1 Oplossingsmethoden en debuggen....................... 38 5.2 Aanpassingen.................................. 40 5.2.1 Geheugenadres van de gastpaginatabel................ 40 5.2.2 Probleem met invalideren....................... 42 5.2.3 Overige aanpassingen.......................... 42 5.3 Besluit...................................... 43 6 Gevirtualiseerde hardware 44 6.1 Oplossingsmethoden.............................. 44 6.2 Energiebeheer.................................. 45 6.3 Beveiligingsmechanisme............................ 46 6.4 Onbekende timer................................ 47 6.5 Bijkomende aanpassingen........................... 48 6.6 Besluit...................................... 48 7 Besluit 50 8 Toekomstig werk 51 A Conditiecodes 52 B Unittesten 53 Bibliografie 56 vii

Hoofdstuk 1 Inleiding In de afgelopen jaren zijn mobiele toestellen zoals smartphones en tablets steeds populairder geworden. Deze toestellen combineren doorgaans een groot aantal functies zoals GPS, MP3-speler, camera en uiteraard telefoon, welke vroeger allemaal aparte toestellen waren. Door deze combinatie van functionaliteiten zijn de toestellen intern een samensmelting van verschillende soorten hardware en software, gemaakt door verschillende fabrikanten. Aangezien voor elk van deze functies een eigen processor aanwezig is, zorgt dit voor inefficiëntie verdeling van de werklast over de beschikbare hardware met excessief batterijverbruik als gevolg. Deze inefficiëntie kan verholpen worden door de verschillende functies de hardware te laten delen. Dit is slechts mogelijk als de beschikbare hardware krachtig genoeg is om al deze verschillende functies tegelijk te ondersteunen. Gelukkig zorgt de populariteit van mobiele toestellen ervoor dat de ontwikkeling niet stil staat en bijgevolg zijn de mobiele processoren de afgelopen jaren dan ook steeds krachtiger geworden en kunnen zich soms al meten met processoren in laptops. Het delen van één krachtige processor heeft als gevolg dat de verschillende kleinere processoren achterwege gelaten kunnen worden waardoor de hardwarekost van mobiele toestellen verminderd kan worden. Hardware kan echter niet zomaar gedeeld worden. Ten eerste moet de software van de verschillende fabrikanten van elkaar afgeschermd worden opdat vertrouwelijke informatie in de software niet zomaar beschikbaar zou zijn voor andere software. Ten tweede moet de software enkel in staat zijn de hardware aan te sturen die het nodig heeft om zijn functie uit te voeren. Dit zou anders, door bijvoorbeeld defecte of kwaadwillige software, tot ernstige schade kunnen leiden aan het toestel zoals een batterij die ontploft. Wat uiteraard ook ernstige gevolgen kan hebben voor de gebruiker. Door het gebruik van virtualisatie kan de beschikbare hardware veilig gedeeld worden door verschillende toepassingen. Iedere toepassing wordt dan uitgevoerd in een afgeschermde omgeving met gevirtualiseerde hardware. Een dergelijke omgeving wordt een virtuele machine (VM) genoemd. Dit concept wordt afgebeeld in Figuur 1.1. De virtuele 1

Figuur 1.1: Virtuele machines. hardware kan een volledige kopie van de fysieke hardware zijn of enkel delen daarvan, zie respectievelijk links en rechts op de figuur. Sommige types van virtualisatie laten zelf toe dat de gevirtualiseerde hardware volledig verschillend is van de echte hardware. De software die voor de goede werking van deze virtuele machines zorgt noemt een virtuelemachinemonitor (VMM) of hypervisor. Voor mobiele toestellen is op het vlak van hardware een ARM processor het meest populair [22]. Op het vlak van software is Google Android op het moment van schrijven het meest gebruikte mobiele besturingssysteem voor toestellen gebaseerd op een ARM processor [12]. Android gebruikt als basis de Linux-kernel en is, net als de Linux-kernel, als openbronsoftware vrij beschikbaar op het internet. Voor deze masterproef is Android dus een heel geschikt platform om door de hypervisor te ondersteunen. 1.1 Probleemstelling Op dit moment is er nog geen hypervisor beschikbaar die volledige virtualisatie van de ARM-architectuur aankan en die Android kan virtualiseren. In samenwerking met The University of Manchester is op de Universiteit Gent sinds enkele jaren een dergelijke hypervisor in ontwikkeling. Deze hypervisor heeft echter nog enkele belangrijke beperkingen die het virtualiseren van Android tegenhouden. Om Android te kunnen virtualiseren moeten de eisen van Android grondig onderzocht worden en nagegaan worden waar de hypervisor nog niet aan deze eisen kan voldoen. Aangezien Android gebruik maakt van de Linux-kernel is het belangrijk om te onderzoeken welke versie van de kernel het meest gebruikt wordt. Dit is niet zo eenvoudig omdat Google 2

de kernel niet opgenomen heeft in de broncode van Android en er veel verschillende versies van Android beschikbaar zijn op het internet. De ontwikkeling van de hypervisor gebeurt op een BeagleBoard waarvoor een Android project bestaat [8]. Voor de populairste versie van Android, versie 2.3.7, wordt Linuxkernel versie 2.6.37 gebruikt [20]. Ook andere Android projecten gebruiken voor deze Android versie dezelfde versie van de kernel [3]. Deze kernel heeft heel wat meer hardwareondersteuning voor de ARM architectuur gekregen, in vergelijking met de 2.6.28 kernel die gebruikt werd voor de ontwikkeling van de hypervisor. De hardware die gebruikt wordt door deze kernel, en dus door Android, zal dus gevirtualiseerd moeten worden. Momenteel wordt er door de Linuxgemeenschap gewerkt aan het integreren van de aanpassingen die nodig zijn voor de ondersteuning van Android in recentere versies van de Linux-kernel [24]. Het doel is om meer recente versies te gebruiken in Android-toestellen. Versie 3.3 van de Linux-kernel bevat al een deel van de aanpassingen, en in de huidige ontwikkeling van versie 3.4 zullen nog meer aanpassingen komen [25]. Om dus mee te zijn met de ontwikkeling van Android is het belangrijk om ook recentere versies te ondersteunen. Bovenop de Linux-kernel draait het eigenlijke Android systeem [21]. Een belangrijk onderdeel van Android is de proces-vm waarin alle gebruikersapplicaties draaien. Deze virtuele machine maakt gebruik van de Thumb-2 instructieset van de ARM architectuur. Aangezien de ondersteuning van deze instructieset niet voldoende is, moet hier ook aandacht aan besteed worden. 1.2 Doelstelling Het doel van deze masterproef was om het mobiele besturingssysteem Android te virtualiseren. Om dit te realiseren was echter heel wat werk nodig in verschillende onderdelen van de hypervisor waarvoor in deze masterproef geen tijd genoeg was. Daarom werd er voor gekozen om enkel de ondersteuning van de volgende eisen van Android te verbeteren. Eerst werd de ondersteuning van de Thumb-2 instructieset verbeterd, aangezien deze door Android zeker gebruikt wordt. Daarna werd de ondersteuning voor de bijhorende Linuxkernel verbeterd. Dit bestaat uit twee delen: de uitbreiding van de virtuele hardware en het aanpassen van het gevirtualiseerd geheugenbeheer. Naast deze doelstellingen was het ook de bedoeling om de hypervisor robuuster te maken. Daarom werd er ondersteuning voor unittesten ingebouwd waarmee delen van de 3

hypervisor herhaaldelijk getest kunnen worden. Met deze unittesten is het mogelijk om problemen te isoleren waardoor ze gemakkelijker opgelost kunnen worden. 1.3 Overzicht van de masterproef In hoofdstuk 2 van deze masterproef wordt het gerelateerd werk besproken. Hierin wordt eerst algemeen uitgelegd wat virtualisatie inhoudt en hoe dit van toepassing is op deze masterproef. Daarna wordt de staat en werking van de hypervisor waarmee de ontwikkeling is begonnen besproken samen met de problemen die het virtualiseren van Android in de weg staan. Het volgende hoofdstuk bespreekt de unittest functionaliteit die toegevoegd werd aan de hypervisor. Hoofdstuk 4 beschrijft de problemen omtrent de ondersteuning van de Thumb-2 instructieset, en hoe deze werden opgelost. Verder wordt in hoofdstuk 5 de aandacht gevestigd op het gevirtualiseerd geheugenbeheer. Ten slotte wordt in hoofdstuk 6 uitgelegd hoe de ondersteuning van specifieke hardware is verbeterd. 4

Hoofdstuk 2 Gerelateerd werk In dit hoofdstuk zal eerst informatie gegeven worden over virtualisatie: waarom wordt aan virtualisatie gedaan en wat zijn de vereisten van een architectuur om dit efficiënt te realiseren? Daarna worden de verschillende types virtualisatie toegelicht en de wat gebruikelijke technieken zijn. Hierbij zal ook verantwoord worden waarom er gekozen werd voor een bepaald type virtualisatie. Nadien zal de ARM architectuur in meer detail uitgelegd worden en de invloed hiervan op het ontwerp van de hypervisor. Ook worden kort de gebruikte hardware en de ontwikkelmethoden besproken. Daarna wordt de architectuur van Android behandeld en de verschillende versies die ervan beschikbaar zijn. Als laatste wordt de staat van de hypervisor bij aanvang van deze masterproef besproken. Daarbij wordt aandacht geschonken aan de werking van verschillende onderdelen en de openstaande problemen. 2.1 Virtualisatie Het virtualiseren van hardware wordt om verschillende redenen toegepast [33]. In de context van mobiele systemen zijn de energie-efficiëntie en het plaatsgebruik van hardware de belangrijkste redenen om voor virtualisatie te kiezen. Door middel van virtualisatie is het immers mogelijk om hardware te delen waardoor er minder hardware nodig is om aan de eisen van eenzelfde aantal softwarecomponenten te voldoen. Dit heeft dan weer een positieve invloed op het energieverbruik. Er zijn echter ook nadelen verbonden aan het delen van hardware. Softwarecomponenten die zich niet gedragen volgens de regels, al dan niet opzettelijk, zijn schadelijker wanneer de hardware gedeeld wordt. Een voorbeeld hiervan is het volledig opeisen van de hardware door één softwarecomponent waardoor deze niet meer kan gebruikt worden door andere softwarecomponenten. Wanneer softwarecomponenten niet goed van elkaar afgeschermd zijn kan bovendien vertrouwelijke informatie lekken naar alle softwarecomponenten die van dezelfde hardware gebruik maken. Deze nadelen kunnen echter vermeden worden door een goed ontwerp van de virtualisatiesoft- 5

ware. Om de softwarecomponenten van elkaar te isoleren maakt de virtualisatiesoftware voor iedere softwarecomponent een eigen virtuele machine (VM) aan. In deze masterproef is de softwarecomponent meestal een besturingssysteem, daarom wordt verder in deze masterproef de term (gast)besturingssysteem gebruikt in plaats van softwarecomponent. Een VM is een voorstelling van de hardware zoals het gastbesturingssyteem die zou zien mocht die rechtstreeks op de fysieke hardware draaien. De virtualisatiesofware is verantwoordelijk voor de goede werking van deze VMs en wordt ook een virtuele machinemonitor (VMM) genoemd, of een hypervisor. Er zijn twee grote categorieën: systeem-vms en proces-vms. Zoals de naam aangeeft kan binnenin een proces-vm één enkel proces uitvoeren. Voorbeelden van proces-vms zijn de Java VM en de Dalvik VM gebruikt door Android [29, 21]. Systeem-VMs virtualiseren een volledig hardwareplatform en ondersteunen dus de uitvoering van een volledig besturingssyteem. Voorbeelden van hypervisors die gebruik maken van dit type VMs zijn VirtualBox en Xen Hypervisor [7, 11]. De hypervisor die het onderwerp is van deze masterproef wordt ontwikkeld voor mobiele toestellen en moet ondersteuning bieden voor volledige (mobiele) besturingssystemen. Deze hypervisor hoort dus bij de categorie van systeem-vms. 2.1.1 Efficiënt virtualiseren Voor het implementeren van een hypervisor is het interessant om te kijken hoe dit best aangepakt wordt. Een paper van Popek en Goldberg beschrijft hypervisors theoretisch. Volgens de paper moet een volwaardige hypervisor voldoen aan drie eigenschappen: controle over de hardware, gelijkheid en efficiëntie [30]. Het is vanzelfsprekend dat de hypervisor de volledige controle over de hardware moet hebben zodat de gastbesturingssystemen niet zomaar de configuraties van de gedeelde hardware, zoals het geheugen en de processor, kunnen lezen of aanpassen. Gelijkheid wijst er op dat besturingssystemen binnenin een VM hetzelfde gedrag vertonen alsof ze rechtstreeks op de fysieke hardware zouden uitvoeren, met uitzondering van een verschil in snelheid. Dit verschil zal door het gebruik van virtualisatie altijd aanwezig zijn aangezien de hypervisor moet ingrijpen om te voldoen aan de vorige eigenschap. Om de laatste eigenschap uit te leggen moet eerst het verschil tussen verschillende types instructies behandeld worden: enerzijds tussen bevoorrechte en onbevoorrechte instructies en anderzijds tussen gevoelige en ongevoelige instructies. 6

Een bevoorrechte instructie zal een exceptie opwerpen wanneer deze uitgevoerd wordt in een onbevoorrechte modus. Onbevoorrechte instructies zijn instructies die hetzelfde gedrag vertonen in alle uitvoeringsmodi. Gevoelige instructies worden opgedeeld in twee types: controle- en gedragsgevoelige instructies. Controlegevoelige instructies zijn instructies die het fysieke geheugen of de uitvoeringsmodus van de processor proberen aanpassen en die de controle-eigenschap kunnen schenden. Gedragsgevoelige instructie zijn instructies waarvan het gedrag afhangt van de plaats in het fysiek geheugen of van de uitvoeringsmodus van de processor. Een instructie die noch controle- of gedragsgevoelig is, wordt een ongevoelige instructie genoemd. Met deze definities kan de laatste eigenschap als volgt uitgelegd worden: efficiëntie vereist dat alle ongevoelige instructies rechtstreeks op de hardware uitgevoerd moeten worden, en dat dus enkel gevoelige instructies geëmuleerd worden door de hypervisor. Enkel wanneer alle gevoelige instructies ook bevoorrechte instructies zijn kan een hypervisor, volgens de theorie van Popek en Goldberg, efficiënt geïmplementeerd worden [30]. Dit is echter niet het geval voor de ARM architectuur waar bijvoorbeeld de CPS instructie, die de processor modus wil veranderen, als NOP wordt behandeld in de onbevoorrechte modus [14]. Dit is dus een gevoelige instructie, maar ze is niet bevoorrecht omdat ze geen exceptie opwerpt. In de praktijk is het echter wel mogelijk om een efficiënte hypervisor te ontwikkelen door gebruik te maken van technieken zoals dynamische binaire vertaling of met een andere architectuur die hardwareondersteuning voor virtualisatie heeft. 2.1.2 Paravirtualisatie en volledige virtualisatie De beschikbare technieken voor het realiseren van systeemvirtualisatie kunnen ingedeeld worden in paravirtualisatie en volledige virtualisatie. Bij volledige virtualisatie wordt de fysieke hardware volledig geëmuleerd en zal het bovenliggende besturingssysteem er zich niet van bewust zijn dat het te maken heeft met virtualisatie. Een besturingssysteem dat zonder problemen op de fysieke hardware kan uitvoeren zal dus zonder aanpassingen op de hypervisor kunnen uitvoeren. De hypervisor moet in dit geval wel alle gevoelige instructies onderscheppen en emuleren. Volledige virtualisatie zorgt voor een grote virtualisatiekost maar heeft als voordeel dat de besturingssystemen niet aangepast moeten worden. Deze virtualisatiekost kan vermeden worden wanneer er hardwareondersteuning voor virtualisatie is. Deze hardwareondersteuning is momenteel nog niet beschikbaar voor de ARM architectuur. 7

(a) Type 1 of bare-metal: hypervisor draait rechtstreeks op de hardware. (b) Type 2 of hosted: hypervisor draait bovenop een besturingssysteem. Figuur 2.1: Type 1 en type 2 hypervisors. Bij paravirtualisatie wordt het gastbesturingssysteem gedeeltelijk aangepast zodat het een interface herkent die aangeboden wordt die de moeilijk virtualiseerbare eigenschappen van de architectuur omzeilt [35]. Op die manier wordt de virtualisatiekost zo veel mogelijk gereduceerd. Dit zorgt echter wel voor grote onderhoudsproblemen. Voor ieder mogelijke combinatie van besturingssysteem en hypervisor moeten deze aanpassingen immers gemaakt worden. Zowel bij een update van het besturingssysteem als bij de hypervisor is het dus mogelijk dat de aanpassingen opnieuw doorgevoerd moeten worden. Voor de hypervisor die gebruikt wordt in deze masterproef werd voor volledige virtualisatie gekozen aangezien er geen aanpassingen aan de gastbesturingssystemen nodig zijn. Er kan dus met verschillende gastbesturingssystemen gewerkt worden. 2.1.3 Type 1 en type 2 hypervisors Hypervisors kunnen ook ingedeeld worden op basis van de plaats die ze innemen in de hardware/software-stapel. Wanneer de hypervisor rechtstreeks uitvoert op de hardware spreken we van een type 1 of bare-metal hypervisor. Het is ook mogelijk dat de hypervisor een gebruikersprogramma is dat zelf een besturingssysteem nodig heeft om uit te voeren. Deze hypervisors zijn type 2 of hosted hypervisors. In Figuur 2.1 worden deze twee types voorgesteld. Een type 1 hypervisor draait rechtstreeks op de hardware en dus zal het ontwerp ervan op enkele punten gelijkaardig zijn aan dat van een traditioneel besturingssysteem. Zo moeten er drivers voor de hardware zijn en moet de hardware geïnitialiseerd worden. 8

Een type 2 hypervisor steunt voor de aansturing van de hardware op de drivers van het besturingssysteem. Aangezien er geen drivers ontwikkeld en ingebouwd moeten worden voor een type 2 hypervisor kan de ontwikkeling ervan een stuk sneller verlopen en is het gemakkelijker om te debuggen. Een traditioneel besturingssysteem zal echter naast de hypervisor nog andere processen uitvoeren die ook de nodige verwerkingstijd zullen innemen. Alle instructies van een gastbesturingssysteem moeten bovendien nog door een extra laag software. De prestaties van een type 2 hypervisor zullen dus steeds lager zijn dan de prestaties van een type 1 hypervisor [32]. Daarom werd voor de hypervisor van dit werk gekozen voor een type 1 implementatie. Voorbeelden van type 1 en type 2 hypervisors zijn respectievelijk Xen en VirtualBox [7, 11]. 2.2 ARM architectuur De ARM processor is met meer dan 90% marktaandeel de populairste processor voor mobiele toestellen [17, 22]. Daarom werd er gekozen om met de hypervisor de ARM architectuur te virtualiseren en is het dus belangrijk om deze in meer detail te bespreken. In wat volgt zullen de aspecten van de ARM architectuur, die voor deze masterproef interessant zijn, besproken worden. Eerst wordt algemeen informatie gegeven over de verschillende ARM processoren en de verschillende modi waarin een processor kan uitvoeren. Daarna komt de voorwaardelijke uitvoering van instructies aan bod. Daarna wordt uitleg gegeven over de verschillende instructiesets van de architectuur: ARM, Thumb en Thumb-2. Ten slotte zal wordt het geheugenbeheer besproken. 2.2.1 De ARM processoren ARM processoren zijn beschikbaar in verschillende types: van processoren voor smartcards tot processoren voor krachtige mobiele toestellen zoals smartphones en tablets. De processoren worden ingedeeld in drie profielen: Cortex-A, Cortex-R en Cortex-M [2]. De processoren voor ingebedde systemen maken deel uit van het Cortex-M en Cortex-R profiel. Het Cortex-R profiel bevat de processoren voor real-time toepassingen, waar een goede afweging wordt gemaakt tussen laag energieverbruik en hoge prestaties. Processoren voor microcontrollers, waar er vooral gefocust wordt op laag energieverbruik, komen terecht in het Cortex-M profiel. Het Cortex-A profiel bevat de toepassingsprocessoren die 9

Figuur 2.2: Schema van het PSR. Figuur 2.3: Schema van het APSR. hoge prestaties leveren en zijn bedoeld voor gebruik in mobiele toestellen zoals smartphones en tablets. Iedere processor implementeert een bepaalde variant van de ARM architectuur. Processoren uit het Cortex-A profiel ondersteunen de ARMv7-A architectuur, die in dit werk gevirtualiseerd wordt. De ARMv7-A architectuur wordt verder in dit werk de ARM architectuur genoemd. Deze architectuur implementeert de ARM en Thumb-2 instructiesets en biedt ondersteuning voor geheugenbeheer met geheugenbescherming en adresvertaling die gebruik maakt van paginatabellen. Deze eigenschappen worden verder in meer detail besproken. 2.2.2 Uitvoeringstoestand van de processor De uitvoeringstoestand van de processor wordt bijgehouden in het Current Program Status Register (CPSR). Figuur 2.2 toont dit register met aanduiding van de verschillende velden. De grijze bits zijn gereserveerd en geven bij het uitlezen altijd de waarde nul terug. Dit zijn de belangrijkste velden van het CPSR die verder in meer detail behandeld zullen worden: N, Z, C, V: dit zijn conditiecode vlaggen en worden gewijzigd na het uitvoeren van instructies die de vlaggen willen wijzigen. De verschillende vlaggen zijn: N: Negatieve conditiecode vlag, Z: Nul conditiecode vlag, C: Carry conditiecode vlag, V: Overflow conditiecode vlag. IT 7:2, IT 1:0: Deze velden vormen samen het ITSTATE veld dat de uitvoeringstoestand bijhoudt voor een IT instructie. Deze velden zijn enkel zinvol als de 10

processor zich in Thumb-2 modus bevindt. T: Bepaalt, samen met de J bit, de instructieset modus van de processor. De J bit wordt niet gebruikt in deze masterproef en staat altijd op 0. Als de T bit op 1 staat is de instructieset Thumb-2 anders is deze ARM. M: Bepaalt de uitvoeringsmodus van de processor. De enige onbevoorrechte modus is de user modus en wordt gecodeerd als 0b10000. Alle andere, geldige, modi zijn wel bevoorrecht. De ARM architectuur beschikt over zeven verschillende uitvoeringsmodi waarin de processor zich kan bevinden. De user modus (USR) is de enige onbevoorrechte modus van de architectuur. De bevoorrechte modi zijn: system (SYS), supervisor (SVC), abort (ABT), undefined (UND), interrupt (IRQ) en fast interrupt (FIQ). Het CPSR kan enkel uitgelezen of aangepast worden in een bevoorrechte modus. Een deel van dit register is ook beschikbaar in de gebruikersmode en wordt het Application Program Status Register (APSR) genoemd. Dit is geen apart register maar een gemaskeerde versie van het CPSR, zie Figuur 2.3. Voor iedere uitvoeringsmodus, met uizondering van de gebruikersmodus, is er een Saved Program Status Register (SPSR), dat hetzelfde formaat heeft als het CPSR en de waarde van het CPSR register bijhoudt wanneer van de gebruikersmodus naar een bevoorrechte modus veranderd wordt. Wanneer er dan terug gewisseld wordt naar de gebruikersmodus wordt het SPSR teruggeschreven naar het CPSR. De hypervisor zal altijd uitvoeren in een van de bevoorrechte modi. Het gastbesturingssysteem zal enkel uitvoeren in de gebruikersmodus. Dit is nodig opdat de hypervisor de controle over de hardware zou kunnen behouden. 2.2.3 Voorwaardelijke uitvoering Een belangrijk kenmerk van de ARM architectuur is de voorwaardelijke uitvoering van het grootste deel van de instructies. Dit kenmerk wordt ook wel de geprediceerde uitvoering van instructies genoemd. Aangezien bijna alle instructies voorwaardelijk uitgevoerd kunnen worden, zijn er minder voorwaardelijke spronginstructies nodig. Daarom wordt de code een stuk compacter wat voordelig is voor het cachegebruik [26]. Bekijk als voorbeeld de pseudocode uit Figuur 2.4(a). In dit voorbeeld wordt R2 bij R1 opgeteld als R1 nul is, anders wordt R3 opgeteld bij R1. Na compilatie wordt de code 11

if (R1 == 0) R1 = R1 + R2; else R1 = R1 + R3; (a) Pseudocode CMP R1, #0 BNE L1 ADD R1, R1, R2 B L2 L1 ADD R1, R1, R3 L2... (b) Zonder predicaten CMP R1, #0 ADDEQ R1, R1, R2 ADDNE R1, R1, R3 (c) Met predicaten Figuur 2.4: Voorwaardelijke uitvoering van ARM code. uit Figuur 2.4(b) genereerd als enkel de spronginstructies geprediceerd zijn. Wanneer alle instructies geprediceerd zijn, wordt de code uit Figuur 2.4(c) gegenereerd. Zonder geprediceerde instructies neemt dit stukje code vijf ARM instructies in, er zijn immers twee spronginstructies nodig om over één van de twee ADD instructies te springen. Met geprediceerde instructies zijn geen spronginstructies nodig om dezelfde functionaliteit te verkrijgen. In dit voorbeeld zorgt het gebruik van geprediceerde instructies dus voor 40% minder instructies. De eerste vier bits van een geprediceerde ARM instructie bepalen de conditiecode. De conditiecode wordt vergeleken met de conditievlaggen uit het CPSR register, zie Sectie 2.2.2 voor het formaat van dit register. De conditiecode op zich bestaat uit twee delen: de eerste drie bits vormen de basisconditie, de laatste bit geeft aan of deze basisconditie tegengesteld moet worden. Bijvoorbeeld, de conditiecode EQ (equal), gecodeerd als 0b0000, geeft aan dat de Z (zero) vlag op 1 moet staan. De conditiecode NE (not equal) 0b0001 geeft aan dat de vlag op 0 moet staan. EQ is het omgekeerde van NE. Voor sommige instructies zijn de eerste vier bits gelijk aan 0b1111. Deze instructies kunnen niet voorwaardelijk gemaakt worden en zullen dus altijd onvoorwaardelijk uitgevoerd worden [14]. In bijlage A worden de verschillende conditiecodes samen met hun codering en betekenis opgesomd. 2.2.4 Thumb-2 instructieset De ARM instructieset bestaat uitsluitend uit 32-bit instructies [14]. Ingebedde systemen beschikken echter niet over veel cachegeheugen en moeten energiezuinig zijn: om deze reden werd de 16-bit Thumb instructieset geïntroduceerd. Thumb code zal in het algemeen kleiner zijn dan ARM code waardoor er minder instructies opgehaald moeten worden en de cache minder energie zal verbruiken [23]. 12

De Thumb instructieset is een deelverzameling van de ARM instructieset en bestaat uitsluitend uit 16-bit instructies. Om de codering van instructies compacter te maken werd de conditiecode weggelaten en kunnen enkel registers R0 tot en met R7 gebruikt worden. Door de halvering van het aantal bits is de expressiviteit van Thumb-instructies wel verminderd. In vergelijking met ARM code zullen hierdoor meer instructies nodig zijn om dezelfde functionaliteit te verkrijgen, maar door de kleinere instructies zal de code gemiddeld 30% compacter zijn [18]. Om optimale gecompileerde code te verkrijgen wordt code, waar de prestatie kritisch is, gecompileerd naar ARM en code, waar compactheid belangrijker is, gecompileerd naar Thumb [18, 23]. Deze menging van Thumb en ARM code kan gebeuren met heel grove granulariteit (per softwaremodule) tot heel fijne granulariteit (binnenin een functie). Om de geschikte menging te bepalen zijn echter extra hulpmiddelen zoals een profiler nodig die werkt op basis van heuristieken [31, 23]. Ook zijn er nog andere nadelen zoals het beperkt aantal instructies en het weglaten van de voorwaardelijke uitvoering. Daarom werd de Thumb-2 instructieset geïntroduceerd. Thumb-2 bestaat uit zowel 16- als 32-bit instructies die gemakkelijk door elkaar gebruikt kunnen worden zonder de processormodus te veranderen [31]. Dit reduceert ook de extra instructies die nodig zijn om de instructieset te wijzigen. Ook Thumb-2 instructies bevatten geen conditiecode maar kunnen wel voorwaardelijk uitgevoerd worden met behulp van een nieuwe instructie, de IT of If-Then instructie. De IT instructie bepaalt een IT-blok die één tot vier instructies bevat die voorwaardelijk uitgevoerd zullen worden. De syntax voor deze instructie is als volgt: ITxyz conditiecode. De operand van de IT instructie bepaalt de conditiecode voor de eerste instructie in het IT blok. De conditiecodes van de volgende instructies worden bepaald door de waarde van de condities x, y en z, voor respectievelijk de eerste, tweede en derde instructie. Deze condities zijn optioneel en kunnen ofwel T ofwel E zijn. Wanneer de conditie T is wordt dezelfde conditiecode gebruikt als die van de eerste instructie, als de conditie E is wordt de tegengestelde conditiecode gebruikt. In Figuur 2.5 wordt de Thumb-2 code gegeven voor het voorbeeld van Figuur 2.4(a). Het IT blok bevat twee instructies waarbij de conditiecode EQ is en de conditie voor de ander instructie E is. Het enige verschil tussen de ARM en Thumb-2 code is de IT instructie die de conditiecodes voor de volgende twee instructies bepaalt. Na het uitvoeren van de IT instructie worden de ITSTATE velden van het CPSR register ingesteld. De eerste drie bits van ITSTATE zijn de basisconditie voor het ITblok, de laatste vijf bits bepalen de grootte van het IT-blok en de minst significante bit 13

CMP R1, #0 ITE EQ ADD R1, R1, R2 ADD R1, R1, R3 Figuur 2.5: Voorwaardelijke uitvoering van Thumb-2 code. Tabel 2.1: Opeenvolgende toestanden van ITSTATE. ITSTATE: [7:5] [4] [3] [2] [1] [0] Toestand basisconditie b1 b2 b3 b4 1 IT-blok met 4 instructies basisconditie b1 b2 b3 1 0 IT-blok met 3 instructies basisconditie b1 b2 1 0 0 IT-blok met 2 instructies basisconditie b1 1 0 0 0 IT-blok met 1 instructie 0 0 0 0 0 0 0 0 Geen IT-blok van de conditiecode voor iedere instructie uit het IT-blok. De grootte van het IT-blok wordt bepaald door de positie van de minst significante 1 bit. Met de ITSTATE heeft de processor dus genoeg informatie om de instructies in het IT-blok voorwaardelijk uit te voeren. Na het uitvoeren van een voorwaardelijke instructie worden de vijf laatste bits verschoven naar links. Als na het uitvoeren van een voorwaardelijke instructie de laatste drie bits van ITSTATE nul zijn, wordt ITSTATE gereset op nul en wordt uit het IT-blok gegaan. In Tabel 2.1 worden de opeenvolgende toestanden gegeven waarbij b1 staat voor de minst significante bit van de conditiecode van de eerst volgende instructie, b2 voor de tweede, enzovoort. De conditiecode voor de eerste instructie is dan de samenvoeging van basisconditie en b1, voor de tweede instructie de samenvoeging van basisconditie en b2, enzovoort. Thumb-2 reduceert de grootte van de code met gemiddeld 20% en behoudt tot 98% van de prestaties in vergelijking met ARM code [31]. Dit is een heel stuk beter dan de resultaten van Thumb. Andere voordelen van de Thumb-2 instructieset tegenover de Thumb instructieset zijn dat de Thumb-2 instructieset bijna alle instructies uit de ARM instructieset bevat en er niet gewisseld moet worden van processormode om 16- en 32-bit instructies door elkaar te gebruiken [14]. Het is mogelijk om tijdens de uitvoering de instructieset te wijzigen door het gebruik van een speciale spronginstructie: de interworking branch. Een interworking branch kan voorkomen bij spronginstructies maar ook bij POP, LDR en LDM instructies, deze laden één of meerdere registers in van het geheugen waaronder eventueel de programmateller waardoor ook een sprong kan gebeuren. Bij een interworking branch bepalen de laatste 14

twee bits van het doeladres de instructieset. Als deze bits 0b00 zijn wordt gesprongen naar ARM code. Als de minst significante bit 1 is wordt gesprongen naar Thumb-2 code en moet deze bit op 0 gezet worden om een juiste uitlijning te verkrijgen. Als de bits 0b10 zijn, is het sprongadres verkeerd uitgelijnd en is dus ongeldig. Als dit voorkomt zal een exceptie opgeworpen worden. De ondersteuning voor de Thumb-2 instructieset werd geïmplementeerd ter ondersteuning van FreeRTOS. FreeRTOS is een klein real-time besturingssysteem [9]. In tegenstelling tot Linux ondersteunt het zowel de ARM instructieset als de Thumb-2 instructieset en kan dus gebruikt worden om de Thumb-2 ondersteuning te testen. 2.2.5 Geheugenbeheer Virtueel geheugen is een belangrijk aspect van geavanceerde besturingssystemen omdat dit de mogelijkheid biedt om meerdere processen op transparante wijze gebruik te laten maken van het fysiek geheugen. De geheugenadressen, gebruikt in de software, worden dan logische of virtuele adressen genoemd. De virtuele adressen worden door het gebruikte geheugenbeheersysteem vertaald naar fysieke adressen. Deze vertaling gebeurt in de Memory Management Unit (MMU). Enkel wanneer de MMU aangeschakeld is, worden virtuele geheugenadressen vertaald naar fysieke geheugenadressen. Wanneer de MMU uitgeschakeld is, zijn de virtuele adressen gelijk aan de fysieke adressen. De structuur en werking van het geheugenbeheer van ARM is belangrijk voor de ontwikkeling van de hypervisor omdat dit ook gevirtualiseerd moet worden. Verschillende gastbesturingssystemen mogen immers niet in staat zijn elkaars toegewezen geheugen zomaar te lezen of aan te passen. Het geheugenbeheer van de ARMv7-A architectuur heet Virtual Memory System Achitecture (VMSAv7) en maakt gebruik van een 2-niveau vertalingsschema. Het fysiek geheugen wordt ingedeeld in vier paginagroottes: supersectie, sectie, grote pagina en kleine pagina. Deze hebben respectievelijk een grootte van 16 MB, 1 MB, 64 KB en 4 KB. In de paginatabel kunnen verschillende types verwijzingen voorkomen die wijzen naar een pagina of een paginatabel op het tweede niveau. De paginatabel op het eerste niveau bevat verwijzingen naar secties, supersecties en paginatabellen op het tweede niveau. Op het tweede niveau wordt verwezen naar kleine en grote pagina s. Op beide niveaus kunnen ook lege plaatsen voorkomen. Het type van een verwijzing wordt bepaald door de laatste twee bits van de verwijzing. Voor een paginatabel op het eerste niveau zijn de mogelijke 15

waarden: 0b01 voor een verwijzing naar een paginatabel op het tweede niveau en 0b10 voor een sectie of supersectie. Het verschil tussen een sectie of supersectie wordt bepaald door een andere bit in de verwijzing. Voor een paginatabel op het eerste niveau zijn de mogelijke waarden: 0b01 voor een grote pagina en 0b1x voor een kleine pagina, waarbij x zowel 1 als 0 kan zijn. Op beide niveaus is een verwijzing waarbij de laatste twee bits 0b00 zijn een lege verwijzing, dit wordt gezien als een ongeldige verwijzing. Alle geldige verwijzingen bevatten het basisadres van de pagina, of paginatabel waar ze naar verwijzen. Naast dit basisadres en de bits die het type bepalen worden nog andere bits bijgehouden die onder andere belangrijk zijn voor de toegangsbeperking. Deze bits kunnen bijvoorbeeld aanduiden dat een sectie in de onbevoorrechte modus enkel gelezen mag worden maar niet mag worden aangepast. In Figuur 2.6 wordt een deel van het fysiek geheugen voorgesteld met een sectie en enkele grote pagina s. Om de figuur leesbaar te houden werd het fysiek geheugen voorgesteld in blokken van 64 KB, de grootte van een grote pagina. De pijlen wijzen naar het eerste adres van de pagina of paginatabel. Dit is dus het basisadres. Een vertaling van een virtueel adres naar een fysiek adres gebeurt op de volgende manier. In een speciaal register, het Translation Table Base Register (TTBR), wordt de locatie van de paginatabel op het eerste niveau opgeslagen. Een deel van het virtueel adres wordt gebruikt als index in deze tabel. Als op die plaats in de tabel een verwijzing naar een sectie of supersectie zit, wordt het virtueel adres vertaald door het basisadres van de (super)sectie en de paginaindex uit het virtueel adres samen te voegen. Anders wordt de paginatabel op het tweede niveau opgehaald waar naar verwezen wordt. In deze paginatabel wordt opnieuw een deel van het virtueel adres als index gebruikt, deze keer voor de tabel op het tweede niveau. De vertaling van het virtueel adres gebeurt dan via een kleine of grote pagina. In Figuur 2.7 wordt een virtueel adres (VA) vertaald naar een fysiek adres (FA) wanneer dit fysiek adres zich in een kleine pagina bevindt. In de figuur staat N1 voor het eerste niveau en N2 voor het tweede niveau. Bij het vertalen van een virtueel adres kunnen er verschillende fouten optreden. Wanneer een adres verwijst naar een lege plaats zal er een vertaalfout opgeworpen worden. Iedere verwijzing in de paginatabel heeft toegangsbits die worden nagekeken wanneer een virtueel adres gebruikt wordt. Wanneer een bepaalde lees- of schrijfopdracht niet geoorloofd is, zal er een permissiefout opgeworpen worden. Beide fouten worden algemeen een datafout genoemd. Als een datafout optreedt, wordt het virtueel geheugenadres en het 16

Figuur 2.6: Paginatabellen op het eerste en tweede niveau. fouttype bijgehouden. proberen afhandelen. Met deze twee gegevens moet het besturingssysteem de fouten 2.2.6 Het ontwikkelplatform De huidige ontwikkeling van de hypervisor gebeurt op een BeagleBoard [15]. Dit bord is gemaakt met het oog op de ontwikkeling van openbronsoftware op openbronhardware. Openbronhardware wil zeggen dat alle documentatie over de hardware en het ontwerp ervan vrij beschikbaar is. Voor deze masterproef zijn belangrijkste onderdelen van het BeagleBoard de Texas Instruments (TI) OMAP3530 System-on-Chip (SoC), de JTAG en UART voor het debuggen en communiceren over de seriële poort naar de computer en de SD/MMC geheugenkaartlezer. Een SoC combineert al de nodige hardwarecomponenten voor een bepaald systeem op één chip. De OMAP is gericht op het gebruik in mobiele ingebedde systemen zoals smartphones [34]. De OMAP kan opgedeeld worden in verschillende subsystemen. Het Microprocessor Unit (MPU) subsysteem bevat de ARM rekenkern met onder andere een ARM Cortex-A8 17