Articulo de TORO

Aquí les dejo el link a el artículo que expuse en el Congreso de Microelectrónica 2011, Facultad de Ingeniería, Universidad Nacional de La Plata. A grandes rasgos habla del proyecto TORO y de algunas cuentas que hice para mi TP final.

Matias E. Vara
www.torokernel.org

IOAPIC soportado!

Acabo de subir al repositorio GIT las modificaciones necesarias para utilizar el controlador de interrupciones IOAPIC en vez del antiguo 8259 en entornos multicore.

El 8259 es el controlador estandar de interrupciones. Con el surgimiento de los procesadores con más de un core el 8259 fue reemplazado por el IOAPIC y el LAPIC, aunque se preservó por compatibilidad. En general, cada PC tiene un IOAPIC que recibe las IRQ y las dirige a los LAPIC, cada procesador posee uno propio.

El problema con el 8259 es que todas las IRQ son capturadas por el BSP, o procesador de booteo. Esto claramente va encontra de la política de dedicación de recursos seguida por TORO.

De esta forma, en sistemas multicore, cuando se dedica un hardware a un core dado, las IRQ serán capturadas por ese core, descongestionando el procesador de boot.

Matias E. Vara
www.torokernel.org

Importante bug solucionado en la migración de threads

A continuación  describiré brevemente acerca del problema descubierto en la migración de thread y como fue solucionado, no ahondaré en detalles.

En las versiones anteriores de Toro, cuando un thread intentaba crear otro thread remoto, la función ThreadCreate era ejecutada localmente y eran alocadas las estructuras: TThread, TLS y el Stack. Luego la   estructura completa era migrada al core remoto. 

El problema en este procedimiento era que los bloques de memoria TThread, TLS  y Stack ya no eran locales lo cual significa una grave infracción en el modelo NUMA. 

De este modo, se reemplazó la migración de la estrucutura TThread por la migración de un conjunto de parametros tales como: tamaño de pila, puntero al código de ejecución, etc. Así, ThreadCreate es ejecutado remotamente y le son pasados los parámetros guardados en esta estructura. Como antes, se retorna al thread padre el ThreadID del recien nacido.

Se puede observar que mientras la creación de un thread local es instantánea, la creación de un thread remoto involucra dos pasos: primero se migran los parámetros y luego se retorna el identificador de thread.

  

Parcheando GDB 7.3 para debug remoto

Esta vez voy a mostrar como parchear GDB 7.3 con el fin de debuguear de forma remota un kernel corriendo sobre la maquina virtual QEMU. Cuando corremos GDB e intentamos debuguear de forma remota nos retorna el siguiente mensaje de error:

Remote packet too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ...

No estoy muy seguro del origen del problema pero parece que es por el tamaño de los registros. Cuando la máquina virtual salta de modo real a modo long o protegido, los registros cambian su tamaño pero GDB no detecta esta situación. Asi, cuando GDB recibe un paquete más grande que el esperado, tira este error. De esta manera, el parche implementado solo se encarga de incrementar el buffer de recepción cuándo suceden aquellos casos.

El primer paso es bajarse el source de GDB 7.3 desde http://www.gnu.org/s/gdb/download/, no estoy seguro si funciona en versiones más viejas pero supongo que si.

Una vez bajado y descomprimido, editar el archivo gdb-7.3/gdb/remote.c, línea 5693. Aqui nos encontramos con el procedimiento process_g_packet. Ahora será necesario buscar y reemplazar el código original por las siguientes líneas:

/* Further sanity checks, with knowledge of the architecture. */

//if (buf_len > 2 * rsa->sizeof_g_packet)

// error (_("Remote 'g' packet reply is too long: %s"), rs->buf);

if (buf_len > 2 * rsa->sizeof_g_packet)

{

rsa->sizeof_g_packet = buf_len;

for (i = 0; i < gdbarch_num_regs (gdbarch); i++)

{

if (rsa->regs[i].pnum == -1)

continue;

if (rsa->regs[i].offset >= rsa->sizeof_g_packet)

rsa->regs[i].in_g_packet = 0;

else

rsa->regs[i].in_g_packet = 1;

}

}

Finálmente, solo resta compilar:

$ ./configure

$ make

Esto debería ser suficiente para ejecutar GDB correctamente.

Matias E. Vara

www.torokernel.org