Linux 7.2 : le noyau fait passer RISC-V à 256 cœurs par défaut, Eswin et UltraRISC entrent dans le defconfig

Libéré mi-août 2026, le noyau Linux 7.2 a fait avancer la plateforme RISC-V sur plusieurs fronts d’un coup : le nombre de cœurs supportés par défaut passe de 64 à 256, deux nouvelles familles de SoC (Eswin et UltraRISC) entrent dans la configuration par défaut du noyau, et le Wi-Fi est enfin opérationnel sur les SBC T-Head BeagleV Ahead et Lichee Pi 4a. Au total, plus de vingt contributions arch sont entrées dans cette version — le rythme de développement arch/riscv reste le plus dense de n’importe quelle architecture du noyau. Retour détaillé.

Le contexte de la release

Linus Torvalds a publié Linux 7.2 au début du mois d’août, un cycle qui s’annonce plus chargé que les précédents. Comme il le note lui-même dans son annonce : « La dernière semaine de la release était, encore une fois, plus grosse que je ne l’aurais souhaitée… Les revocations de retard sont nombreuses, les revocations de DRM font figure de code le plus gros, mais il y a beaucoup de petits correctifs partout. Surtout dans les drivers, mais le réseau est resté relativement actif. » Le merge window de 7.3 s’est ouvert immédiatement après, avec 40 pull requests déjà en attente.

Les changements majeurs de cette version, indépendamment de l’architecture, méritent d’être cités pour situer le contexte :

• Scheduler prise en compte du cache : le load balancer co-localise désormais les threads qui partagent les données dans le même domaine de Last Level Cache, réduisant le cache bouncing et les fautes de cache
• Scheduler GPU « Fairer » : inspiré du CFS historique, il remplace le FIFO pour offrir une équité entre clients interactifs et charges lourdes GPU
• USB4STREAM : transfert de paquets bruts d’un hôte à l’autre via câble USB4/Thunderbolt, avec exposés de /dev/tbstreamX exploitables par dd et cat
• Phase IV de la swap table : unification de l’allocation et du comptage du swap anonyme et shmem dans les folios, élimine le tableau statique — un device swap de 1 To économise désormais environ 512 Mo de mémoire

Le cap des 256 cœurs : une demande de SpacemiT

Le changement le plus symbolique est peut-être le plus discret : le défaut de NR_CPUS pour les noyaux RISC-V 64-bit passe de 64 à 256. Cette modification est arrivée après le merge window — ce qui est exceptionnel, mais Linus Torvalds l’a acceptée car elle n’apporte aucun risque de régression réel. La justification donnée dans le commit est directe :

« SpacemiT a déjà produit un serveur RISC-V RVA23 à 80 cœurs, et en remontant encore, le Sophgo Pisces basé sur SG2042 à double socket a 128 cœurs (même s’il a eu des difficultés à obtenir un support mainline). Un NR_CPUS de 64 ne suffit donc plus. Augmenter à 256 pour 64BIT (quand !RISCV_SBI_V01, car les très vieux firmwares ne peuvent pas supporter plus de 64 cœurs). Le nombre a été choisi comme une puissance de deux qui est au moins le double du maximum connu. Je pense que c’est le bon équilibre entre ne pas gaspiller trop de mémoire et ne pas avoir à toucher ce paramètre trop souvent. Ubuntu livre déjà NR_CPUS=512 pour riscv64. Nous avons aussi testé NR_CPUS=256 en interne à ISCAS et constaté un impact sur les performances négligeable et aucun effet pervers. »

Le texte montre deux choses : le nombre n’est pas arbitraire mais pragmatique, et les distributions ne sont plus du tout en retard sur le noyau amont. Ubuntu est déjà à 512, soit le double de ce que 7.2 rend par défaut — l’écart entre le support mainline et la réalité du marché s’amenuce.

Deux familles de SoC dans le defconfig par défaut

Dans la même foulée, deux SoC non documentés sont activés par défaut dans la configuration par défaut RISC-V du noyau :

• Eswin : le defconfig intègre maintenant le support du SoC Eswin, un signal de maturation pour les plateformes comme le SiFive HiFive Premier P550, dont le développeur principal a demandé explicitement que le build par défaut du noyau RISC-V couvre cette puce populaire
• UltraRISC UR-DP1000 : le Kconfig ARCH_ULTRARISC a été activé par défaut pour le defconfig, couvrant l’UR-DP1000 et ses 8 cœurs UltraRISC C100. Le support a été intégré de manière « tardive » après le merge window, mais certains drivers y référaient déjà — le noyau principal n’attend plus que le driver pour exposer la puce

À titre de comparaison : pour un SoC de 8 cœurs C100, la présence par défaut dans le defconfig est un signal fort. Ce n’est plus un SoC de niche qu’il faut configurer à la main ; c’est une puce qu’on retrouve « out of the box » dans n’importe quel build standard du noyau RISC-V.

T-Head TH1520 : le Wi-Fi fonctionne enfin

Un des changements les plus tangibles pour les développeurs embarqués : le Wi-Fi est opérationnel sur les SBC BeagleV Ahead et Lichee Pi 4a, tous deux basés sur le TH1520 d’Alibaba T-Head. Le BeagleV Ahead embarque un module AP6203BM, le Lichee Pi 4a un RTL8723DS. Les changements de device tree de 7.2 activent enfin le Wi-Fi sur les deux, sans patch supplémentaire ni compilation manuelle.

