sergio
8fcc4dc067
El `-global pci-hole64-size=0` del commit anterior NO movía los BAR: verifiqué con `info pci` que OVMF seguía alojando el BAR4 prefetchable 64-bit del virtio-blk en `0xc000000000` (mi Proxmox) o `0x800000000` (la laptop del usuario). El cargador `bootloader_api` 0.11 mapea la memoria física pero no extiende su mapeo hasta la ventana PCI de 64 bits, y `KernelHal::mmio_phys_to_virt` devolvía `phys + offset` a ciegas — un puntero a memoria sin tabla de páginas, al primer registro MMIO leído → #PF. La solución: un mapeador MMIO propio del kernel. - `memory::mmio`: envuelve la tabla L4 activa (vía CR3 + el mapeo de memoria física del cargador) en un `OffsetPageTable`. Su función `mapear(fisica, tam)` abre, para cada página de la región, una entrada en la L4 con `PRESENT | WRITABLE | NO_CACHE | WRITE_THROUGH` — las banderas habituales del MMIO. - Los marcos para tablas intermedias salen del banco DMA del disco (`drivers::disco::asignar_marco_para_tabla`, sin pánico). Se ponen a cero antes de cederlos: las tablas empiezan vacías. - Tratamos `PageAlreadyMapped` y `ParentEntryHugePage` como éxito: la región ya estaba cubierta por el cargador (con páginas 4 KiB o hugepages 2 MiB / 1 GiB) y el acceso ya funciona. Solo abortamos el mapeo si se nos agota la arena DMA. - `KernelHal::mmio_phys_to_virt` llama a `memory::mmio::mapear` antes de devolver el puntero virtual. virtio-drivers lo invoca con la base y el tamaño exactos de cada BAR; el kernel asegura que cada uno sea accesible antes de devolverlo. - `kernel_main` funda el mapeador justo después del heap (paso 4.5), antes del disco. Necesita `physical_memory_offset` para alcanzar la L4 activa. Quito el `-global q35-pcihost.pci-hole64-size=0` que añadí antes: no movía los BAR (verificado con `info pci`) y solo confundía la descripción del fix. Esta solución es la robusta: el kernel sabe mapear sus propios MMIOs y deja de depender del firmware. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
renaser
renaser es un kernel asíncrono de Espacio de Direccionamiento Único
(SASOS), escrito en Rust #![no_std] para x86_64 bare-metal.
Es un sistema operativo disruptivo que rompe por completo con el paradigma POSIX de los años 70: no emula Linux, no usa archivos planos, no usa TTYs ni capas GNU. El aislamiento entre aplicaciones no descansa en la MMU ni en los anillos de privilegio de la CPU, sino en límites matemáticos sobre el bytecode — aislamiento por software (SFI). La interfaz es visual desde el primer microsegundo: el texto es, simplemente, un caso particular del dibujo.
Qué hace, hoy
- Arranca por UEFI y adopta el framebuffer GOP con doble búfer sin parpadeo.
- Se autoempaqueta en una imagen de disco UEFI y se lanza en QEMU.
- Tiene reflejos de fallo: GDT/TSS, IDT y manejadores de excepción; si colapsa, lo dibuja (franja roja de pánico, naranja de memoria agotada).
- Late con el hardware: PIC remapeado, temporizador (PIT) y teclado.
- Gestiona memoria dinámica (heap de 64 MiB, asignador global).
- Ejecuta un reactor asíncrono cooperativo sobre los
Futurenativos de Rust: las interrupciones no conmutan contexto, despiertan tareas. - Rasteriza texto vectorial al vuelo con
fontdue. - Ejecuta un userspace WebAssembly aislado por capacidades (
wasmi): las aplicaciones solo tocan el mundo a través de funciones de host concedidas.
Construir y ejecutar
Requisitos: rustup con toolchain nightly, QEMU y firmware OVMF.
cargo run
Compila el kernel para x86_64-unknown-none, forja la imagen de disco UEFI y
abre QEMU. Ver CLAUDE.md para el resto de comandos y el flujo de la app WASM.
Documentación
| Documento | Contenido |
|---|---|
ARCHITECTURE.md |
la arquitectura del sistema, subsistema a subsistema |
ROADMAP.md |
fases completadas y plan de las siguientes |
CLAUDE.md |
guía operativa: comandos, estructura y convenciones |
Licencia
MPL-2.0