¿La CPU desactiva todas las interrupciones en la CPU local antes de llamar al controlador de interrupciones? ¿O solo deshabilita esa línea de interrupción en particular, que se está sirviendo?¿Puede un controlador de interrupción ser reemplazado por el mismo controlador de interrupción?
x86 deshabilita todas las interrupciones locales (excepto NMI por supuesto) antes de saltar al vector de interrupción. Linux normalmente enmascara la interrupción específica y vuelve a habilitar el resto de las interrupciones (que no están enmascaradas), a menos que se pasen banderas específicas al registro del controlador de interrupciones.
Tenga en cuenta que, si bien esto significa que su manejador de interrupciones no competirá consigo mismo en la misma CPU, puede competir con otras CPU en un sistema SMP/SMT.
¿Podría proporcionar la fuente de la reclamación "x86 deshabilita todas las interrupciones locales ... antes de saltar al vector de interrupción"? Tengo en mi posesión la documentación de la arquitectura Intel 3 volúmenes y la documentación 8259A, también de Intel. No puedo encontrar nada que me diga que las interrupciones se desactivan automáticamente antes de saltar para interrumpir el vector, es decir, al ingresar un ISR (rutina de servicio de interrupción/procedimiento de manejo de interrupciones) – amn
Comportamiento de HW no estricto: la pregunta se hizo en el contexto del kernel de Linux El comportamiento de LAPIC es programable, pero así es como Linux lo programa: todas las interrupciones de la misma prioridad, por lo que uno bloquea al otro, pero Linux en el software vuelve a activar las interrupciones muy rápidamente incluso antes de que se ejecute el manejador de interrupciones. – gby
Posteriormente, encontré una referencia al comportamiento "predeterminado" x86 HW en cuestión, en "Intel 64 y IA-32 Arch. Software Developer's Manual", p. 6-10 vol. 1: "Si un controlador de interrupción o excepción se llama a través de una puerta de interrupción, el procesador borra el indicador de habilitación de interrupción (IF) en el registro EFLAGS para evitar que las interrupciones posteriores interfieran con la ejecución del controlador". Gracias por aclarar las cosas con respecto a Linux. – amn
Normalmente, al menos en x86, una interrupción deshabilita las interrupciones.
Cuando se recibe una interrupción, el hardware hace lo siguiente:
1. Guarde todos los registros en un lugar predeterminado.
2. Establezca el puntero de instrucción (contador de programa AKA) en la dirección del manejador de interrupciones.
3. Establezca el registro que controla las interrupciones en un valor que deshabilite todas (o la mayoría) las interrupciones. Esto evita que otra interrupción interrumpa esta.
Una excepción es NMI (interrupción no enmascarable) que no se puede deshabilitar.
del desarrollo del kernel de Linux ** No es necesario reentratar los controladores de interrupción en Linux. Cuando un controlador de interrupción determinado se está ejecutando, la línea de interrupción correspondiente se enmascara en todos los procesadores, impidiendo que se reciba otra interrupción en la misma línea. Normalmente, todas las demás interrupciones están habilitadas, por lo que se atienden otras interrupciones, pero la línea actual siempre está deshabilitada. En consecuencia, el mismo controlador de interrupción nunca se invoca al mismo tiempo para dar servicio a una interrupción anidada. Esto simplifica enormemente la escritura de su manejador de interrupciones. ** Por lo tanto, solo se enmascara la línea de interrupción actual. – Harman
@Harman, Esto significa que solo se garantiza que la línea de interrupción actual esté enmascarada. Estoy bastante seguro de que la implementación real en x86 es enmascararlos a todos. – ugoren
Sí, está bien. También me gustaría agregar lo que creo que podría ser relevante.
En muchos controladores del mundo real/código de kernel, los manejadores de "bottom-half" (bh) se usan bastante a menudo: tasklets, softirqs. Estos bh se ejecutan en contexto de interrupción y pueden ejecutarse en paralelo con sus manejadores de la mitad superior (th) en SMP (especialmente los softirq's).
Por supuesto, recientemente hay un movimiento (principalmente código migrado desde el proyecto PREEMPT_RT) hacia la línea principal, que básicamente elimina el mecanismo 'bh': todos los manejadores de interrupción se ejecutarán con todas las interrupciones desactivadas. No solo eso, los manejadores se convierten (pueden) convertir a hilos del kernel, estos son los llamados manejadores de interrupción "roscados".
A partir de hoy, la opción aún le queda al desarrollador: puede utilizar el estilo 'th/bh' tradicional o el estilo de subprocesos.
Ref y Detalles:
Citando de Intel posee, sorprendentemente bien escrito "Intel® 64 e IA-32 arquitecturas de software Manual del desarrollador", Volumen 1, páginas 6-10:
Si un manejador de interrupciones o excepción se llama a través una puerta de interrupción, el procesador borra el indicador de habilitación de interrupción (IF) en el registro EFLAGS para evitar que las interrupciones subsiguientes interfieran con la ejecución del controlador. Cuando se llama a un controlador a través de una puerta de trampa , el estado de la bandera IF no cambia.
Solo para que quede claro - sí, efectivamente la CPU "desactiva" todas las interrupciones antes de llamar al manejador de interrupciones.Correctamente descrito, el procesador simplemente activa un indicador que lo hace ignorar todas las solicitudes de interrupción. Excepto las interrupciones no enmascarables y/o sus propias excepciones de software (por favor, que alguien me corrija en esto, no verificado).
Queremos que ISR sea atómico y nadie debería adelantarse al ISR.
Por lo tanto, un ISR deshabilita las interrupciones locales (es decir, la interrupción en el procesador actual) y una vez que el ISR llama a la función ret_from_intr() (es decir, hemos terminado el ISR), las interrupciones se activan nuevamente en el procesador actual.
Si ocurre una interrupción, ahora será servida por el otro procesador (en el sistema SMP) y el ISR relacionado con esa interrupción comenzará a ejecutarse.
En el sistema SMP, también tenemos que incluir el mecanismo de sincronización adecuado (bloqueo de giro) en un ISR.
¿Podría por favor elaborar más su respuesta agregando un poco más de descripción acerca de la solución que proporciona? – abarisone
¿Qué CPU? ¿Qué arquitectura? – eepp
arquitectura x86. – Harman