Cette page a été traduite par l'API Cloud Translation.

Architecture

La plupart des changements nécessaires pour prendre en charge VirtIO dans AAOS impliquent des changements au niveau de la mise en œuvre de HAL et ci-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 appareils 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 en anneau de type DMA de listes de collecte dispersées. 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é exploité 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 VM distincte via une interface vsock . GRPC-vsock est utilisé pour accéder à ces sous-systèmes non standardisés. GRPC dans l'arborescence des sources Android a été modifié pour fonctionner avec vsock avec le format d'adresse vsock:CID:PORT_NUMBER .

**Figure 1.** Architecture de virtualisation

l'audio

Dans AAOS virtualisé, la VM invitée Android peut utiliser virtio-snd pour accéder à l'audio. virtio-snd fournit les périphériques PCM virtualisés à la VM 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, la musique diffusée en arrière-plan devra peut-être être coupée. Le contrôle audio HAL informe les applications qui diffusent de la musique de les couper dans cette situation. Dans le système virtualisé, les sons peuvent provenir d’autres VM. Dans l'implémentation de référence, la VM invitée AAOS dispose d'un démon de serveur de contrôle audio en cours d'exécution, qui utilise GRPC-vsock pour recevoir les demandes de focus audio d'autres VM. La VM hôte peut utiliser device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller pour envoyer des requêtes de contrôle audio à AAOS. Pendant que libandroid_audio_controller détient le focus audio, il continue d'envoyer des battements de cœur à AAOS jusqu'à ce que le focus soit relâché.

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 commandes audio liées au HFP :

hfp_enable
hfp_set_sampling_rate
hfp_volume

Lorsque AAOS s'exécute en tant que VM 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 décharge

Lors de la génération du rapport de bogue pour l'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 sur la VM hôte emballées dans le package `tar` sont nommées dumpstate_board.bin dans le rapport de bug 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 vision é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 streaming 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 le véhicule HAL. En mode virtualisation, le mode Garage est déclenché côté hôte. La VM hôte doit rester sous tension pour fournir des appareils virtuels à la VM Android, jusqu'à ce qu'Android soit éteint. Le serveur VHAL sur la VM hôte envoie le signal d'arrêt à la VM invitée AAOS. Dès réception du signal client VHAL, la VM AAOS passe en mode Garage et commence à envoyer des signaux de battement de cœur 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 repères 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, comme 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 fictif est fourni dans le cadre du code source trout .

La mise en œuvre actuelle s'attend à ce que l'initialisation 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 VM invitée aux côtés d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir d'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 VM invitée Android et le périphérique virtio-gpu peuvent être utilisés pour accéder au GPU.

Sur la VM invitée Android, Mesa ou goldfish-opengl encode respectivement les commandes OpenGLES dans un flux Gallium ou dans un flux GLES généré automatiquement. Le pilote du noyau virtio-gpu est utilisé comme transport. Du côté de l'hôte, virglrenderer (pour Mesa) et vulkan-cereal (pour goldfish-opengl ) rejouent le flux de commandes décodé au-dessus du pilote GPU existant. La plate-forme de référence AAOS trout prend en charge OpenGL ES uniquement avec le support Vulkan, prévu dans une prochaine 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 d'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 un Sensor HAL générique et indépendant du matériel qui peut être utilisé pour que les SoC basés sur ARM accèdent aux capteurs.

Le capteur HAL communique avec le pilote IIO SCMI dans le sous-système Linux Kernel IIO, qui utilise le protocole de gestion des capteurs 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 de leur présence. 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 du capteur HAL

L'implémentation de référence du capteur HAL, qui utilise VirtIO SCMI, se trouve dans device/google/trout/hal/sensors .

Configuration du capteur HAL

Le capteur HAL devra peut-être modifier les données du capteur reçues de la VM hôte pour se conformer au système de coordonnées des capteurs 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 des capteurs, 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

La mise en œuvre du 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, tel que les bus de véhicules (ou un émulateur).

En virtualisation, le serveur VHAL s'exécute sur la VM 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 du GRPC en remplaçant les API de communication. Pour 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 le stockage en bloc, le réseau, la console, l'entrée, le socket et l'entropie. 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.