Consigli su come utilizzare hypervisor per eseguire un OS Real Time in parallelo con Windows / Linux

Question

Quali sono i vostri consigli / esperienza di utilizzo di un hypervisor (ad esempio RTS Real-Time hypervisor ) per eseguire un RTOS in parallelo con un sistema operativo non in tempo reale. Ci sono delle implicazioni sulle prestazioni? Ci sono dei rischi? (Come come si può garantire che il non-vero OS tempo non interferirà con gli aspetti in tempo reale del RTOS)

Da quello che ho capito, un dual core (o hyperthreading) CPU deve essere utilizzato in modo da poter assegnare ad ogni sistema operativo proprio core.

Answer 1

1. no, non ha bisogno di dual core o hyperthreading.
   • no, le attività non-RT non interferisce con quelli RT.

L'idea principale è quella di avere un RTOS, che esegue compiti scritti appositamente per questo sistema operativo, utilizzando il proprio API. Questi compiti sono fissati in livelli di priorità delle stringhe, in cui un task con priorità più alta sarà allways la precedenza su una priorità inferiore. I compiti prioritari bassi eseguiranno solo finché non c'è nessun altro compito a disposizione per l'esecuzione (cioè, sono tutti in attesa di qualche evento, o un timeout o un segnale esterno).

tutto questo è proprio come un normale multitasking del sistema operativo di pianificazione, non ha bisogno multple anime o thread hardware; è solo che le garanzie di temporizzazione sono radicalmente diversi, e l'API disponibili rispecchia questo fatto.

In quelle implementazioni ibride, c'è una singola attività di livello più basso che utilizzi un kernel completo non-RT OS, di solito Linux o qualche altro kernel unix-like (non so su Windows, ma dovrebbe funzionare lo stesso). Al giorno d'oggi, che noi chiamiamo questa architettura un hypervisor.

così, dal momento che tutta la non-RT OS viene eseguito come il compito più bassa priorità, non ha alcuna garanzia di ottenere il tempo di elaborazione a tutti. tutta l'operazione RT può interrompere in qualsiasi momento, anche quando si accede hardware. per mantenere questo, di solito i compiti RT hanno un accesso molto limitato al hardware o ci sono arbitrati minimi a livello molto basso. Per esempio: può interrompere un accesso al disco (risultante in un errore di accesso); ma non un accesso PCI (finché sono di breve durata e che richiede tempo limitato)

ci sono anche alcune estensioni soft-RT allo scheduler di Linux da qualche tempo; ma le garanzie di temporizzazione non sono così stretti come alcuni hard-RT sistemi operativi costruiti con questo in mente.