Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Arquitectura

La mayoría de los cambios necesarios para admitir VirtIO en AAOS implican cambios en el nivel de implementación de HAL y por debajo en el kernel común de Android. El marco de trabajo de Android se comunica con una HAL genérica independiente del hardware mediante los controladores VirtIO en el kernel de la máquina virtual invitada de AAOS, que se comunica con los dispositivos VirtIO en el lado del host mediante los protocolos VirtIO. Los dispositivos VirtIO en el lado del host pueden acceder al HW físico utilizando controladores de dispositivos específicos de SoC.

La comunicación entre el controlador VirtIO y el dispositivo VirtIO se lleva a cabo con virtqueue , que son búferes de anillo similares a DMA de listas de recopilación dispersa. Se pueden usar varios transportes, como MMIO o PCI , para intercambiar los mensajes de VirtIO entre máquinas virtuales.

En algunos casos, vsock se ha aprovechado para la comunicación entre máquinas virtuales. Las comunicaciones HAL del vehículo, Control de audio y Dumpstate se admiten mediante una conexión a un agente del mismo nivel en una VM separada a través de una interfaz vsock . GRPC-vsock se utiliza para acceder a estos subsistemas no estandarizados. GRPC en el árbol de fuentes de Android se ha modificado para que funcione con vsock con el formato de dirección de vsock:CID:PORT_NUMBER .

Arquitectura de virtualización
Figura 1. Arquitectura de virtualización

Gráficos

Cuando AAOS se ejecuta como una VM invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a la GPU o al controlador de pantalla. En este caso, Mesa y un virtio-gpu en la VM invitada de Android y el dispositivo virtio-gpu se pueden usar para acceder a la GPU.

En la máquina virtual invitada de Android, Mesa usa el marco Gallium3D para compilar sombreadores en la representación intermedia de TGSI y traduce la API en objetos de estado. Luego, Gallium3D envía objetos de estado compilados y las llamadas de sorteo a Mesa Virgl, que luego usa virtio-gpu como protocolo de transporte para enviar comandos y sombreadores a la máquina virtual host.

En el lado del host, virglrenderer recibe el flujo de comandos virtio-gpu y convierte el flujo en comandos OpenGL ES. También traduce sombreadores del formato TGSI al formato GLSL y luego los reproduce sobre el controlador GPU existente.

La trout de la plataforma de referencia de AAOS actualmente es compatible con OpenGL ES solo con soporte Vulkan, anticipado en una versión futura.

Arquitectura gráfica
Figura 2. Arquitectura de gráficos

Sensores

Cuando AAOS se ejecuta como una VM invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a los sensores. En este caso, el controlador Virtio-SCMI en la VM invitada de Android y el dispositivo VirtIO-SCMI en la VM host se utilizan para acceder a los sensores. La plataforma de referencia de virtualización de AAOS proporciona una HAL de sensor genérica e independiente del HW que se puede usar para que los SoC basados ​​en ARM accedan a los sensores.

El sensor HAL se comunica con el controlador IIO SCMI en el subsistema Linux Kernel IIO, que utiliza el protocolo de administración de sensores SCMI proporcionado por la especificación ARM System Control and Management Interface (SCMI) para descubrir y configurar sensores, leer datos de sensores y recibir notificaciones de sensores. cambios de valor. El controlador IIO SCMI usa el controlador VirtIO SCMI, que usa el protocolo de transporte VirtIO como se especifica en la especificación virtio-scmi para intercambiar mensajes SCMI con el dispositivo VirtIO SCMI en la máquina virtual host. El dispositivo VirtIO SCMI tiene acceso directo a los sensores a través de controladores de sensor específicos de SoC.

Arquitectura de sensores
Figura 3. Arquitectura del sensor

Ubicación HAL del sensor

La implementación de referencia del sensor HAL, que utiliza VirtIO SCMI, se encuentra en device/google/trout/hal/sensors .

Configuración HAL del sensor

Es posible que el HAL del sensor deba modificar los datos del sensor recibidos de la máquina virtual host para cumplir con el sistema de coordenadas del sensor del automóvil de Android. El esquema para la configuración del sensor se puede encontrar en device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .

Los OEM pueden proporcionar la configuración del sensor, como la orientación y la ubicación, en sensor_hal_configuration.xml y copiar el archivo en /odm/etc/sensors/ o /vendor/etc/sensors/ . A continuación se proporciona una configuración de sensor de muestra:

<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>

Audio

En AAOS virtualizado, la VM invitada de Android puede usar virtio-snd para acceder al audio. virtio-snd proporciona los dispositivos PCM virtualizados a la VM de Android para que la implementación de HAL de audio pueda interactuar con los dispositivos de sonido virtualizados con la biblioteca TinyALSA.

