2013-02-26 5 views
5

Un principio educativo è: Non esiste una cosa come una domanda stupida. L'idea alla base di questo è che le persone imparano chiedendo. Mi è stato chiesto di: "Puoi mostrare e spiegare a livello di programmazione che cosa accadrà se ogni attività può eseguire tutte le istruzioni".Inter-processore Utilizzo dell'interruzione

ho fatto dare il codice

main(){ 
     _asm_("cli;"); 
     while(1); 
    } 

e spiegato (il sistema congelato per buono- UP)

Poi mi è stato chiesto: "E 'possibile fare un esempio in modo che il sistema non congelare anche questa interruzione di compensazione è stata fatta? "

ho fatto modificare l'esempio precedente:

ho fatto dare il codice

main(){ 
     _asm_("cli;"); 
     i=i/0; 
     while(1); 
    } 

e spiegato.

Banalmente: Se abbiamo paging richiesta i = i/0 cause primo un errore di pagina (pagina dati non presente) e un altro compito può essere programmato per eseguire gli interrupt abilitati durante il disco in lettura e successivamente sulla dividere per zero getterà via questo compito per sempre.

Ma le risposte erano basate su UP. Che mi dici di SMP? Devo dire che le risposte sono incomplete. E 'ancora abbastanza facile da costruire:

int i; 
    main(){ 
    for(i=0;i<100;i++)// Suppose we have less than 100 CPUs 
     if(fork()) 
     { sleep(5);//The generating task has (most probable) time to do all forks 
     _asm_("cli;"); 
     while(1); 
     } 
    } 

che disabilitare gli interrupt per tutte le CPU, perché ogni CPU ottiene un compito velenoso per l'esecuzione.

Anche finora una domanda stupida ha rivelato molte cose buone per imparare a un principiante: istruzioni privilegiate, di paging, movimentazione di guasto, la programmazione durante DMA, forcella ..... Ma un dubbio resti minori (Vergogna su di me) sul primo programma in esecuzione su un SMP.

Una CPU si spegnerà definitivamente o no? Altre CPU continuano e possono inviare re_schedule() Messaggio IPI. Cosa succede allora? Può essere facile ipotizzare che la CPU congelata non si attivi, poiché gli interrupt sono disabilitati. Ma per essere perfettamente sicuro deve sapere di più.

La mia domanda era: L'Inter Processor Interrupt (IPI) è mascherabile o non mascherabile? Intendo nelle più comuni implementazioni "popolari"?

Scusa la mia stupida domanda. Non può essere molto difficile trovare una risposta. Lo cercherò. Intendo numero pin di interruzione (che dice mascherabile, I indovina).


La mia risposta - corretta? Ho studiato il problema, perché nessun altro l'ha fatto, venendo ai seguenti pensieri:

Con importanti applicazioni in tempo reale abbiamo avuto per molto tempo un timer watchdog (HW che interrompe CPU per rispondere in qualche modo "Sono vivo"). Ad esempio, abbiamo il computer di controllo principale e il computer di standby che si occupa del sistema se il computer principale non è attivo.

Che dire di Linux? Che tipo di cane da guardia - abbiamo uno? Possiamo compilare il kernel Linux con o senza watchdog.

Che cosa fa il cane da guardia Linux? Su molti (!) tipo di hardware x86/x86-64 c'è una funzionalità che ci consente di generare 'interrupt NMI watchdog'. È persino possibile disabilitare il watchdog NMI in fase di esecuzione scrivendo "0" in/proc/sys/kernel/nmi_watchdog. Se una CPU nel sistema non esegue l'interrupt del timer locale per più di 5 secondi, APIC tenta di risolvere la situazione con un interrupt non mascherabile (la CPU esegue il gestore e uccide il processo)! (SCC Linux è un caso diverso per NMI.)

Le mie risposte (nella domanda originale) erano basate sul sistema senza cane da guardia! È problematico rispondere a livello generale e fornire esempi basati su alcuni sistemi fissi. Le risposte possono essere corrette o meno a seconda della cpu e della configurazione e delle impostazioni.

In ogni caso, parlare di NMI aveva senso? Fatto?

+3

Dopo molto studio, rispondo alla mia domanda (a nessuno piace). – SikaS

risposta

0

Se la CPU non ha limitato l'accesso ad alcune istruzioni, sarebbe troppo facile causare accidentalmente o deliberatamente una catastrofe.

push $0 
push $0 
lidt (%esp) 
int $42 

Questa sequenza di codici ripristinerà un processore x86. Ecco perché:

  • Il codice carica registro IDTR con una tabella descrittore di interrupt (IDT) all'indirizzo lineare 0, con una dimensione di un byte.
  • Solleva l'interrupt 42, che non può funzionare perché supera il limite di 1 byte dell'IDT.
  • La CPU tenta di generare un errore di protezione generale, interrupt 13. Anche questo non funziona, poiché l'interrupt 13 supera il limite di un byte.
  • La CPU tenta di generare un'eccezione di doppio errore, interrupt 8. Anche questo non riesce, l'interrupt 8 supera il limite dell'IDT.

Questo è noto come triplo errore. La CPU esegue un ciclo del bus di spegnimento per comunicare alla scheda madre che ora sta ignorando tutto e interrompendo l'esecuzione. La scheda madre asserisce il ripristino, riavviando la macchina.

Questo è effettivamente trascurabile rispetto a quello che potrebbe fare il codice. Una sequenza di codice potrebbe facilmente dirottare completamente la macchina e iniziare a distruggere tutti i dati sul disco rigido, potrebbe inviare tutti i file a un server malevolo su Internet, potrebbe cambiare la password, abilitare l'accesso remoto, connettersi a un server malevolo e garantire a un utente malintenzionato un accesso illimitato alla shell. Non c'è limite a ciò che un programma potrebbe fare.

I processori hanno istruzioni privilegiate per due motivi, lo scopo principale è quello di proteggere il sistema operativo da programmi buggati che potrebbero accidentalmente fare qualcosa per far cadere o dirottare l'intera macchina. Lo scopo secondario è di limitare i programmi deliberatamente maliziosi a fare lo stesso.