OS Awareness
Simics OS awareness is een Simics module die de datastructuren en abstracties begrijpt van het besturingssysteem dat op het Simics doelsysteem draait. Met OS awareness weten Simics en de Simics debugger over kernelruimte, gebruikersruimte, processen, threads en taken.
Fundamenteel voert OS awareness twee taken uit: live volgen van gebeurtenissen terwijl ze gebeuren, en het onderzoeken van de momentane toestand van het besturingssysteem. Het live volgen van gebeurtenissen betekent dat OS-bewustzijn detecteert wanneer het besturingssysteem een taakomschakeling uitvoert, wanneer software een systeemaanroep doet, of wanneer interrupts plaatsvinden. De meest gebruikelijke manier om dergelijke gebeurtenissen te detecteren is te wachten op interrupts in het doelsysteem – zolang er geen interrupts plaatsvinden, draait dezelfde software op gebruikersniveau. Wanneer een interrupt optreedt, neemt het besturingssysteem het over en wordt het lopende proces geacht te zijn uitgeschakeld. Als het besturingssysteem terugkeert naar de gebruikersruimte, wordt een ander proces geacht te zijn ingeschakeld.
Live tracking bepaalt wanneer er iets gebeurt, maar om te bepalen wat er is gebeurd moet de actuele toestand van het besturingssysteem worden onderzocht. Bijvoorbeeld, wanneer een interrupt triggert, wat zijn de actieve threads op de processor die de interrupt heeft ontvangen? Om dat te bepalen moet OS awareness de structuur kennen van de OS wachtrijen van lopende en wachtende processen, de inhoud van de taakstructuren of procesbesturingsblokken, en andere datastructuren. Als dit correct is geconfigureerd, kan OS awareness vervolgens de lijsten in het doelgeheugen doorlopen en de naam bepalen van het momenteel actieve proces op een bepaalde processor, alle bestaande processen, dynamisch geladen softwaremodules en hun relocatie-adressen, en alles wat verder van belang is.
Omdat de precieze inhoud van taakstructuren en de offsets van bepaalde velden kunnen verschillen tussen builds en versies van het besturingssysteem, moet OS awareness worden geconfigureerd voordat het kan worden gebruikt. Meestal is het mogelijk om de parameters voor OS awareness te bepalen door te kijken naar een symbolentabel of kernelbestand met debug informatie van de OS build. Er zijn echter besturingssystemen waarbij de exacte parameters niet kunnen worden bepaald tot runtime, en in dergelijke gevallen zal de configuratie moeten wachten tot het doelsysteem is opgestart. In ieder geval kan de set parameters, wanneer die eenmaal is bepaald, worden opgeslagen en gebruikt de volgende keer dat dezelfde doel-setup wordt gedraaid.
Het gebruik van parameter-bestanden maakt het mogelijk om OS awareness configuraties te laten distribueren samen met de OS-images waarnaar zij verwijzen. Dit betekent dat een platformteam een OS-image kan bouwen, OS awareness ervoor kan configureren, de parameters kan opslaan, en zijn gebruikers kan voorzien van het OS en de OS awareness parameters zonder symboolbestanden of debug-informatie te hoeven verstrekken. Het OS awareness parameters bestand is gewoon onderdeel van de meegeleverde software stack, en het wordt geactiveerd in de opstartscripts die gebruikt worden om Simics op te starten. De gebruikers van het systeem hoeven niet te weten hoe ze OS awareness moeten configureren – ze krijgen het gewoon aan de praat zodra ze de meegeleverde doelsysteem setups opstarten. OS awareness parameters worden ook opgeslagen in Simics checkpoint bestanden, zodat OS awareness blijft werken tijdens het opslaan en terugzetten van checkpoints.
OS awareness maakt het mogelijk om Simics functies alleen te laten werken op een bepaalde subset van de software stack, zoals breakpoints alleen laten zetten binnen een bepaald proces, of alleen geheugentoegang traceren die wordt uitgevoerd door de kernel en niet door taken op gebruikersniveau. Een door de gebruiker geschreven Simics uitbreiding of script kan luisteren naar de gebeurtenissen van OS awareness en acties ondernemen gebaseerd op welke software op dat moment draait in het doelsysteem. Het is mogelijk om het OS awareness systeem alleen om meldingen voor een bepaald proces te vragen, of om alle acties voor alle processen te zien.
Het OS awareness systeem in Simics werkt met het concept van een knooppuntenboom. Elk knooppunt in de boom vertegenwoordigt een abstractie niveau in het OS proces model. Typisch, is de hoogste knoop het besturingssysteem zelf, die dan in kernel en gebruikersniveau taken wordt gesplitst. In een besturingssysteem als Linux bevat elke taak op gebruikersniveau een of meer threads. In de kernel maakt het OS normaliter onderscheid tussen kernel threads en de idle task, omdat dat de doeluitvoeringstijd helpt verklaren. Figuur 3.3 toont een voorbeeld van een node tree van een kaal Linux-systeem.
Figuur 3.3. OS awareness tree.
In de Simics CLI en debugger GUI worden proces-query’s gebruikt om interessante processen te vinden. Deze zoekopdrachten kunnen overeenkomen met procesnamen, proces ID nummers, of andere eigenschappen die beschikbaar zijn gesteld door OS awareness. In de meeste gevallen is de naam van een proces voldoende om het te identificeren, maar in complexe systemen zijn meer complexe overeenkomsten nodig zoals “het proces genaamd foo op het bord genaamd bar.” In een langlopend systeem waar een bepaald programma vele malen wordt uitgevoerd, kan de proces-ID worden gebruikt om een bepaalde start van een proces te identificeren.
Simics OS awareness ondersteunt geneste besturingssystemen om OS awareness voor hypervisor-gebaseerde systemen af te handelen. In een systeem met een hypervisor is het noodzakelijk om de planning van gast-besturingssystemen op de doelprocessorkernen bij te houden. Zodra het actieve besturingssysteem op een kern is bepaald, is het mogelijk om vervolgens OS-awareness voor dat besturingssysteem toe te passen om het actieve proces of de actieve thread te bepalen. Er wordt dus een enkele boom gebruikt voor het hele systeem, met de hypervisor als root.
De details van wat OS awareness kan volgen en ontdekken over de doelsoftwarestack varieert afhankelijk van het gast-besturingssysteem en hoeveel werk er is besteed aan het bouwen van OS awareness daarvoor.
Vergeleken met de OS awareness-systemen die worden gebruikt met hardware-gebaseerde (JTAG) debuggers, is het vermogen van een simulator om nauwkeurig taakschakelaars te volgen uniek. Dergelijke functies zijn onpraktisch gebleken om te implementeren in hardware-gebaseerde debuggers, omdat ze een aanzienlijke overhead zouden veroorzaken en de beschikbaarheid van hardware breakpoints zouden overbelasten. De inspectie van de ogenblikkelijke toestand is in wezen hetzelfde als de inspectie van de systeemtoestand door een hardware debugger na het stoppen van het systeem, en inderdaad is dezelfde code als gebruikt voor hardware debuggers gebruikt met Simics om feiten te bepalen zoals relocatie-adressen voor dynamisch geladen modules.
Een agent-gebaseerde debugger heeft geen OS awareness nodig, omdat het draait binnen het doelsysteem en OS APIs kan gebruiken om het doel-OS te vragen naar draaiende taken, geladen modules, en andere informatie.