VirtualizationService verwaltet mehrere geschützte oder andere Gast-VMs, die auf einem Android-System ausgeführt werden, hauptsächlich durch die Verwaltung von Crosvm-Instanzen. VirtualizationService stellt eine AIDL-API bereit, die Systemdienste oder Apps zum Starten, Überwachen und Stoppen von VMs verwenden können. Um VirtualizationService zu verwenden, führen Sie virtmgr direkt aus oder importieren Sie Javalib oder Rustlib , das virtmgr als untergeordneten Prozess ausführt.
VM-Lebenszyklus
Der Zugriff auf eine VM wird vom IVirtualMachine -Objekt verfolgt. Solange mindestens ein Verweis auf das IVirtualMachine Objekt vorhanden ist, wird die VM weiter ausgeführt (es sei denn, sie stürzt ab oder fährt von selbst herunter). Wenn alle Verweise auf das IVirtualMachine Objekt gelöscht werden, bevor die VM heruntergefahren wird, fährt VirtualizationService die VM automatisch herunter. Dieser Prozess impliziert, dass, wenn der Client, der die VM gestartet hat, durch den Low-Memory-Killer heruntergefahren wird, auch die VM heruntergefahren wird, wodurch Ressourcenlecks verhindert werden.
Jede VM wird von einer eigenen crosvm-Instanz verwaltet, die VirtualizationService wiederum im Namen des Clients verwaltet. VirtualizationService in virtmgr startet diese untergeordneten Crosvm-Prozesse nach Bedarf mit zugewiesenen globalen Ressourcen, einschließlich der von VirtualizationServiceInternal in virtualizationservice gewährten CID, und übergibt ihnen die Dateideskriptoren für die Bilder, die die VM benötigt. VirtualizationService überwacht dann den untergeordneten Prozess auf seinen Tod, sodass er alle verbleibenden Clients entsprechend benachrichtigen kann.
VM-Verpackung
crosvm unterstützt zwei verschiedene Arten, eine VM zu booten: Entweder werden ein Kernel und initrd bereitgestellt oder es wird ein Bootloader bereitgestellt. In beiden Fällen kann auch eine beliebige Anzahl von Disk-Images bereitgestellt werden, bei denen es sich entweder um ein Roh-Image oder um eine Kombination aus mehreren Partitionen handeln kann. Die verschiedenen Bilder werden vom Client als Dateideskriptoren bereitgestellt.
VirtualizationService erstellt bei Bedarf zusammengesetzte Festplatten-Images. Dieser Vorgang ist erforderlich, da die zusammengesetzte Festplattendatei intern auf die verschiedenen Partitionsbilddateien verweist, aus denen die Festplatte besteht, die vom Client übergeben werden und auf die crosvm möglicherweise nicht direkt zugreifen kann. Um dieses Problem zu umgehen, stellt VirtualizationService sicher, dass die von crosvm geerbten Dateideskriptornummern mit den Dateideskriptornummern übereinstimmen, die VirtualizationService beim Erstellen der zusammengesetzten Images verwendet hat. Das zusammengesetzte Festplatten-Image verwendet Dateinamen in der Form /proc/self/fd/N um jede Partitionsdatei darzustellen.
Für Microdroid-pVMs enthält AVF einen Bootloader, der den Kernel von einer Partition eines zusammengesetzten Festplatten-Images lädt und dabei dem standardmäßigen Android Verified Boot-Ablauf folgt.
VM-Sockets (vsock)
Die primäre Schnittstelle für die Kommunikation zwischen pVMs ist vsock, eine standardmäßige Virtio-Socket-Schnittstelle. Jede VM wird durch eine 32-Bit-Kontextkennung (CID) identifiziert, die einer IP-Adresse entspricht, die VirtualizationServiceInternal der VM zuweist, wenn VirtualizationService die VM erstellt, und Dienste auf den von der VM gewählten Portnummern verfügbar machen kann. Die CID ist während der Ausführung der VM eindeutig, aber der CID-Wert kann wiederverwendet werden, wenn die VM beendet wird und alle IVirtualMachine Binderhandles für die VM gelöscht wurden.
Debug-Schnittstelle
Der Befehl vm wird für Debugzwecke bereitgestellt. Mit diesem Befehl kann ein Entwickler eine VM über die Shell starten, ihre Protokolle anzeigen und die VM beenden. Mit dem Befehl vm oder anderen von AVF bereitgestellten Schnittstellen kann eine VM entweder im debuggbaren (FULL) oder im nicht debuggbaren (NONE) Modus gestartet werden. Mit einer debuggbaren VM können Sie Protokolle auf Betriebssystemebene anzeigen, auf die ADB-Shell zugreifen und Crash-Dumps oder App-Payloads erfassen. Es wird empfohlen, in der Produktion eine nicht debuggbare VM zu verwenden. Weitere Informationen zum Befehlszeilentool und anderen Debugschnittstellen, die AVF bereitstellt, finden Sie unter debug/README.md .