Architektura

Większość zmian potrzebnych do obsługi VirtIO w AAOS obejmuje zmiany na poziomie implementacji HAL i poniżej we wspólnym jądrze Androida. Struktura systemu Android komunikuje się z ogólną, niezależną od sprzętu warstwą HAL przy użyciu sterowników VirtIO w jądrze maszyny wirtualnej gościa AAOS, która komunikuje się z urządzeniami VirtIO po stronie hosta za pomocą protokołów VirtIO. Urządzenia VirtIO po stronie hosta mogą uzyskać dostęp do fizycznego sprzętu za pomocą sterowników urządzeń specyficznych dla SoC.

Komunikacja pomiędzy sterownikiem VirtIO a urządzeniem VirtIO odbywa się za pomocą virtqueue , które są buforami pierścieniowymi typu DMA list gromadzenia rozproszonego. Do wymiany komunikatów VirtIO pomiędzy maszynami wirtualnymi można wykorzystać kilka transportów, takich jak MMIO lub PCI .

W niektórych przypadkach vsock został wykorzystany do komunikacji między maszynami wirtualnymi. Komunikacja HAL pojazdu, sterowanie dźwiękiem i stan zrzutu są obsługiwane przy użyciu połączenia z agentem równorzędnym na osobnej maszynie wirtualnej za pośrednictwem interfejsu vsock . Aby uzyskać dostęp do tych niestandaryzowanych podsystemów, używany jest GRPC-vsock . GRPC w drzewie źródłowym Androida został zmodyfikowany do współpracy z vsock z formatem adresu vsock:CID:PORT_NUMBER .

Architektura wirtualizacji
Rysunek 1. Architektura wirtualizacji

Audio

W zwirtualizowanym AAOS maszyna wirtualna gościa z Androidem może używać virtio-snd w celu uzyskania dostępu do dźwięku. virtio-snd udostępnia zwirtualizowane urządzenia PCM maszynie wirtualnej z systemem Android, dzięki czemu implementacja audio HAL może wchodzić w interakcję ze zwirtualizowanymi urządzeniami dźwiękowymi za pomocą biblioteki TinyALSA.

Domyślna implementacja audio HAL znajduje się w AOSP pod /device/google/trout/hal/audio/6.0 . Producenci OEM mogą modyfikować ro.vendor.trout.audiohal.{in,out}_period_{ms,count} dla swojej platformy. Producenci OEM mogą również wdrożyć własną warstwę audio HAL, zastępując zmienne związane z dźwiękiem w /device/google/trout/aosp_trout_common.mk.

Sterowanie dźwiękiem HAL zarządza fokusem audio w AAOS. Na przykład, gdy system odtwarza dźwięki alarmowe, konieczne może być wyciszenie muzyki odtwarzanej w tle. Sterowanie dźwiękiem HAL powiadamia aplikacje odtwarzające muzykę o konieczności wyciszenia w tej sytuacji. W systemie zwirtualizowanym dźwięki mogą pochodzić z innych maszyn wirtualnych. W implementacji referencyjnej na maszynie wirtualnej gościa AAOS działa demon serwera kontroli dźwięku, który używa GRPC-vsock do odbierania żądań fokusu audio od innych maszyn wirtualnych. Maszyna wirtualna hosta może używać device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller do wysyłania żądań kontroli dźwięku do AAOS. Podczas gdy libandroid_audio_controller utrzymuje fokus audio, nadal wysyła pulsy do AAOS, dopóki fokus nie zostanie zwolniony.

Architektura dźwięku
Rysunek 5. Architektura audio

Bluetooth

Implementacja Bluetooth opiera się na projekcie przedstawionym poniżej.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth

Profil zestawu głośnomówiącego Bluetooth

Aby włączyć profil głośnomówiący Bluetooth (HFP) na trout , specyfikacja urządzenia dźwiękowego VirtIO została rozszerzona o obsługę sterowania audio. Stosując to podejście, urządzenie dźwiękowe VirtIO po stronie hosta/hypervisora ​​zapewnia trzy elementy sterujące dźwiękiem powiązane z HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Gdy AAOS działa jako maszyna wirtualna gościa, AAOS używa TinyAlsa do ustawiania tych elementów sterujących dźwiękiem. Aby włączyć przypadek użycia HFP, host/hiperwizor odpowiednio wykonuje routing i kalibrację specyficzne dla dostawcy.

