Il y a un peu plus d’un an votre serviteur eut cette idée -qui à l’époque me semblait- folle d’implémenter la fonctionnalité boot PVH dans le noyau de notre système d’exploitation favori. En quelques mots, il s’agit de pouvoir démarrer un noyau avec un hyperviseur (QEMU ou Firecracker par exemple) sans passer par la séquence BIOS - bootloader, mais en branchant directement sur un point d’entrée du noyau avec les informations nécessaires au démarrage passées par l’hyperviseur.
Cette fonctionnalité a maintenant été intégrée au code source officiel du noyau en décembre 2024.

Suite à ces travaux, j’ai voulu comprendre pourquoi et comment Colin Perceval réussissait à faire démarrer un noyau FreeBSD en 25ms là où NetBSD ne parvenait pas à descendre sous les 200ms. Cela m’a emmené à porter le pilote MMIO cmdline du sieur Colin, grâce auquel on s’affranchit du bus PCI pour l’attachement des pilotes VirtIO. L’ajout de cette fonctionnalité avait en outre une condition, implémenter un bus “trivial”, pv(4) spécialement dédié à l’attachement des pilotes ne nécessitant pas de bus PCI ou ISA sur machine x86.

Malgré cette nouvelle mécanique, impossible de passer la barre des 150ms, donc afin de comprendre où le noyau “perdait” du temps, j’ai porté une infrastructure de test, tslog(4), encore une fois l’œuvre de Colin.
Grâce à cet outil, je compris que ces précieuses millisecondes étaient utilisées à attendre ! En effet, plusieurs appels à la fonction DELAY(9) sont présents dans le noyau, essentiellement pour :

• calculer la fréquence du CPU
• attendre que le port série n’aie plus de caractères en tampon

J’ai entrepris de me débarrasser de ces délais inutiles en implémentant diverses méthodes de récupération de la fréquence des processeurs, certaines empruntées à FreeBSD et d’autres à OpenBSD. Pour le port série, il a “suffit” d’utiliser une fonction prévue à cet effet.

Quelques petites améliorations plus loin, le noyau était capable de démarrer en moins de 20ms sur une machine i5 de 2015.

Au delà de la simple performance, l’objectif de ce travail de fond était de proposer une version miniature de NetBSD: smolBSD.

892e8f2d0c7bf6fe66a2d86fbd33a86c0e2ed598 L’idée de ce micro-système m’est venue à l’annonce de la sortie de Firecracker, un VMM (gestionnaire de machine virtuel, à ne pas confondre avec l’hyperviseur) Libre issu des laboratoires d’Amazon Web Services qui équipe les infrastructures serverless du cloudiste.
Après plusieurs expériences avec un noyau i386 qui savait déjà démarrer directement via le paramètre -kernel de QEMU, je me suis jeté dans le vide pendant un de mes lives Twitch en annonçant que j’allais essayer d’ajouter cette fonctionnalité au noyau amd64. À ce stade, je ne comprenais pas encore qu’il s’agissait d’implémenter le boot PVH, ni qu’en réalité la raison pour laquelle le noyau i386 savait booter directement provenait de son support de MULTIBOOT, qui n’a jamais trouvé son chemin jusqu’à l’architecture 64 bits. J’ai récemment fini par implémenter PVH également sur i386, ce qui permet désormais de construire un noyau smolBSD pour les deux plateformes.

Préalable aux travaux sur le noyau, le projet smolBSD avait également démarré avec un noyau i386, les premières expériences consistaient à désactiver dans ce dernier les fonctionnalités inutiles dans un environnement virtualisé, expérience qui a donné naissance au programme confkerndev de l’ami Denis, qui permet de désactiver, dans le binaire du noyau, le support des drivers choisis.
smolBSD a ensuite évolué en un projet de création de micro-système d’exploitation basé sur NetBSD pour aujourd’hui proposer plusieurs modèles de microVM, de la simple machine de dépannage au serveur web qui démarre en quelques millisecondes, en passant par un OS NetBSD hybride qui utilise runit au lieu d’init !

À noter pour finir que smolBSD et en particulier son noyau fonctionnent sur QEMU, et plus spécialement son type de machine microvm, ainsi que Firecracker. Quant aux plateformes, au delà des suscitées i386 et amd64, les outils de création d’image de smolBSD permettent de créer des microVMs pour l’architecture ARM aarch64, permettant ainsi l’utilisation de telles machines sur Raspberry Pi, OrangePi ou encore… MacBook M[123] !

– iMil