Una instrucción de llamada de supervisor ( SVC ) es una instrucción de hardware utilizada por la familia System/360 de computadoras mainframe de IBM hasta la contemporánea zSeries , Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M y 5990A, y otras; Univac 90/60 , 90/70 y 90/80, y posiblemente otras; Fujitsu M180 (UP) [1] y M200 (MP), y otras; y también se utiliza en el software de emulación de mainframe de código abierto Hercules . Provoca una interrupción para solicitar un servicio del sistema operativo . La rutina del sistema que proporciona el servicio se denomina rutina SVC . SVC es una llamada del sistema .
Los mainframes IBM de las familias System/360 y sucesoras funcionan en uno de dos estados: estado de problema o estado de supervisor y en una de las dieciséis claves de acceso de almacenamiento (0 a 15). En el estado de problema , un gran conjunto de instrucciones de propósito general sin privilegios están disponibles para un programa de usuario. En el estado de supervisor , los programas del sistema pueden utilizar además un pequeño conjunto de instrucciones privilegiadas que generalmente están destinadas a funciones de supervisión. Estas funciones pueden afectar a otros usuarios, otros procesadores o a todo el sistema informático. En la clave de almacenamiento 0, un programa puede acceder a todo el almacenamiento direccionable [a] ; de lo contrario, está limitado a las áreas de almacenamiento con una clave coincidente. Un programa solo puede acceder a funciones de supervisión específicas después de una verificación de autorización exhaustiva por parte del sistema operativo: DEBCHK (SVC 117), TESTAUTH (SVC 119) y, posiblemente, pruebas adicionales. Los programas que no superan cualquiera de estas pruebas se terminan de forma anormal y dejan de procesarse inmediatamente. Algunas de estas pruebas no estaban disponibles en OS/360, pero se agregaron en OS/VS1 , SVS o MVS/370 , pero todas estaban disponibles en MVS/370 o versiones posteriores, y todavía están disponibles hasta el día de hoy.
En OS/VS1 , OS/VS2 (SVS) , MVS/370 y versiones posteriores del SO, la función MODESET (SVC 107) eliminó la necesidad de muchos SVC escritos por el usuario, ya que este SVC del sistema admitía cambios en el modo (estado del problema a estado del supervisor) y la clave (8-15 [usuario] a 0-7 [sistema]) en una sola operación, y muchos SVC escritos por el usuario estaban pensados originalmente para cambios simples de modo y clave, de todos modos, y posteriormente el único requisito especial era que el paso de trabajo estuviera autorizado por APF [b] [c] y que el programa que invocaba MODESET residiera en una concatenación de bibliotecas, todas las cuales se identificaran como autorizadas, y este enfoque seguro estaba completamente bajo el control de la instalación. Este enfoque generalmente simplificaba los controles del usuario sobre la autorización, aunque por ello se requerían algunos cambios simples en la aplicación. En general, las instalaciones de usuario favorecían este enfoque, y por ello la confiabilidad general del sistema mejoraba significativamente.
Aunque las aplicaciones mainframe son típicamente procesos sincrónicos , el sistema operativo en sí es naturalmente asincrónico , aunque el sistema también soporta muchos procesos que son naturalmente sincrónicos . Cuando una aplicación solicita un servicio del sistema que es naturalmente asincrónico , como el procesamiento de entrada/salida, se debe emplear un mecanismo para sincronizar la aplicación y el sistema operativo. Este mecanismo esencial es a través de funciones que están integradas en el sistema operativo, o que son específicamente soportadas por él, incluyendo: WAIT (detener temporalmente el procesamiento de la aplicación hasta que haya ocurrido un evento externo); POST (indicar la ocurrencia de un evento externo para que el procesamiento de la aplicación pueda continuar); y SYNCH (cambiar el modo de procesamiento del sistema—de supervisor a usuario y clave del sistema a clave del usuario—mientras se preserva la integridad del sistema, y realizar sincrónicamente una función en nombre de la aplicación, después de lo cual el procesamiento del supervisor puede continuar).
La siguiente tabla de SVC de OS/360 indica las condiciones bajo las cuales se pueden emplear estas funciones de sincronización.
SVC es una instrucción de dos bytes con el código de operación hexadecimal 0A ; el segundo byte de la instrucción, el número SVC , indica la solicitud específica. [2] El número SVC puede ser cualquier valor entre 0 y 255, y el número SVC particular depende del implementador del sistema operativo, por ejemplo, en MVS de IBM, SVC 3 se utiliza para finalizar un programa, mientras que en los sistemas operativos UNIVAC VS/9 y Fujitsu BS2000, SVC 9 se utilizó para el mismo propósito.
Cuando un programa emite un SVC, se produce una interrupción. El PSW, un registro privilegiado de 8 bytes (en el System 360 y S/370) o 16 bytes (en el z/System), que contiene, entre otras cosas, la dirección actual de la instrucción que se va a ejecutar, el bit de privilegio (1 si es privilegiado) y la clave de almacenamiento, se guarda en una dirección real [d] . Estas son las ubicaciones 32-39 en el 360 y 370; 320-335 en el z/System. Luego, el PSW se carga desde una dirección real [d] diferente ; es 96-103 en el 360 y 370, 448-463 en el z/System. La ejecución se reanuda en la dirección que se cargó en el PSW. Los bits 24-31 del PSW guardado (dirección real [d] 35 en el 360 y 370, 323 en el z/System) contienen el número de llamada del Supervisor.
SVC invoca una función de supervisión, generalmente implementada como una "subrutina cerrada" del controlador de interrupciones SVC del sistema . La información que se pasa hacia y desde las rutinas SVC se transmite en registros de propósito general o en la memoria.
En OS/360 y sucesores , el retorno de una rutina SVC se realiza, para las rutinas SVC de tipo 2, 3 y 4, a través de una invocación SVC 3 (EXIT), y para otros tipos de SVC, mediante la instrucción privilegiada Load PSW (LPSW), que es ejecutada en nombre de la rutina SVC por el despachador del programa de control o el manejador de interrupciones SVC.
En sistemas operativos no desarrollados por IBM, como MUSIC/SP, desarrollado por la Universidad McGill en Montreal, Canadá, para mainframes IBM, y para mainframes no IBM, VS/9 , desarrollado por Univac (a partir del sistema operativo TSOS para las computadoras de la serie RCA Spectra 70 ) para la línea de mainframes UNIVAC Serie 90 , y el sistema operativo B800 (también desarrollado a partir del sistema operativo TSOS) para mainframes Fujitsu, todos utilizan la instrucción LPSW para salir de una llamada de supervisor .
La elección de si se debe hacer que una llamada de supervisor regrese al programa que la llamó directamente a través de una instrucción LPSW o a través de algún otro medio, como una instrucción de retorno de subrutina o una llamada de supervisor en sí, es una cuestión de diseño. No hay una manera obvia "correcta" de hacerlo; puede haber razones para ambos métodos. El uso de una instrucción LPSW para salir de una rutina SVC permite una ejecución más rápida, pero significa que la prueba real de la rutina debe realizarse en una máquina dedicada que ejecute el código como parte de un supervisor de sistema operativo real. Si el código se escribió como una subrutina común, se puede probar de la misma manera que cualquier programa común y potencialmente implementarlo sin tener que modificarlo. También permitiría medir métricas, como cuánto tiempo tardó una rutina de llamada de supervisor en completar su tarea, lo que permitiría el análisis de rutinas que tienen un tiempo de ejecución excesivamente largo (o que son muy rápidas).
En OS/360 y versiones posteriores del sistema operativo, los puntos de entrada de bifurcación y enlace son alternativas a las invocaciones de SVC para algunas rutinas de modo supervisor. En MVS/SP V1R3 y versiones posteriores del sistema operativo, las entradas de Llamada de programa (PC) han aumentado los SVC para las invocaciones de muchas funciones de supervisión por parte de programas autorizados y no autorizados; y algunas funciones solo pueden ser invocadas por entradas de bifurcación o PC, por ejemplo, STARTIO . (Esto también tiene la ventaja de evitar que los sistemas operativos IBM se ejecuten en hardware que no sea IBM).
Los distintos sistemas operativos de IBM tienen poca compatibilidad en los códigos específicos utilizados o en los servicios de supervisión que se pueden invocar. Los sistemas VM/370 y z/VM utilizan la instrucción DIAG de manera similar y dejan el SVC para que lo utilicen los sistemas operativos que se ejecutan en máquinas virtuales. La mayoría de los SVC de OS/360 se han mantenido para programas "heredados", pero algunos SVC se han "ampliado" con el paso del tiempo.
En OS/360 y sistemas posteriores, los números SVC del 0 al 127 aproximadamente están definidos por IBM, y los números del 255 en adelante están disponibles para que los use el personal de programación de sistemas de una instalación. z/OS cambió esto a los números SVC del 0 al 200 aproximadamente para IBM, y del 255 en adelante para la instalación, ya que IBM estaba implementando servicios de sistema adicionales, principalmente en apoyo del cifrado/descifrado, utilizando SVC. Las rutinas SVC deben tener nombres de módulo en un formato específico que comience con IGC.
Por diseño de sistema, el término "deshabilitado" significa deshabilitado para todas las interrupciones excepto las interrupciones de verificación de máquina en sistemas anteriores a MVS/370, y con el "bloqueo local" mantenido, pero no "deshabilitado" para ninguna interrupción en MVS/370 y todos los sistemas posteriores. El primero es una deshabilitación física, el segundo es una deshabilitación lógica, ya que el "bloqueo local" de un espacio de direcciones tiene el mismo impacto dentro de su espacio de direcciones que la deshabilitación física, pero no tiene impacto en otros espacios de direcciones.
OS/360 definió cuatro tipos de rutinas SVC, llamadas del "Tipo 1" al "Tipo 4"; MVS/370 agregó un "Tipo 6" adicional, que es similar al "Tipo 1" excepto que la rutina SVC está físicamente deshabilitada. El "Tipo 5" no fue definido ni implementado. La siguiente información, parte de una tabla para OS/360, aumentada para MVS/370 y sistemas sucesores, da una idea de las consideraciones involucradas en la escritura de una rutina SVC.
Las restricciones de tamaño en las rutinas SVC de tipos 3 y 4 son necesarias porque se cargan en "áreas transitorias" designadas (PLPA en post-MVT) cuando se invocan.
En general, OS/360 no tenía ninguna forma de restringir el uso de SVC. En consecuencia, existían bastantes riesgos no intencionales para la integridad de los datos y del sistema que eran posibles al emplear ciertas secuencias de SVC y otras instrucciones. Se convirtió en una práctica común que los usuarios curiosos intentaran descubrir estos riesgos, pero algunos programadores de sistemas los utilizaban en lugar de desarrollar sus propios SVC escritos por el usuario.
A partir de MVS/370, IBM consideró que era un defecto del producto si un error de diseño del sistema permitía que un programa de aplicación entrara en estado de supervisor sin autorización. Ordenaron que todos los SVC de IBM estuvieran protegidos para cerrar todas las exposiciones de integridad del sistema y de los datos. "Garantizaron" cerrar dichas exposiciones a medida que se descubrieran. En la versión 3.7 de MVS/370 en 1977, prácticamente todas esas exposiciones habían sido identificadas y cerradas, a un costo de 100.000 Informes de análisis de programas autorizados (APAR) y correcciones temporales de programas (PTF) relacionadas. Este fue un logro notable, ya que el "tiempo de funcionamiento" del sistema se midió a partir de entonces en años , en lugar de en días o incluso en horas .