C’est le type de contribution qu’on ne voit jamais dans les annonces, mais qui change concrètement l’expérience de développement : un câble, un kernel mainline, et le Wi-Fi qui marche.

SpacemiT, Microchip, Sophgo, StarFive : un tour de l’arch

L’arch RISC-V a aussi reçu des contributions massives des grands fabricants de SoC. Un tour d’horizon :

• SpacemiT K1 : driver SPI, driver I2C activé, capteur thermique, support MicroSD, eMMC sur Milk-V Jupiter, EEPROM/PCIe/QSPI/USB sur Muse Pi Pro, PMIC/USB3 sur OrangePi R2S, et eMMC/I2C/PCIe/PMIC/QSPI/USB sur OrangePi RV2
• SpacemiT K3 : USB 2.0 PHY, driver ASoC, extension Ziccrse, PWM, PDMA, support d’alimentation I/O du pinctrl
• Microchip : un seul ajout de compatible dt-binding pour l’irqmux sur pic64gx, et une série de correctifs de basse priorité sur pic64gx et beaglev-fire, sans nouveau matériel
• Sophgo SG2042/2044 : corrections de l’adresse de l’unité CPU (les nœuds 10 et plus étaient mal numérotés en décimal), correction de la prise en compte du nombre maximal d’interruptions MSI (16 au lieu de la valeur documentée), et marquage de la cohérence de cache entre le PCIe et le CPU
• StarFive JH8100/JHB100 : renommage du contrôleur d’interruption JH8100 au profit de JHB100 (JH8100 a été abandonné avant production), ajout de l’obligation de cache ops non standard sur JH7110 (le GPU y est DMA incohérent, contrairement aux autres périphériques), binding clint pour JHB100, et support SGMII GMAC

Les nouveaux boards ajoutés : K3-based CoM260-IFX et DeepComputing FML13V05, et Milk-V Duo S (CV18xx).

Fixes correctifs et améliorations de robustesse

La file de correctifs RISC-V de 7.2 est dense et touche les fondations de l’arch :

• get_free_mem_region() : définition de DIRECT_MAP_PHYSMEM_END pour empêcher la fonction de renvoyer des régions inaccessibles dans certains modes de mémoire virtuelle
• kexec_file : correction d’un problème de boot précoce quand la quantité de mémoire physique dépasse la taille du direct map, ce qui est possible dans certains modes
• vmalloc / page fault : sfence.vma de manière inconditionnelle dans le nouveau code de gestion des zones vmalloc, car la présence de Svvptc ne garantit pas que le CPU ne fausse pas de nouveau immédiatement
• ftrace_graph_ret_addr() : correction de l’indicateur de tâche pour s’aligner avec les autres arch
• Accès non alignés : correction de la vérification de performance quand la performance est indiquée sur la ligne de commande du kernel et quand des CPU ont été mis hors ligne puis ramené
• walk_stackframe() : suppression d’un offset d’adresse erroné dans la version sans pointeur de trame
• kfence : correction d’un faux positif use-after-free qui provoquait des avertissements erronés
• cacheinfo : correction d’une fuite mémoire potentielle
• IRQ handler stacks : le kernel panique maintenant tôt au boot si les piles de gestionnaire d’interruption ne peuvent pas être allouées, au lieu de continuer en dépit du bon sens
• Cleanups : alignement de purgatory.[ch] avec x86, standardisation de strscpy() en remplacement des fonctions de chaîne bornées, sysfs_emit() en remplacement de sprintf() pour une meilleure gestion des limites, Kconfirm détectant des infelicités Kconfig

Le tout accompagné de l’ajout de ARCH_HAS_CC_CAN_LINK (le RISC-V a besoin de flags de ligne de commande du compilateur spécifiques par rapport aux autres arch) et de l’implémentation de _THIS_IP_ en assembly RISC-V, jugée moins fragile côté compilateur que la prise de l’adresse d’une étiquette.

Pourquoi l’effort arch RISC-V est le plus dense du noyau

Les changements RISC-V de 7.2 se comptent en dizaines de contributions arch/riscv, alors que les contributions pour d’autres architectures sont plus rares. Ce rythme est le reflet direct de deux dynamiques :

• La diversification du matériel : SpacemiT, T-Head, Microchip, Sophgo, StarFive, Eswin et UltraRISC poussent tous des SoC en mainline, et chaque nouveau SoC demande son lot de bindings, de device trees et de drivers de base
• La montée en puissance du serveur : le passage de 256 cœurs par défaut et le support d’un serveur RVA23 de 80 cœurs montrent que le RISC-V n’est plus perçu comme un « arch de l’architecture qui ne peut pas faire grand-chose » mais comme une plateforme sérieuse pour le datacenter

La comparaison avec x86 et Arm est éloquente : x86_64 maintient NR_CPUS à 8192 en config MAXSMP pour les serveurs de dernière génération, Arm64 est à 512, et LoongArch a déjà passé le cap à 2048. RISC-V à 256, pour une arch qui il y a trois ans n’avait aucun serveur en production, est un pas considérable.