2012-11-16 12 views
5

Qual è lo scopo di un processore che invia un Inter Processor Interrupt a se stesso sull'architettura IA-32?Scopo dell'IPI automatico su IA-32

In base al Manuale dello sviluppatore del software di architettura Intel IA-32, vol. 3, cap. 10.1:

IPI vengono utilizzati per gli interrupt automatici del software, l'inoltro di interruzioni o la pianificazione preventiva .

Ma perché si dovrebbe utilizzare un IPI automatico quando il processore può anche interrompere se stesso con un'istruzione INT? Questa funzione sembra essere ridondante.

risposta

3

Penso che la ragione principale sia la coerenza: se si sta scrivendo un software per un processore multi core e si desidera inviare un interrupt a tutti i core del sistema, si rischia di dover fare un IPI a vicenda core, quindi esegui INT per interrompere il core corrente e, naturalmente, dovrai anche impostare i gestori per entrambe le fonti di interrupt ecc ... È molto più facile inviare IPI a tutti.

Un altro scenario potrebbe essere un sistema multi-core in cui si passa il lavoro oi messaggi a un core "libero" per gestire il carico. Il core "libero" potrebbe essere il core attuale, di nuovo non si vuole avere un caso particolare nel software solo perché si sta inviando un interrupt a se stessi.

+0

Entrambi i motivi sono sbagliati, penso. Ogni processore logico (quindi ogni core) ha il proprio APIC locale. Ciò significa che un IPI di sé viene ricevuto solo da quel particolare core che lo ha inviato.In secondo luogo, esiste una speciale stenografia della destinazione disponibile per inviare un IPI a tutti gli APICS locali in un sistema che include se stesso. – jmiller

+0

Si prega di rileggere, perché ho dato solo una ragione per avere IPI (consistenza) auto e due esempi che illustrano la coerenza. –

2

C'è un altro motivo per l'IPI di sé.

Se si inizializza un gestore SMI, viene prima posizionato su un indirizzo basso nella ram. L'intero stato della CPU viene salvato nella SMI. Tuttavia, tutte le CPU inizialmente utilizzano la stessa area di stato e il nuovo indirizzo trasferito viene impostato manipolando una variabile di stato.

In questo caso, si desidera inviare l'SMI iniziale a una CPU alla volta. Se lo invii a tutti, useranno tutti la stessa area per la memorizzazione dello stato e questo sarà un disastro.

È conveniente utilizzare la stessa routine di inizializzazione per il riposizionamento del gestore SMI per tutte le CPU, quindi è possibile utilizzare l'IPI automatico con il tipo SMI per immettere il codice di trasferimento SMI.

Il BSP può inviare l'IPI SMI a se stesso e quindi un AP alla volta. Saranno quindi trasferiti uno ad uno in aree non conflittuali.

Sono sicuro che ci sono molte altre situazioni in cui è necessario un IPI autonomo. Ogni volta che le CPU condividono un'area critica come nello stato SMI iniziale, l'IPI di sé è motivato per coerenza.

2

Immagino che tu abbia già conosciuto il motivo da quando sono passati 2 anni.

Ma ecco la mia comprensione:

IPI può essere bloccata quando IRQ è disabilitato, esso è mantenuto dal IOAPIC, finché il nucleo destinata riattiva IRQ con un'istruzione sti. Tuttavia un'istruzione int intrappola sempre la CPU in un livello di suoneria inferiore, indipendentemente dal fatto che l'IRQ sia abilitato o meno.

Quindi forse l'IPI di sé è necessario quando il kernel vuole fare qualcosa, ma non ora quando l'IRQ è disabilitato. Quindi, si invia un IPI, facendo in modo che tale interruzione si verifichi non appena l'IRQ su quel core viene riabilitato.