Les premiers serveurs RISC-V dans le cloud par Scaleway

En 2013, Scaleway était l'un des premiers fournisseurs de cloud à proposer des instances bare metal — serveur physique directement accessible, sans virtualisation — ARM. Onze ans plus tard, nous réitérions en proposant la première offre mondiale de serveurs dédiés RISC-V (prononcé “risc five”).

Mais comment transforme-t-on une architecture d’ISA en un serveur cloud opérationnel ? Découvrez les coulisses de cette première industrielle : du jeu d’instructions aux choix de conception matériel.

L’essor de l'architecture RISC-V

Depuis des décennies, le monde des processeurs est dominé par les architectures CISC (Complex Instruction Set Computing), avec des géants comme Intel et AMD façonnant l'informatique moderne.

Ces architectures, conçues pour exécuter des instructions complexes avec un minimum de lignes de codes, ont propulsé le développement des PC portables et des serveurs. Mais avec l’essor des téléphones portables dans les années 2000, ces processeurs se sont révélés moins adaptés, car ils consomment plus d’énergie et sont moins flexibles pour les nouveaux besoins.

En réponse à ces contraintes, les architectures RISC (Reduced Instruction Set Computing), qui avaient émergées dans les années 1980, ont fait un retour en force. Grâce à des instructions plus simples et plus rapides à exécuter pour le processeur, elles permettent aux développeurs d’optimiser aussi bien la consommation énergétique que les performances. C’est notamment ARM qui a remis le RISC au goût du jour pour des applications grand public, avec des processeurs plus légers et moins gourmands en énergie, adaptés à un usage dans les smartphones et les objets connectés.

Aujourd’hui, RISC-V va encore plus loin en offrant un jeu d’instructions (le langage machine que comprend le processeur) open source. À la différence d’architectures propriétaires comme x86 ou ARM, cette ISA (Instruction Set Architecture) est donc gratuite et accessible à tous, ne nécessite aucune licence, et peut être étendue ou modifiée librement.

La révolution RISC-V et son impact

Lancé en 2010 à l’Université de Berkeley, RISC-V s’inscrit dans la lignée des architectures RISC existantes.

Son principe clé : la modularité du jeu d'instructions. Là où les générations précédentes (RISC I à IV) cherchaient avant tout la performance, RISC-V met l’accent sur la flexibilité. Les concepteurs peuvent ajouter des extensions pour adapter leurs processeurs à un usage précis : calcul vectoriel, traitement d’IA, chiffrement…

Si cette approche permet de concevoir du matériel plus spécialisé, elle a aussi des inconvénients : chaque combinaison d’extensions crée une nouvelle variante du langage machine. Autrement dit, un programme compilé pour une configuration donnée ne fonctionnera pas forcément sur une autre. Cette segmentation inquiète aujourd’hui une partie de la communauté : Linus Torvalds, le créateur de Linux, a, par exemple, critiqué la multiplication des variantes RISC-V.

Pour remédier à cette fragmentation, la fondation RISC-V a introduit des profils standardisés comme RVA23, qui fixent un socle commun d’instructions et d’extensions obligatoires que tout constructeur se doit d'implémenter. Ces profils servent de point d’ancrage pour les développeurs et garantissent qu’un même logiciel puisse s’exécuter sur différents processeurs sans recompilation.

Lorsque l’on dit que RISC-V est open source, il est important de faire la distinction entre l'ISA (le standard), qui est open source, et l'implémentation physique, qui ne l'est pas forcément. En effet, dans la majorité des cas, la conception interne du processeur et son développement (le code HDL) restent propriétaires. Les fabricants gardent ainsi leurs secrets de fabrication et leur modèle économique, tout en respectant la "grammaire" publique imposée par le profil.