Implementacja Bluetooth opiera się na poniższej ilustracji projektu.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth

Stan śmietnika

Podczas generowania raportu o błędach dla zwirtualizowanego AAOS warto uwzględnić informacje o maszynie wirtualnej hosta, aby programiści mieli pełniejszy wgląd w system. Aby to osiągnąć, implementacja referencyjna trout implementuje IDumpstateDevice HAL, która zbiera informacje o maszynie wirtualnej hosta za pośrednictwem GRPC-vsock . Informacje o maszynie wirtualnej hosta spakowane w formacie tar mają nazwę dumpstate_board.bin w raporcie o błędach, natomiast dzienniki zrzutu znajdują się pod dumpstate_board.txt .

Aby skonfigurować polecenia do wykonania:

  1. Skopiuj szczegóły konfiguracji z poniższego pliku do pliku XML, na przykład 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. Podczas uruchamiania przekaż ścieżkę nowego pliku XML do serwera stanu zrzutu. Na przykład:
    --config_file my_config.xml

System rozszerzonego widoku (EVS)

System rozszerzonego widoku (EVS) służy do wyświetlania obrazu wideo zarejestrowanego przez kamery cofania i kamery surround. W zwirtualizowanym AAOS stos EVS może uzyskać dostęp do strumienia wideo ze zwirtualizowanego urządzenia do przesyłania strumieniowego V4L2, które korzysta ze sterownika wideo VirtIO.

Tryb garażowy

Aby uzyskać więcej informacji, zobacz Tryb garażowy .

Wejście i wyjście z trybu garażu jest wyzwalane przez właściwości AP_POWER_STATE_REQ wysyłane przez HAL pojazdu. W trybie wirtualizacji tryb garażu jest uruchamiany po stronie hosta. Maszyna wirtualna hosta powinna pozostać włączona, aby zapewnić urządzenia wirtualne dla maszyny wirtualnej z systemem Android, dopóki system Android nie zostanie wyłączony. Serwer VHAL na maszynie wirtualnej hosta wysyła sygnał zamknięcia do maszyny wirtualnej gościa AAOS. Po odebraniu sygnału klienta VHAL maszyna wirtualna AAOS przechodzi w tryb garażu i zaczyna wysyłać sygnały pulsu, aby utrzymać aktywność maszyny wirtualnej hosta.

Globalny system nawigacji satelitarnej (GNSS)

W trout 1.0 dodano obsługę wirtualizacji GNSS poprzez virtio-console . Implementacja wspiera wymianę surowych pomiarów i poprawek lokalizacji od gospodarza do gościa.

Format wymiany danych to CSV używany przez aplikację GnssLogger. W implementacji referencyjnej, ponieważ natywny sterownik GNSS nie jest dostępny, udostępniane są próbne dane, ale natywny sterownik można zaimplementować bez żadnych zmian po stronie gościa. Przykładowy fałszywy agent hosta jest dostarczany jako część kodu źródłowego trout .

Obecna implementacja oczekuje, że inicjalizacja GNSS i wspomagany GNSS (AGNSS) będą obsługiwane przez środowisko systemu operacyjnego hosta.

Architektura GNSS
Rysunek 2. Architektura GNSS

Grafika

Gdy AAOS działa jako maszyna wirtualna gościa wraz z innymi samochodowymi systemami operacyjnymi, Android może nie mieć bezpośredniego dostępu do procesora graficznego lub kontrolera wyświetlacza. W tym przypadku do uzyskania dostępu do procesora graficznego można użyć Mesa lub goldfish-opengl i sterownika virtio-gpu na maszynie wirtualnej gościa z systemem Android i urządzeniu virtio-gpu .