La implementación de HAL de audio predeterminada se encuentra en AOSP en /device/google/trout/hal/audio/6.0 . Los OEM pueden modificar ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para su plataforma. Los OEM también pueden implementar su propia HAL de audio anulando las variables relacionadas con el audio en /device/google/trout/aosp_trout_common.mk.

El control de audio HAL gestiona el foco de audio en AAOS. Por ejemplo, cuando el sistema está reproduciendo sonidos de emergencia, es posible que sea necesario silenciar la música de fondo. El control de audio HAL notificará a aquellas aplicaciones que reproduzcan música para silenciarlas en esta situación. En el sistema virtualizado, los sonidos pueden provenir de otras máquinas virtuales. En la implementación de referencia, la máquina virtual invitada de AAOS tiene un demonio de servidor de control de audio en ejecución, que usa GRPC-vsock para recibir solicitudes de enfoque de audio de otras máquinas virtuales. La máquina virtual host puede usar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller para enviar solicitudes de control de audio a AAOS. Mientras libandroid_audio_controller mantiene el foco de audio, continuará enviando latidos a AAOS hasta que se libere el foco.

Arquitectura de sonido
Figura 4. Arquitectura de audio

Bluetooth

Cuando AAOS se ejecuta como una máquina virtual invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo al controlador Bluetooth. En este caso, el controlador VirtIO-Console en la VM invitada de Android y el dispositivo VirtIO-Console en la VM host se pueden usar para abrir un puerto COM virtual y enviar los paquetes HCI al controlador Bluetooth y recibir eventos. Este diseño permite que la pila Bluetooth de Android utilice una HAL de Bluetooth genérica e independiente del HW. La máquina virtual host puede manejar tareas específicas de HW, como la inicialización y la descarga de firmware del controlador Bluetooth.

La implementación de Bluetooth se basa en la siguiente ilustración de diseño.

arquitectura Bluetooth
Figura 5. Arquitectura Bluetooth

HAL del vehículo

La implementación de Vehicle HAL consta de dos componentes:

  • Cliente. Proporciona las API utilizadas por Android en AAOS virtualizado
  • Servidor. Se comunica directamente con el hardware, como buses de vehículos (o un emulador).

En la virtualización, el servidor VHAL se ejecuta en la máquina virtual host. El cliente y el servidor VHAL se comunican a través GRPC-vsock (para obtener más información, consulte device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Los OEM pueden usar un protocolo de transporte diferente al de GRPC anulando las API de comunicación. Para ver ejemplos, consulte device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Sistema de vista extendida

El sistema de vista extendida (EVS) se usa para mostrar videos capturados por las cámaras de visión trasera y de visión envolvente. En AAOS virtualizado, la pila EVS puede acceder a la transmisión de video desde el dispositivo de transmisión V4L2 virtualizado que utiliza el controlador de video VirtIO.

modo garaje

Para obtener más información, consulte ¿Qué es el modo de garaje? .

Entrar y salir del modo Garaje se activa mediante las propiedades AP_POWER_STATE_REQ enviadas por el HAL del vehículo. En el modo de virtualización, el modo Garaje se activa desde el lado del host. La VM del host debe permanecer encendida para proporcionar dispositivos virtuales para la VM de Android, hasta que se apague Android. El servidor VHAL en la máquina virtual host envía la señal de apagado a la máquina virtual invitada de AAOS. Al recibir la señal del cliente VHAL, la VM de AAOS ingresa al modo de garaje y comienza a enviar señales de latido para mantener activa la VM del host.

basurero

Al generar el informe de errores para AAOS virtualizado, es valioso incluir información de la máquina virtual host para que los desarrolladores tengan una visión más completa del sistema. Para lograr esto, la implementación de referencia de trout implementa IDumpstateDevice HAL, que recopila la información de la máquina virtual host a través GRPC-vsock . La información de la VM del host empaquetada en tar se denomina dumpstate_board.bin en el informe de errores, mientras que los registros de volcado se encuentran en dumpstate_board.txt .

Para configurar los comandos a ejecutar:

  1. Copie los detalles de configuración del archivo a continuación en un archivo XML, por ejemplo, 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>
    
  2. Pase la ruta del nuevo archivo XML al servidor dumpstate cuando se inicie. Por ejemplo:
    --config_file my_config.xml
    

Otros subsistemas

VirtIO ya proporciona una interfaz bien definida para componentes como Block Storage, Network, Console, Input, Socket y Entropy. Para estos subsistemas, AAOS usa el controlador tal cual, como virtio-blk , virtio-input , virtio-console y virtio-net .

En la plataforma de referencia AAOS virtualizada, Wi-Fi es compatible con mac80211_hwsim para habilitar una red inalámbrica VirtWifi , que luego usa el túnel virtio-net para enviar el tráfico de red a la máquina virtual host, que tiene acceso directo a la red Wi-Fi real.