Cette source est une demande de fonctionnalité, et non une capacité confirmée de ZimaOS. Son auteur souhaitait partager une Intel Arc B580 entre plusieurs VM ou conteneurs via SR-IOV et proposait qu’IceWhale fournisse un pilote xe déverrouillé ou corrigé.
La correction actuelle la plus importante concerne la matrice de compatibilité officielle d’Intel. Intel indique désormais que les cartes graphiques discrètes Arc Pro B-Series prennent en charge le SR-IOV, tandis que la famille de cartes graphiques discrètes grand public Arc B-Series est indiquée comme Non prise en charge. Cela signifie qu’il ne faut pas considérer comme un fait établi l’affirmation de la source selon laquelle une B580 grand public serait simplement verrouillée par logiciel et privée d’une fonctionnalité officiellement prise en charge par ailleurs.
Ce que le SR-IOV permettrait
La virtualisation des entrées/sorties à racine unique permet à un périphérique PCIe physique d’exposer plusieurs fonctions virtuelles. Un hyperviseur peut attribuer ces fonctions virtuelles à différents systèmes invités, afin que plusieurs VM partagent le matériel sans qu’une seule VM ne prenne le contrôle exclusif de l’ensemble du périphérique physique.
L’utilisateur à l’origine de la demande avait activé les prérequis habituels de la plateforme
La demande mentionnait VT-d, le décodage Above 4G, la BAR redimensionnable et la prise en charge globale du SR-IOV dans le BIOS. Ces paramètres sont pertinents pour la virtualisation PCIe, mais leur activation ne peut pas créer une prise en charge du SR-IOV pour GPU si la pile GPU/pilote/micrologiciel ne l’expose pas.
Battlemage utilise la nouvelle branche de pilotes xe d’Intel
La publication mettait correctement en évidence une véritable transition architecturale : les cartes graphiques Intel récentes utilisent de plus en plus le pilote noyau xe, plutôt que l’ancienne branche i915 utilisée par de nombreuses expériences communautaires de SR-IOV. On ne peut pas simplement supposer qu’un ancien correctif DKMS pour Alchemist/i915 fonctionnera sur Battlemage.
La matrice actuelle d’Intel n’indique pas le SR-IOV comme pris en charge sur les Arc B-Series grand public
Le tableau actuel d’Intel consacré aux technologies de virtualisation graphique distingue les Arc Pro B-Series, qui prennent en charge le SR-IOV, des cartes graphiques discrètes Arc B-Series grand public, qu’Intel indique comme Non prises en charge.
Consultez la matrice actuelle d’Intel concernant la prise en charge de la virtualisation graphique avant de choisir un GPU spécifiquement pour le SR-IOV.
Les Arc Pro B-Series et l’Arc B580 ne sont pas des catégories de produits interchangeables
Une fonctionnalité documentée pour les Arc Pro B-Series ne doit pas être généralisée à la B580 grand public. Le micrologiciel du produit, la validation, les identifiants de périphérique, la politique du pilote et les garanties de prise en charge peuvent différer, même lorsque les architectures sont apparentées.
Un pilote xe corrigé constituerait une modification non prise en charge du noyau
En l’absence d’une implémentation prise en charge par IceWhale ou Intel, l’injection d’un module xe SR-IOV non officiel peut entraîner des incompatibilités avec l’ABI du noyau, une incompatibilité avec le micrologiciel du GPU, des échecs au démarrage, des problèmes d’attribution aux VM et des difficultés lors des mises à jour. ZimaOS étant un système d’exploitation de type appliance, les modules du noyau non pris en charge sont particulièrement susceptibles d’entrer en conflit avec les mises à jour OTA.
Le passthrough PCIe complet est une autre possibilité
Si un GPU grand public ne peut pas exposer de fonctions virtuelles prises en charge, un hyperviseur peut tout de même être en mesure d’attribuer l’intégralité du GPU à une VM via VFIO/IOMMU. Cela fournit un accès exclusif, plutôt que de partager une seule carte entre plusieurs systèmes invités.
Le partage d’un GPU entre conteneurs Docker ne nécessite pas le SR-IOV de la même manière
Plusieurs conteneurs Docker peuvent souvent partager un même GPU hôte via l’environnement d’exécution graphique/de conteneurs habituel, sans créer de fonctions virtuelles PCIe. Si l’objectif est de faire fonctionner plusieurs conteneurs multimédias ou d’IA, et non plusieurs VM entièrement isolées, le partage du GPU au niveau de l’hôte peut répondre au besoin plus simplement.
La discussion ne contient aucun engagement d’implémentation de la part d’IceWhale
La source ne contient aucune réponse d’un membre de l’équipe annonçant la prise en charge du SR-IOV sur la B580 ni de feuille de route pour un pilote xe corrigé. Considérez-la comme une demande d’utilisateur avancé, et non comme une promesse concernant une future version.
FAQ sur le SR-IOV de l’Arc B580
Intel indique-t-il actuellement que le SR-IOV est pris en charge sur les Arc B-Series grand public ?
Non. Le tableau actuel d’Intel indique que les cartes graphiques discrètes Arc B-Series grand public ne sont pas prises en charge.
Intel indique-t-il que le SR-IOV est pris en charge sur les Arc Pro B-Series ?
Oui. Intel indique actuellement que les cartes graphiques discrètes Arc Pro B-Series prennent en charge le SR-IOV.
Peut-on simplement utiliser un ancien correctif SR-IOV pour i915 sur une B580 ?
Il ne faut pas le supposer. Battlemage utilise la nouvelle branche de pilotes xe, et la source elle-même précise que l’ancien module centré sur i915 ne s’applique pas.