Na maszynie wirtualnej gościa z Androidem Mesa lub goldfish-opengl koduje polecenia OpenGLES odpowiednio w strumieniu Gallium lub automatycznie generowanym strumieniu GLES. Jako transport używany jest sterownik jądra virtio-gpu . Po stronie hosta virglrenderer (dla Mesa) i vulkan-cereal (dla goldfish-opengl ) odtwarzają zdekodowany strumień poleceń na istniejącym sterowniku GPU. Platforma referencyjna AAOS trout obsługuje OpenGL ES tylko ze wsparciem Vulkan, przewidywanym w przyszłej wersji.

Architektura graficzna
Rysunek 3. Architektura graficzna

Czujniki

Gdy AAOS działa jako gościnna maszyna wirtualna wraz z innymi samochodowymi systemami operacyjnymi, Android może nie mieć bezpośredniego dostępu do czujników. W tym przypadku sterownik Virtio-SCMI na maszynie wirtualnej gościa z systemem Android i urządzenie VirtIO-SCMI na maszynie wirtualnej hosta służą do uzyskiwania dostępu do czujników. Platforma referencyjna wirtualizacji AAOS zapewnia ogólną, niezależną od sprzętu warstwę HAL czujnika, której można używać w układach SoC opartych na architekturze ARM w celu uzyskania dostępu do czujników.

Sensor HAL komunikuje się ze sterownikiem IIO SCMI w podsystemie Linux Kernel IIO, który wykorzystuje protokół SCMI Sensor Management Protocol dostarczony przez specyfikację ARM System Control and Management Interface (SCMI) do wykrywania i konfigurowania czujników, odczytywania danych z czujników i otrzymywania powiadomień o czujnikach zmiany wartości.

Sterownik IIO SCMI wykorzystuje sterownik VirtIO SCMI, który wykorzystuje protokół transportowy VirtIO zgodnie ze specyfikacją virtio-scmi do wymiany komunikatów SCMI z urządzeniem VirtIO SCMI na maszynie wirtualnej hosta. Urządzenie VirtIO SCMI ma bezpośredni dostęp do czujników poprzez sterowniki czujników specyficzne dla SoC.

Architektura czujnika
Rysunek 4. Architektura czujnika

Lokalizacja czujnika HAL

Referencyjna implementacja czujnika HAL, który wykorzystuje VirtIO SCMI, znajduje się pod device/google/trout/hal/sensors .

Konfiguracja czujnika HAL

Może być konieczne zmodyfikowanie danych czujnika otrzymanych z hosta VM w systemie HAL w celu zapewnienia zgodności z układem współrzędnych czujnika samochodu z systemem Android. Schemat konfiguracji czujnika można znaleźć w device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .

Producenci OEM mogą udostępnić konfigurację czujnika, taką jak orientacja i lokalizacja, w sensor_hal_configuration.xml i skopiować plik do katalogu /odm/etc/sensors/ lub /vendor/etc/sensors/ . Poniżej przedstawiono przykładową konfigurację czujnika:

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

Pojazd HAL

Implementacja pojazdu HAL składa się z dwóch komponentów:

  • Klient. Zapewnia interfejsy API używane przez system Android w zwirtualizowanym systemie AAOS
  • Serwer. Komunikuje się bezpośrednio ze sprzętem, takim jak autobusy samochodowe (lub emulator).

W wirtualizacji serwer VHAL działa na maszynie wirtualnej hosta. Klient i serwer VHAL komunikują się poprzez GRPC-vsock (więcej informacji można znaleźć na device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Producenci OEM mogą używać innego protokołu transportowego niż GRPC, zastępując komunikacyjne interfejsy API. Przykłady można znaleźć w device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Inne podsystemy

VirtIO zapewnia już dobrze zdefiniowany interfejs dla komponentów takich jak pamięć blokowa, sieć, konsola, wejście, gniazdo i entropia. W przypadku tych podsystemów AAOS używa sterownika w niezmienionej postaci, np. virtio-blk , virtio-input , virtio-console i virtio-net .

Na zwirtualizowanej platformie referencyjnej AAOS Wi-Fi jest obsługiwane przez mac80211_hwsim , aby umożliwić sieć bezprzewodową VirtWifi , która następnie wykorzystuje tunel virtio-net do wysyłania ruchu sieciowego do maszyny wirtualnej hosta, która ma bezpośredni dostęp do rzeczywistej sieci Wi-Fi.