61 / 84
61
EMBEDDED
MAGGIO
HYPERVISOR |
SOFTWARE
controllo motore che
opera su uno stack
AUTOSAR. In passa-
to per ottenere que-
sto scopo sarebbero
servite quattro o più
piattaforme hardwa-
re diverse, ma oggi
tutte queste funzioni
sono integrate nello
stesso sistema e, se
possibile, anche nella
stessa CPU.
Perché? La prima ra-
gione è legata ai co-
sti. Al giorno d’oggi
i sistemi embedded
sono così potenti che
un solo sistema è in grado di portare a termine
tutti i compiti ad esso assegnati. Inoltre è molto
più economico produrre e installare un solo mo-
dulo hardware integrato piuttosto che quattro si-
stemi diversi. Questo è il motivo principale, dal
momento che ogni centesimo conta, specialmente
nell’industria automobilistica. Non dimentichia-
mo poi che un hypervisor garantisce un ulterio-
re livello di sicurezza e protezione. L’hypervisor
è in grado di monitorare tutti i guest e reagire
di conseguenza in caso di malfunzionamenti,
per esempio facendo ripartire un guest. È anche
fondamentale proteggere i guest da interazioni
indesiderate. Un prerequisito di carattere tecni-
co per ottenere tale protezione è assicurare che
tutti i guest rimangano ben separati gli uni da-
gli altri in termini hardware, mediante un’MMU
indipendente (Figura 1). Incontreremo di nuovo
questa caratteristica, specialmente quando par-
leremo di debug.
Funzionalità dell’hypervisor
In termini hardware i singoli guest possono es-
sere separati fra loro se la CPU permette una
completa astrazione dell’hardware. In linea di
principio, per ottenere questo risultato devono
essere virtualizzate tre risorse: la memoria, le
unità periferiche e la CPU stessa (Figura 2). Il
sistema operativo guest non dovrebbe neanche
essere consapevole che sta girando su una mac-
% 3 G
À
-
tivo continua a gestire la propria MMU (MMU di
1
À ! 0À
il guest = intermedia). Ma non si tratta in realtà
À %
-
À
seconda MMU dell’hypervisor (MMU di livello 2).
Anche le unità periferiche vengono virtualizza-
te (I/O virtuale) per assicurare che ogni singolo
guest possa interagire con l’ambiente. È ancora
l’hypervisor a decidere quale guest può accede-
re a quale componente delle unità periferiche,
% ) À
ogni guest sono assegnate una o più CPU virtuali
che vengono mappate sui core effettivi mediante
uno schedulatore. In questo scenario il numero
3*<
À
G
minore o uguale rispetto al numero di core reali.
Riprendendo l’esempio già citato per il sistema
automobilistico, una possibile catena di eventi
À @
"
Un sensore di temperatura rileva una caduta al
di sotto di 3°C e attiva un interrupt hardware.
L’interrupt è ricevuto e processato dall’hyper-
visor. L’hypervisor inoltra l’interrupt al guest
come interrupt virtuale per il cruscotto.
"
Il sistema guest riceve l’interrupt virtuale
(guest driver) e manda un segnale al processo
del guest responsabile per la gestione degli al-
larmi, il quale stampa “Pericolo: ghiaccio”.
Un altro esempio è la comunicazione fra i guest.
Il conducente dell’auto si accorge che fuori fa
freddo e preme il pulsante del riscaldamento sul
cruscotto. Di conseguenza il guest responsabile
Fig. 2 – L’hypervisor assicura una completa virtualizzazione del software esistente