Sans ce socle, le système pourrait émuler les instructions manquantes (au prix d'une lenteur extrême) ou serait tout simplement incapable d'exécuter certaines tâches nécessitant un support matériel spécifique, comme la virtualisation.

RISC-V se trouve donc à un tournant : entre la promesse d’une ISA ouverte et personnalisable, et le défi de maintenir un écosystème cohérent et compatible.

Le schéma ci-dessus vous donne un aperçu de la "recette" pour composer une ISA RISC-V : chaque lettre correspond à une extension standard ou spécialisée qui rend cet ISA unique. Prenons par exemple le SiFive U74 utilisé dans la carte de développement HiFive Unmatched. Derrière cette ISA se cache un "RV64GC (RV64IMAFDC)", qui indique une architecture 64 bits (RV64), avec des extensions de multiplication (M), d'instructions atomiques (A), de flottants (F et D), et d'instructions compressées (C). Qui eût cru que choisir un CPU serait si compliqué ?

Quels défis Scaleway a-t-il surmontés pour lancer la première offre Bare Metal RISC-V ?

Au cours des dernières années, l’écosystème RISC-V n’a cessé de croître, et est de plus en plus adopté par les acteurs industriels. RISC-V est désormais supporté par des projets d’envergures comme Android ou le noyau Linux et devrait même être utilisé dans de futures missions de la NASA. Le RISC-V Summit, l’événement phare de l’écosystème, réunit aujourd’hui aussi bien les fondateurs historiques et les acteurs du logiciel libre que les géants du cloud et des semi-conducteurs. On est loin des premières conférences confidentielles !

À la R&D de Scaleway, nous avions pressenti cette effervescence et fait le pari de concevoir la première offre cloud d’instances RISC-V. Mais adapter le matériel RISC-V existant à l’époque aux contraintes du cloud computing s’avéra un défi.

Genèse du projet

Notre objectif était clair : lancer la première offre Bare Metal RISC-V au monde. Le défi ? Utiliser des cartes qui n'étaient pas conçues pour aller dans un datacenter et en faire des serveurs pour proposer la première offre RISC-V du cloud.

Heureusement, chez Scaleway, nous disposions déjà d’une infrastructure complète pour provisionner des serveurs Bare Metal. Il ne restait donc plus qu'à intégrer cette nouvelle architecture dans notre environnement logiciel existant.

Voici comment cette aventure a débuté et comment Scaleway contribue aujourd’hui à la révolution RISC-V.

Identification des SoC et des fabricants

Il convenait d’abord d’évaluer le matériel exploitable. Nous avons donc effectué un premier travail d’identification des acteurs, des fournisseurs et des fabricants. À ce moment-là, les options étaient limitées, mais deux SoC (system-on-a-chip) avaient retenu notre attention :

• TH1520, développé par T‑Head (la branche “semi-conducteur” de Alibaba Group), et équipé d’un processeur Xuantie C910.
• JH7110, développé par StarFive Technology, et équipé d’un processeur SiFive U74.

Pour des raisons de performance, notre choix s’est porté sur le TH1520. Nos benchmarks réalisés sur carte VisionFive 2 ont en effet montré que le TH1520 fournissait une puissance de calcul supérieure au SoC JH7110, un atout indispensable pour des usages en production.

Premiers défis : Booter les cartes

Au moment de nos recherches, il n'existait pas de carte mère type serveur compatible avec un démarrage UEFI adapté aux cartes RISC-V, contrairement aux architectures x86. Nous devions composer avec un processus de démarrage hérité du monde des systèmes embarqués et non-conventionnel pour un datacenter (cf. Figure 3).

L’enjeu était loin d’être trivial : il fallait réussir à faire démarrer les cartes jusqu’à arriver au “user space” Linux. Le schéma ci-dessous illustre les différences et similitudes entre le processus de boot de serveurs type, que l’on retrouve en datacenter, et nos machines RISC-V :

Cependant, l’offre s’enrichit à mesure que l'écosystème RISC-V se développe (ex : la Milk-V Titan, une carte qui propose bien le support UEFI et la virtualisation, mais n’est pas encore disponible. Ce contraste rappelle la situation d'ARM, qui dispose à la fois de processus de boot type serveur (UEFI, GPT) et de démarrages plus légers (ROM + U-Boot) pour les systèmes embarqués.

S’il est facile de démarrer un système d’exploitation en utilisant les images fournies par les fabricants, cela n‘est pour autant pas suffisant pour une intégration dans le monde du cloud : dans ce contexte, il faut également pouvoir démarrer ces machines depuis le réseau. Plusieurs options s'offraient à nous : PXE, iPXE, ou encore UEFI HTTP Boot. Mais nous avons rapidement constaté que seul PXE était fonctionnel. Ni iPXE ni UEFI n'avait, à l’époque, été porté sur cette architecture.

Nous avons donc réussi à démarrer un système sur un système Linux minimal (busybox), puis à lancer une distribution Debian. Cela a ainsi confirmé que ces cartes étaient suffisamment matures pour être exploitées dans une offre.

Nous utilisons deux U-Boot en chaîne : un premier, minimal, figé dans l’e-MMC, qui assure un démarrage stable et immuable, puis un U-Boot dit final, chargé ensuite, que nous pouvons mettre à jour au fil du temps (cf: Phase 2 en bleu de la Figure 3). Cette séparation nous permet d’éviter toute modification involontaire côté client, tout en gardant la capacité de mettre à jour le bootloader.

Au final, le processus de boot complet, non modifiable par le client, est le suivant :

82. Démarrage du serveur.
83. Exécution du code propriétaire minimaliste permettant le chargement du bootloader de premier niveau.
84. Exécution du bootloader de premier niveau (U-Boot SPL), responsable entre autres du chargement du bootloader de second niveau.
85. Exécution du bootloader de second niveau (U-Boot “Proper”), et chargement du bootloader final.

Jusqu’ici, le processus est standard pour un environnement de type embarqué. La partie suivante, elle, est modifiable par un client.

81. Exécution du bootloader final (U-Boot Proper de nouveau, mais configuré différemment), qui vient charger OpenSBI et le noyau Linux.
82. Initialisation de OpenSBI, qui est l'implémentation de référence de la spécification SBI pour l'architecture RISC-V, agissant comme une couche d'abstraction (firmware) entre le matériel et l'OS. Elle permet au noyau de communiquer avec le matériel via une interface standardisée pour exécuter les tâches privilégiées.
83. Lancement du noyau Linux

Nous pouvions maintenant démarrer des serveurs RISC-V ! Il fallait désormais les intégrer dans nos datacenters.

Conception matérielle : du prototype au châssis rackable

Pour comprendre notre défi d'intégration, il faut rappeler comment s'organise physiquement un datacenter :

• Le Rack : une armoire métallique normalisée divisée en unité de taille standard (souvent de 52U de hauteur, où 1U = 1,75 pouce, c’est-à-dire environ 4,45 cm) permettant d’empiler des serveurs, des switchs et des équipements d’alimentation dans un espace optimisé, avec un flux d’air et une alimentation électrique centralisés.
• Le Châssis : un boîtier métallique fixé au rack et contenant directement le matériel (CPU, RAM, disques) ou permettant d’insérer des éléments amovibles (disques ou même serveurs sous forme de lames) .
• Les Lames (ou Blades) : des tiroirs amovibles qui s'insèrent dans le châssis, permettant de remplacer un serveur sans tout éteindre

Notre choix s’est porté sur des lames comportant chacune une clusterboard (une carte mère regroupant des mini-serveurs sous formes de modules amovibles) de 7 serveurs dédiés RISC-V (cf. Figure 4).

Cette solution permet une grande densité de serveurs. En effet, nous sommes en mesure de regrouper 12 lames de 7 serveurs dans un châssis de 5U de hauteur, auquel il faut ajouter 1U pour l’alimentation (cf. Figure 5).

Design des blades et modélisation 3D

Les clusterboards sont au format mini-ITX. Quoique compact et pratique pour le développement, ce format n’est pas adapté pour une intégration directe en datacenter, tout simplement car il ne peut pas être monté dans un rack standard. Pour rendre ces clusterboards exploitables dans un environnement de production, nous avons donc dû faire un travail de conception mécanique complet. L’objectif était de concilier :

• un grand nombre de serveurs par unité de hauteur,
• une gestion électrique maîtrisée, et
• un refroidissement efficace par la circulation de l’air.

À cette fin, nous avons dû concevoir et imprimer en 3D des blades spécifiques pouvant accueillir nos clusterboards. Pour cela, nous avons développé un châssis 5U capable d’accueillir simultanément douze blades (cf. Image 1, plus bas), six à l’avant et six à l’arrière. Cette approche permet d’intégrer nos serveurs RISC-V dans les racks standards du datacenter, tout en maximisant la densité (jusqu’à 84 serveurs dédiés par châssis).

Optimisation énergétique

Pour ce qui est de la consommation énergétique, une clusterboard consomme en moyenne 55W, soit environ 660W pour un châssis entier. En comparaison, un serveur Dell x86 typique (Dell R660) consomme environ 350W pour 1U, ce qui porte la consommation à 1750W pour 5U de serveurs Dell, avec un nombre de serveurs bien inférieur à celui que nous hébergeons dans nos châssis RISC-V. Certes, la puissance de calcul brute d'un processeur x86 de dernière génération reste aujourd'hui bien supérieure. Cependant, l’enjeu de ce comparatif réside dans l’efficience — le ratio entre performance et consommation d’énergie.

Ce design basé sur RISC-V, associé à un design mécanique compact et une faible consommation énergétique, permet une excellente densité de serveurs par rack.

Toutes les blades contenant nos serveurs RISC-V ont été entièrement imprimées en 3D dans nos locaux à Paris, tandis que le châssis a été découpé au laser à partir de plaques de métal. Chaque étape de fabrication a été réalisée en interne, ce qui nous a permis d'ajuster et d’améliorer le design à chaque itération. Le choix du matériau a été important, puisqu'il devait être certifié pour respecter les exigences des datacenters.

Intégration dans l'infrastructure cloud

Défis logiciels : réseau, BMC et U-Boot

Une fois passée l’aspect matériel, l’intégration de ces serveurs RISC-V dans notre offre Elastic Metal a soulevé des défis logiciels, notamment au niveau du réseau. En effet, chaque module devait être isolé pour éviter toute communication possible entre les modules d’une même clusterboard.

Nous avons également dû intégrer une BMC (Board Management Controller), un système qui permet de piloter un serveur à distance (allumage, surveillance, reboot) indépendamment du système d'exploitation. Souvent un élément se trouvant à côté du matériel à surveiller (cf. Image 5). Pour nos besoins, nous avons dû personnaliser OpenBMC (un firmware open-source initialement promu par Meta) pour y intégrer un contrôleur IPMI adapté au matériel. Ce protocole sert d’interface de gestion d'urgence, ce qui permet de contrôler l’alimentation d’un serveur.

Système de provisioning et mise en production

Le dernier défi a consisté à faire passer toutes ces étapes de déploiement à l'échelle. En plus de la fabrication en série des châssis et blades, nous avons mis en place un système de provisioning capable de gérer : le flash des firmwares, le contrôle qualité unitaire, l’enregistrement et la déclaration dans le système de production de Scaleway. Une fois ce processus rodé, les serveurs ont pu quitter l'atelier pour être “rackés” (c'est-à-dire, installés) en datacenter, transformant notre expérimentation R&D en une offre cloud (cf. Image 5).

Lancement de l'offre Bare Metal EM-RV1

Spécifications des EM-RV1

Une fois les premiers serveurs RISC-V intégrés dans notre infrastructure de production, ce qui était une preuve de concept dans le laboratoire de R&D est devenu un véritable produit pour nos clients. Le 29 février 2024, nous avons officiellement lancé notre offre Bare Metal RISC-V avec les EM-RV1 qui proposaient donc :

• Un système basé sur le SoC T-Head 1520 avec :
  • un CPU RISC-V (C910) 4 cœurs à 1,85 GHz
  • un GPU compatible OpenCL/Vulkan
  • un NPU de 4 TOPS pour l'IA
  • 16GB de RAM LPDDR4
  • 128GB de stockage eMMC
• Une connexion réseau 100 Mbit/s
• Des images d’OS correspondant aux standards du cloud : Debian, Ubuntu et Alpine

Disponible depuis la console Scaleway (cf. Image 6) :

• Produit : Elastic Metal
• Zone : Paris 2
• Onglet : Labs

Retour sur le succès et les améliorations

Le succès fut immédiat et les serveurs ont rapidement été en rupture de stock, nous obligeant à en remettre de nouveaux en production.

Mais on ne s’est pas arrêtés là. Nous avons continué à étoffer l'offre en ajoutant Fedora, Kosmos, et même Android 12 grâce à l’équipe Damo Academy (une division d’Alibaba spécialisée dans les processeurs RISC-V et qui a grandement contribué au développement de SoC RISC-V). Pour les plus aventureux, nous avons même rendu disponible l'accès à la console série des serveurs, et donc au bootloader, afin de pouvoir installer les OS les plus exotiques. Besoin d’un petit challenge ? Pourquoi ne pas tenter d’installer Arch Linux directement depuis la console série ?

Et parce qu'on tient à bien faire les choses, on a aussi intégré des fonctionnalités comme Flexible IP et Private Network, permettant à nos clients de personnaliser encore plus leur configuration, avec un contrôle total sur leur réseau et leurs IPs.

Vulnérabilité « GhostWrite » dans les puces C910 RISC-V

Mais le chemin de l'innovation est semé d’obstacles ! Des chercheurs du CISPA Helmholtz Center for Information Security nous ont en effet alertés sur une vulnérabilité, appelée « GhostWrite », dans les puces RISC-V C910 déployées dans notre cloud. Cette vulnérabilité permettait à des attaquants non privilégiés d'effectuer des écritures arbitraires en mémoire via une instruction (vse1024.v), qui fait partie de l’extension vectorielle (V), ce qui peut conduire à une élévation de privilèges jusqu'au niveau 0 (Ring 0).

Il est toutefois important de noter que cette instruction ne fait pas partie de la version officielle de l'extension vectorielle RVV 0.7.1 (draft de l'extension), actuellement utilisée dans nos serveurs. Cette version est une norme intermédiaire qui n'est pas compatible avec la version finale RVV 1.0. Comme cette version (RVV 0.7.1) n’est pratiquement pas utilisée en production, désactiver cette extension vectorielle n’a pas d’impact significatif sur les performances des serveurs.

En réponse, nous avons désactivé par défaut l'extension vectorielle V dans nos serveurs grâce à une mise à jour du kernel, et ce, avant même que la vulnérabilité ne soit rendue publique. Des instructions pour réactiver cette extension sont disponibles dans notre documentation.

Mais concrètement, que peut-on faire sur un serveur RISC-V ?

Tout ce que vous feriez sur une architecture classique ! À la sortie de notre produits un peu plus de 96 % des packages Linux (Debian, Fedora, Ubuntu) sont compatibles RISC-V, aujourd’hui nous sommes autour des 98%, donc serveurs web, bases de données, clusters Kubernetes : tout y passe. Les compilateurs, comme GCC et LLVM, évoluent pour être optimisés pour RISC-V, et bien que le support des images Docker soit encore en cours, il est déjà possible de construire et tester des logiciels sur plusieurs architectures avec une CI/CD multi-archi. Bref, RISC-V vous permet de déployer, tester, et innover avec un écosystème ouvert et en pleine expansion.

Pourquoi, malgré tous ses avantages, l'architecture RISC-V n'est-elle pas encore adoptée massivement ?

Malgré ses atouts, RISC-V reste une technologie jeune face aux géants x86 et ARM installés depuis des décennies. Son adoption se heurte encore à deux freins majeurs :

• Le risque de fragmentation : Comme nous l’avons expliqué plus haut, c'est la crainte principale. Avec un standard trop flexible, le risque est d'avoir des logiciels incompatibles d'un processeur à l'autre.
• La maturité de l'écosystème : Le matériel est là, mais le logiciel doit suivre ! Migrer des applications critiques demande du temps et des investissements lourds pour rattraper le retard d'optimisation. C'est d'ailleurs pour mutualiser ces coûts de développement que des géants (Google, Samsung, Nvidia) se sont unis au sein du projet RISE (RISC-V Software Ecosystem).

Le futur de RISC-V chez Scaleway

Lancer la première offre Bare Metal RISC-V n’était qu’un début.

L’écosystème s’industrialise à toute vitesse, avec l’arrivée de serveurs haute performance comme le SRA3-40 de Sophgo, le support natif par Ubuntu du standard RVA23, ou encore la création de groupe de travail tel que le Data Center SIG au sein de RISC-V International.

En mai 2024, Scaleway a rejoint la fondation RISC-V, confirmant notre engagement envers cette architecture et notre volonté de continuer à développer et proposer des offres innovantes basées sur RISC-V. Nous prenons également régulièrement la parole dans des évènements majeurs comme le RISC-V Summit.

L'ère du RISC-V en datacenter est lancée, et nous sommes fiers d'y contribuer pleinement !

---

Un grand merci à mes collègues de Scaleway Labs — Antoine Blin, Antoine Radet, Cédric Courtaud, et Ludovic Le Frioux — pour leurs conseils avisés et leur relecture attentive de cet article.