La plupart des modifications nécessaires pour prendre en charge VirtIO dans AAOS impliquent des modifications au niveau de l'implémentation HAL et en dessous dans le noyau commun Android. Le framework Android communique avec un HAL générique indépendant du matériel à l'aide des pilotes VirtIO dans le noyau de la machine virtuelle invitée AAOS, qui communique avec les périphériques VirtIO côté hôte à l'aide des protocoles VirtIO. Les périphériques VirtIO côté hôte peuvent accéder au matériel physique à l'aide de pilotes de périphériques spécifiques au SoC.
La communication entre le pilote VirtIO et le périphérique VirtIO s'effectue avec virtqueue , qui sont des tampons circulaires de type DMA de listes de collecte de dispersion. Plusieurs transports, tels que MMIO ou PCI peuvent être utilisés pour échanger les messages VirtIO entre les VM.
Dans certains cas, vsock a été utilisé pour la communication inter-VM. Les communications Vehicle HAL, Audio Control et Dumpstate sont prises en charge à l'aide d'une connexion à un agent homologue sur une machine virtuelle distincte via une interface vsock . GRPC-vsock est utilisé pour accéder à ces sous-systèmes non standardisés. GRPC dans l'arborescence source d'Android a été modifié pour fonctionner avec vsock avec le format d'adresse vsock:CID:PORT_NUMBER .
l'audio
Dans AAOS virtualisé, la machine virtuelle invitée Android peut utiliser virtio-snd pour accéder à l'audio. virtio-snd fournit les périphériques PCM virtualisés à la machine virtuelle Android afin que l'implémentation audio HAL puisse interagir avec les périphériques audio virtualisés avec la bibliothèque TinyALSA.
L'implémentation audio par défaut de HAL se trouve dans AOSP à /device/google/trout/hal/audio/6.0 . Les OEM peuvent modifier ro.vendor.trout.audiohal.{in,out}_period_{ms,count} pour leur plate-forme. Les OEM peuvent également implémenter leur propre HAL audio en remplaçant les variables liées à l'audio dans /device/google/trout/aosp_trout_common.mk.
Le contrôle audio HAL gère le focus audio dans AAOS. Par exemple, lorsque le système émet des sons d'urgence, il peut être nécessaire de couper la musique en arrière-plan. Le contrôle audio HAL avertira les applications jouant de la musique de se mettre en sourdine dans cette situation. Dans le système virtualisé, les sons peuvent provenir d'autres VM. Dans l'implémentation de référence, la machine virtuelle invitée AAOS a un démon de serveur de contrôle audio en cours d'exécution, qui utilise GRPC-vsock pour recevoir des demandes de focus audio d'autres machines virtuelles. La machine virtuelle hôte peut utiliser device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller pour envoyer des demandes de contrôle audio à AAOS. Pendant que libandroid_audio_controller détient le focus audio, il continuera à envoyer des battements de cœur à AAOS jusqu'à ce que le focus soit libéré.
Bluetooth
L'implémentation Bluetooth est basée sur la conception illustrée ci-dessous.
Profil mains libres Bluetooth
Pour activer le profil mains libres Bluetooth (HFP) sur trout , la spécification du périphérique audio VirtIO a été étendue pour prendre en charge les commandes audio. En utilisant cette approche, un périphérique audio VirtIO côté hôte/hyperviseur fournit ces trois contrôles audio liés au HFP :
-
hfp_enable -
hfp_set_sampling_rate -
hfp_volume
Lorsque AAOS s'exécute en tant que machine virtuelle invitée, AAOS utilise TinyAlsa pour définir ces commandes audio. Pour activer le cas d'utilisation HFP, l'hôte/hyperviseur effectue le routage et l'étalonnage spécifiques au fournisseur en conséquence.
L'implémentation Bluetooth est basée sur l'illustration de conception ci-dessous.
État de vidage
Lors de la génération du rapport de bogue pour AAOS virtualisé, il est utile d'inclure des informations sur la machine virtuelle hôte afin que les développeurs aient une vue plus complète du système. Pour ce faire, l'implémentation de référence trout implémente IDumpstateDevice HAL, qui collecte les informations de la machine virtuelle hôte via GRPC-vsock . Les informations de la machine virtuelle hôte empaquetées `tar` sont nommées dumpstate_board.bin dans le rapport de bogue tandis que les journaux de vidage se trouvent dans dumpstate_board.txt .
Pour configurer les commandes à exécuter :
- Copiez les détails de configuration du fichier ci-dessous dans un fichier XML, par exemple,
config.xml.<dumpstateHalConfiguration version="1.0"> <services> <service name="coqos-virtio-blk" command="/bin/journalctl --no-pager -t coqos-virtio-blk"/> <service name="coqos-virtio-net" command="/bin/journalctl --no-pager -t coqos-virtio-net"/> <service name="coqos-virtio-video" command="/bin/journalctl --no-pager -t coqos-virtio-video"/> <service name="coqos-virtio-console" command="/bin/journalctl --no-pager -t coqos-virtio-console"/> <service name="coqos-virtio-rng" command="/bin/journalctl --no-pager -t coqos-virtio-rng"/> <service name="coqos-virtio-vsock" command="/bin/journalctl --no-pager -t coqos-virtio-vsock"/> <service name="coqos-virtio-gpu-virgl" command="/bin/journalctl --no-pager -t coqos-virtio-gpu-virgl"/> <service name="coqos-virtio-scmi" command="/bin/journalctl --no-pager -t coqos-virtio-scmi"/> <service name="coqos-virtio-input" command="/bin/journalctl --no-pager -t coqos-virtio-input"/> <service name="coqos-virtio-snd" command="/bin/journalctl --no-pager -t coqos-virtio-snd"/> <service name="dumpstate_grpc_server" command="/bin/journalctl --no-pager -t dumpstate_grpc_server"/> <service name="systemd" command="/bin/journalctl --no-pager -t systemd"/> <service name="systemctl" command="/bin/systemctl status"/> <service name="vehicle_hal_grpc_server" command="/bin/journalctl --no-pager -t vehicle_hal_grpc_server"/> </services> <systemLogs> <service name="dmesg" command="/bin/dmesg -kuPT"/> </systemLogs> </dumpstateHalConfiguration> - Transmettez le chemin du nouveau fichier XML au serveur dumpstate lors du lancement. Par exemple :
--config_file my_config.xml
Système de vue étendue (EVS)
Le système de vue étendue (EVS) est utilisé pour afficher la vidéo capturée par les caméras de recul et de vision panoramique. Dans AAOS virtualisé, la pile EVS peut accéder au flux vidéo à partir du périphérique de diffusion V4L2 virtualisé qui utilise le pilote vidéo VirtIO.
Mode garage
Pour plus d'informations, voir Mode Garage .
L'entrée et la sortie du mode Garage sont déclenchées par les propriétés AP_POWER_STATE_REQ envoyées par la HAL du véhicule. En mode virtualisation, le mode Garage est déclenché du côté hôte. La machine virtuelle hôte doit rester sous tension pour fournir des périphériques virtuels à la machine virtuelle Android, jusqu'à ce qu'Android soit éteint. Le serveur VHAL sur la machine virtuelle hôte envoie le signal d'arrêt à la machine virtuelle invitée AAOS. Dès réception du signal VHAL client, la VM AAOS passe en mode Garage et commence à envoyer des signaux de pulsation pour maintenir la VM hôte active.
Système mondial de navigation par satellite (GNSS)
Dans trout 1.0, la prise en charge de la virtualisation GNSS sur virtio-console a été ajoutée. L'implémentation prend en charge l'échange de mesures brutes et de correctifs de localisation de l'hôte vers l'invité.
Le format d'échange de données est le CSV utilisé par l'application GnssLogger. Dans l'implémentation de référence, étant donné que le pilote GNSS natif n'est pas disponible, des données fictives sont mises à disposition, mais un pilote natif peut être implémenté sans aucune modification côté invité. Un exemple d'agent hôte factice est fourni dans le cadre du code source trout .
L'implémentation actuelle s'attend à ce que l'initialisation du GNSS et le GNSS assisté (AGNSS) soient gérés par l'environnement du système d'exploitation hôte.
Graphique
Lorsque AAOS s'exécute en tant que machine virtuelle invitée aux côtés d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir un accès direct au GPU ou au contrôleur d'affichage. Dans ce cas, Mesa ou goldfish-opengl et un pilote virtio-gpu sur la machine virtuelle invitée Android et le périphérique virtio-gpu peuvent être utilisés pour accéder au GPU.
Sur la machine virtuelle invitée Android, Mesa ou goldfish-opengl encode les commandes OpenGLES soit dans un flux Gallium, soit dans un flux GLES généré automatiquement, respectivement. Le pilote du noyau virtio-gpu est utilisé comme moyen de transport. Du côté de l'hôte, virglrenderer (pour Mesa) et vulkan-cereal (pour goldfish-opengl ) rejouent le flux de commande décodé au-dessus du pilote GPU existant. La trout de la plate-forme de référence AAOS prend en charge OpenGL ES uniquement avec le support Vulkan, prévu dans une future version.
Capteurs
Lorsque AAOS s'exécute en tant que machine virtuelle invitée aux côtés d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir un accès direct aux capteurs. Dans ce cas, le pilote Virtio-SCMI sur la VM invitée Android et le périphérique VirtIO-SCMI sur la VM hôte sont utilisés pour accéder aux capteurs. La plate-forme de référence de virtualisation AAOS fournit une HAL de capteur générique et indépendante du matériel qui peut être utilisée pour que les SoC basés sur ARM accèdent aux capteurs.
Sensor HAL communique avec le pilote IIO SCMI dans le sous-système Linux Kernel IIO, qui utilise le protocole de gestion de capteur SCMI fourni par la spécification ARM System Control and Management Interface (SCMI) pour découvrir et configurer les capteurs, lire les données des capteurs et être averti du capteur. changements de valeur.
Le pilote IIO SCMI utilise le pilote VirtIO SCMI, qui utilise le protocole de transport VirtIO comme spécifié dans la spécification virtio-scmi pour échanger des messages SCMI avec le périphérique VirtIO SCMI sur la machine virtuelle hôte. Le périphérique VirtIO SCMI a un accès direct aux capteurs via des pilotes de capteur spécifiques au SoC.
Emplacement HAL du capteur
L'implémentation de référence du capteur HAL, qui utilise VirtIO SCMI, se trouve sur device/google/trout/hal/sensors .
Configuration HAL du capteur
Le capteur HAL peut avoir besoin de modifier les données du capteur reçues de la machine virtuelle hôte pour se conformer au système de coordonnées du capteur de voiture Android. Le schéma de configuration du capteur se trouve dans device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .
Les OEM peuvent fournir la configuration du capteur, telle que l'orientation et l'emplacement, dans sensor_hal_configuration.xml et copier le fichier dans /odm/etc/sensors/ ou /vendor/etc/sensors/ . Un exemple de configuration de capteur est fourni ci-dessous :
<sensorHalConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
<modules>
<module halName="android.hardware.sensors@2.0-Google-IIO-Subhal" halVersion="2.0">
<sensors>
<sensor name="scmi.iio.accel" type="1">
<configuration>
<!-- Attribute rotate denotes if HAL needs to modify the sensor data to comply with //
the Android car sensor coordinate system -->
<orientation rotate="true">
<!-- Attribute map denotes the indexes of data in sensor data received -->
<!-- Attribute negate denotes if data needs to be negated -->
<x map="0" negate="false"/>
<y map="1" negate="true"/>
<z map="2" negate="true"/>
</orientation>
<location>
<!-- Attribute x, y, z denotes location of the sensor placement -->
<x>10</x>
<y>15</y>
<z>20</z>
</location>
</configuration>
</sensor>
</sensors>
</module>
</modules>
</sensorHalConfiguration>
Véhicule HAL
L'implémentation de Vehicle HAL se compose de deux composants :
- Client. Fournit les API utilisées par Android dans AAOS virtualisé
- Serveur. Communique directement avec le matériel, comme les bus de véhicules (ou un émulateur).
Dans la virtualisation, le serveur VHAL s'exécute sur la machine virtuelle hôte. Le client et le serveur VHAL communiquent via GRPC-vsock (pour plus d'informations, voir device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Les OEM peuvent utiliser un protocole de transport différent de GRPC en remplaçant les API de communication. Pour obtenir des exemples, consultez device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .
Autres sous-systèmes
VirtIO fournit déjà une interface bien définie pour des composants tels que Block Storage, Network, Console, Input, Socket et Entropy. Pour ces sous-systèmes, AAOS utilise le pilote tel quel, tel que virtio-blk , virtio-input , virtio-console et virtio-net .
Dans la plate-forme de référence AAOS virtualisée, le Wi-Fi est pris en charge avec mac80211_hwsim pour activer un réseau sans fil VirtWifi , qui utilise ensuite le tunnel virtio-net pour envoyer le trafic réseau à la machine virtuelle hôte, qui a un accès direct au réseau Wi-Fi réel.