La mayoría de los cambios necesarios para admitir VirtIO en AAOS implican cambios en el nivel de implementación de HAL y en niveles inferiores en el kernel común de Android. El marco de Android se comunica con un HAL genérico independiente del hardware mediante los controladores VirtIO en el kernel de la VM invitada AAOS, que se comunica con los dispositivos VirtIO en el lado del host mediante protocolos VirtIO. Los dispositivos VirtIO en el lado del host pueden acceder al hardware físico mediante controladores de dispositivo específicos de SoC.
La comunicación entre el controlador VirtIO y el dispositivo VirtIO se realiza con virtqueue , que son búferes en anillo similares a DMA de listas de recopilación de dispersión. Se pueden utilizar varios transportes, como MMIO o PCI, para intercambiar mensajes VirtIO entre máquinas virtuales.
En algunos casos, se ha aprovechado vsock 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 par en una máquina virtual separada a través de una interfaz vsock . GRPC-vsock se utiliza para acceder a estos subsistemas no estandarizados. GRPC en el árbol de código fuente de Android se ha modificado para funcionar con vsock con el formato de dirección vsock:CID:PORT_NUMBER .
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 máquina virtual de Android para que la implementación de audio HAL pueda interactuar con los dispositivos de sonido virtualizados con la biblioteca TinyALSA.
La implementación de audio HAL 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 propio 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 enfoque de audio en AAOS. Por ejemplo, cuando el sistema reproduce sonidos de emergencia, es posible que sea necesario silenciar la música que se reproduce en segundo plano. El control de audio HAL notifica a las aplicaciones que reproducen música que se silencien en esta situación. En el sistema virtualizado, los sonidos pueden provenir de otras máquinas virtuales. En la implementación de referencia, la VM invitada AAOS tiene un demonio de servidor de control de audio en ejecución, que utiliza GRPC-vsock para recibir solicitudes de enfoque de audio de otras VM. 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, continúa enviando latidos a AAOS hasta que se libera el foco.
Bluetooth
La implementación de Bluetooth se basa en el diseño que se ilustra a continuación.
Perfil manos libres Bluetooth
Para habilitar el perfil de manos libres Bluetooth (HFP) en trout , la especificación del dispositivo de sonido VirtIO se ha ampliado para admitir controles de audio. Usando este enfoque, un dispositivo de sonido VirtIO en el lado del host/hipervisor proporciona estos tres controles de audio relacionados con el HFP:
-
hfp_enable -
hfp_set_sampling_rate -
hfp_volume
Cuando AAOS se ejecuta como una máquina virtual invitada, AAOS usa TinyAlsa para configurar estos controles de audio. Para habilitar el caso de uso de HFP, el host/hipervisor realiza el enrutamiento y la calibración específicos del proveedor en consecuencia.
La implementación de Bluetooth se basa en la ilustración de diseño siguiente.
estado de volcado
Al generar el informe de errores para AAOS virtualizado, es valioso incluir información de la máquina virtual del host para que los desarrolladores tengan una visión más completa del sistema. Para lograr esto, la implementación de referencia trout implementa IDumpstateDevice HAL, que recopila la información de la VM del host a través de GRPC-vsock . La información de la máquina virtual host empaquetada en `tar` se denomina dumpstate_board.bin en el informe de error, mientras que los registros de volcado se encuentran en dumpstate_board.txt .
Para configurar los comandos a ejecutar:
- Copie los detalles de configuración del archivo siguiente 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> - Pase la ruta del nuevo archivo XML al servidor dumpstate al iniciar. Por ejemplo:
--config_file my_config.xml
Sistema de vista extendida (EVS)
El sistema de visión extendida (EVS) se utiliza para mostrar el vídeo capturado por las cámaras de visión trasera y 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 Modo garaje .
La entrada y salida del modo Garaje se activa mediante las propiedades AP_POWER_STATE_REQ enviadas por el vehículo HAL. En el modo de virtualización, el modo Garage se activa desde el lado del host. La máquina virtual host debe permanecer encendida para proporcionar dispositivos virtuales para la máquina virtual de Android, hasta que se apague Android. El servidor VHAL en la VM host envía la señal de apagado a la VM invitada AAOS. Al recibir la señal del cliente VHAL, la VM AAOS ingresa al modo Garaje y comienza a enviar señales de latido para mantener activa la VM host.
Sistema global de navegación por satélite (GNSS)
En trout 1.0, se agregó soporte para la virtualización GNSS a través de virtio-console . La implementación admite el intercambio de mediciones sin procesar y correcciones de ubicación del anfitrión al huésped.
El formato de intercambio de datos es el CSV utilizado por la aplicación GnssLogger. En la implementación de referencia, debido a que el controlador GNSS nativo no está disponible, se ponen a disposición datos simulados, pero se puede implementar un controlador nativo sin ningún cambio por parte del invitado. Se proporciona un agente de host simulado de muestra como parte del código fuente trout .
La implementación actual espera que la inicialización de GNSS y el GNSS asistido (AGNSS) sean manejados por el entorno del sistema operativo host.
Gráficos
Cuando AAOS se ejecuta como máquina virtual 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, se pueden usar Mesa o goldfish-opengl y un controlador virtio-gpu en la VM invitada de Android y el dispositivo virtio-gpu para acceder a la GPU.
En la máquina virtual invitada de Android, Mesa o goldfish-opengl codifica los comandos OpenGLES en una secuencia Gallium o una secuencia GLES generada automáticamente, respectivamente. El controlador del kernel virtio-gpu se utiliza como transporte. En el lado del host, virglrenderer (para Mesa) y vulkan-cereal (para goldfish-opengl ) reproducen el flujo de comando decodificado sobre el controlador de GPU existente. La plataforma de referencia AAOS trout admite OpenGL ES solo con soporte Vulkan, previsto en una versión futura.
Sensores
Cuando AAOS se ejecuta como máquina virtual 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 AAOS proporciona un sensor HAL genérico e independiente del hardware que se puede utilizar para que los SoC basados en ARM accedan a los sensores.
Sensor HAL se comunica con el controlador IIO SCMI en el subsistema IIO del kernel de Linux, 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 sobre sensores. cambios de valor.
El controlador IIO SCMI utiliza el controlador VirtIO SCMI, que utiliza 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 sensores específicos de SoC.
Ubicación del sensor HAL
La implementación de referencia del sensor HAL, que utiliza VirtIO SCMI, se encuentra en device/google/trout/hal/sensors .
Configuración del sensor HAL
Es posible que el sensor HAL 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>
Vehículo HAL
La implementación de Vehicle HAL consta de dos componentes:
- Cliente. Proporciona API utilizadas por Android en AAOS virtualizados
- Servidor. Se comunica directamente con el hardware, como autobuses de vehículos (o un emulador).
En la virtualización, el servidor VHAL se ejecuta en la VM host. El cliente y el servidor VHAL se comunican a través de GRPC-vsock (para obtener más información, consulte device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Los OEM pueden utilizar un protocolo de transporte diferente a GRPC anulando las API de comunicación. Para ver ejemplos, consulte device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .
Otros subsistemas
VirtIO ya proporciona una interfaz bien definida para componentes como Block Storage, Network, Console, Input, Socket y Entropy. Para estos subsistemas, AAOS utiliza 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 utiliza el túnel virtio-net para enviar el tráfico de la red a la máquina virtual host, que tiene acceso directo a la red Wi-Fi real.