mklinux fait tourner plusieurs noyaux Linux sur la même machine sans hyperviseur
Le 25 août 2026, Cong Wang a publié mklinux v7.0-mk2, première distribution clé en main du concept multi-noyau : plusieurs noyaux Linux indépendants sur une même machine physique, sans hyperviseur ni émulation. Une piste prometteuse pour l’isolation dure — mais pas encore un produit de production.
25 août 2026. Cong Wang annonce mklinux v7.0-mk2, la première version « clé en main » du patchset multi-noyau, basée sur Linux 7.0. Une seule machine. Plusieurs noyaux Linux indépendants tournent en même temps, chacun sur ses propres cœurs, sa propre mémoire et ses propres périphériques. Aucun hyperviseur. Rien n’est émulé, rien n’est piégé.
Le concept courait depuis un an sous forme de patchs à assembler soi-même. Il devient testable d’une commande — et il remet sur la table une question que la virtualisation pensait avoir réglée.
Un hyperviseur en moins, plusieurs noyaux en plus
L’architecture de mklinux tient en une phrase : un noyau hôte possède un pool de CPU, de mémoire et de périphériques PCI, le découpe en instances, puis démarre un noyau « spawn » dans chaque instance via kexec_file_load(). Chaque noyau spawn s’exécute nativement sur ses propres ressources — pas de VM exit, pas de seconde table de pages, pas de modèle de périphériques émulés. La seule chose partagée est ce que vous choisissez de partager.
La comparaison avec les deux outils que tout le monde connaît est instructive. Face aux machines virtuelles, il n’y a plus de couche d’hyperviseur à payer : pas de chemin de sortie de VM, pas de traduction d’adresses à deux niveaux. Face aux conteneurs, les instances ne partagent plus le noyau : un verrou, un panic ou une exploitation dans un noyau ne peut pas atteindre un autre. Cette propriété d’isolation est le cœur de la proposition.
mklinux n’est d’ailleurs pas l’ancien MkLinux — le port de Linux vers les Macintosh PowerPC des années 1990. La ressemblance s’arrête au nom.
La vraie nouveauté : migrer les ressources à chaud
Le détail le plus intéressant du projet n’est pas le découpage initial, mais sa réversibilité. Les instances sont déclarées via un device tree exposé dans /sys/fs/multikernel/. Des overlays de device tree déplacent la mémoire, les CPU et les périphériques entre le pool et les instances en cours d’exécution, sans redémarrage.
Concrètement : une instance peut être éteinte, ses ressources récupérées, puis relancée avec un noyau différent. On peut ainsi changer la version ou la configuration d’un noyau à la volée, sans toucher aux autres. C’est une gestion de ressources d’un genre nouveau — les orchestrateurs pourraient traiter les instances comme des ressources de première classe, sans nouvel appel système.
# L'interface device tree qui déclare les instances multi-noyau
ls /sys/fs/multikernel/
# Le mécanisme de démarrage d'un « spawn kernel » utilisé par mklinux
kexec --load /boot/vmlinuz-spawn --initrd=/boot/initrd-spawn.img --reuse-cmdline
kexec -eDes benchmarks précoces et provocateurs
La publication s’accompagne de quelques chiffres, à prendre pour ce qu’ils sont : des signaux, pas un verdict. Sur un duel 2 cœurs / 2 vCPU, le multi-noyau bat KVM. Sur une configuration 24 cœurs, deux noyaux battent un seul. Deux points de données, sans méthodologie détaillée dans l’annonce — pas de chiffres de bande passante mémoire, pas de décomposition des entrées-sorties.
Le sens de ces chiffres reste cohérent avec la théorie : supprimer l’hyperviseur et la seconde table de pages devrait réduire la surcharge, et le résultat sur 24 cœurs suggère que la contention du scheduler au sein d’un noyau unique sur beaucoup de cœurs est un goulot d’étranglement réel, que le découpage pourrait lever.
Les compromis que personne ne souligne assez
Le projet est honnête sur ses limites, et elles sont structurelles.
- Fragmentation mémoire. Découper la mémoire physique en pools disjoints signifie qu’on ne peut pas rééquilibrer dynamiquement la pression entre charges, comme le ferait un noyau unique avec les cgroups. Une instance affamée à côté d’une instance riche reste bloquée, sauf à démonter et relancer avec un nouvel overlay — l’équivalent d’un redémarrage pour l’instance concernée.
- Affectation de périphériques statique. Chaque noyau reçoit ses périphériques au démarrage. Le hot-plug dépend des pilotes de l’instance et de la volonté de l’hôte de céder le matériel. Ce n’est pas le passthrough médiatisé d’un hyperviseur, avec migration à chaud.
- Interaction avec le firmware. L’hôte initialise le matériel ; les noyaux spawn font un kexec dans un état pré-initialisé. Ça fonctionne pour la plupart des périphériques PCI, mais tout ce qui attend une vraie passation de firmware — certains GPU, certains accélérateurs — peut exiger que l’hôte n’y touche jamais, ce qui lui retire l’accès à ce matériel.
On ne partitionne pas seulement au niveau logiciel : on partitionne au niveau matériel.
À qui ça sert maintenant
Le projet le dit lui-même : l’inclusion dans le noyau principal est incertaine et probablement lointaine. Le patchset touche simultanément la gestion mémoire, l’affectation de périphériques et les chemins de boot — trois zones que les mainteneurs examinent avec une prudence légitime, surtout quand le mécanisme d’overlay ajoute de la complexité au modèle de périphériques.
Les cas d’usage crédibles à court terme sont donc des niches, mais des niches réelles. Un boîtier NFV (network function virtualization) qui veut une latence déterministe pour un noyau de plan de données dédié, pendant qu’un noyau de plan de contrôle s’occupe de la gestion, s’y prête bien. Idem pour le test matériel dans la boucle : on monte un noyau avec les affectations exactes voulues, on le démonte, on reconfigure, on recommence. Pour le développement d’exploits ou de stabilité noyau, un panic dans un noyau spawn n’emporte pas l’hôte — un vrai gain de workflow, même s’il reste de niche.
Verdict
Si vous concevez des appliances spécialisées, du edge telco ou du test noyau, mklinux mérite une évaluation maintenant : l’isolation sans la taxe de l’hyperviseur est une propriété rare, et le mécanisme de migration de ressources par overlays est réellement nouveau. Mais traitez-le comme un laboratoire, pas comme une plateforme : les données de performance sont trop minces et la surface de sécurité de l’hôte n’a pas encore subi la revue qu’elle mérite.
Si vous gérez une flotte de VMs classique, n’y touchez pas encore. La virtualisation éprouvée reste la bonne réponse à vos charges, et le bon signal à suivre ici n’est pas « migrer », mais « observer la discussion sur la liste de diffusion » — c’est là que le débat technique commence, et que la viabilité du concept se décidera.