Comment faire fonctionner Intel GVT-g

Bonjour à tous! Intel a offert une excellente solution au problème éternel: "J'ai un ordinateur portable sous Linux et je dois exécuter Windows avec une accélération matérielle, mais je n'ai pas un ordinateur portable lourd avec deux GPU et un refroidissement liquide." En utilisant leur architecture GPU ou autre chose, ils ont réussi à faire en sorte que vous puissiez diviser votre GPU Intel intégré en deux ou plusieurs GPU.

Malheureusement, ce n'est pas si simple ... La documentation est un peu dépassée, et certaines choses se brisent de manière incompréhensible sans raison apparente. Par conséquent, dans cet article, je vais vous expliquer comment configurer une machine virtuelle Windows avec accélération matérielle avec des pilotes rapides virtio et Intel GVT-g.

Pour ce faire, vous aurez besoin d'un GPU plus ou moins moderne ( Note du traducteur : selon la documentation officielle , GVT-g prend en charge les cartes vidéo intégrées, à commencer par la cinquième génération d'Intel Core et la quatrième génération de Xeon ).

Étape 1: configurer le noyau

Vérifiez que vous disposez d'une nouvelle version du noyau. Il semble que les options pour GVT-g aient été incluses avant la version 4.8, mais elles ont définitivement fonctionné de façon pire, donc je recommande d'utiliser le dernier noyau disponible. Si vous êtes assez original pour construire votre noyau, activez ces options . Désactivez également la suppression des ksymes inutilisés, car cette option provoque un bogue .

Vous devez maintenant corriger les arguments de la ligne de commande du noyau. Les options importantes sont:

i915.enable_gvt=1 kvm.ignore_msrs=1 intel_iommu=on i915.enable_guc=0 

Assurez-vous de ne pas remplacer enable_guc=0 par quelque chose qui permettra le chargement de GuC, car cela entraînerait une panne déprimante du pilote i915. Lorsque vous démarrez, accédez à votre environnement de travail et consultez le répertoire /sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/ . S'il n'existe pas, GVT-g ne fonctionne pas. Vérifiez les bûches et / ou pleurez dans l'oreiller.

Pour résoudre le problème, vous pouvez ajouter ces modules à initramfs et en retirer le i915.

Pour une journalisation plus détaillée, vous pouvez définir la variable drm.debug sur une certaine valeur, par exemple, la définir sur 0x02 inclura les messages des pilotes.

Étape 2: créez un ami virtuel

Dans mdev_supported_types vous pouvez trouver un ensemble complet de répertoires. Cet ensemble est déterminé par la quantité de votre mémoire graphique, chaque sous-répertoire correspond à un certain type de GPU virtuel. Le fichier de description qu'il contient contient des informations sur la mémoire et les résolutions prises en charge par ce GPU virtuel. Si la création d'un GPU virtuel avec une grande mémoire à l'aide de la sortie UUID dans le fichier /create vous donne une erreur incompréhensible, alors vous avez plusieurs options. Tout d'abord, allez dans le BIOS et ajoutez de la mémoire vidéo, si possible. Si cela ne fonctionne pas, vous pouvez arrêter votre DM, basculer vers le framebuffer, créer le vGPU souhaité à partir de là, puis revenir à x11. Malheureusement, cette méthode entraîne de nombreux bugs et ne permet pas d'atteindre 60 FPS sur mon ordinateur portable. Une alternative consiste à créer un vGPU plus petit et à utiliser un programme spécial pour augmenter la résolution (CRU). De cette façon, j'ai réussi à atteindre 60 FPS, et il y avait beaucoup moins de bugs et de gels.

Vous pouvez créer vGPU avec cette commande:

 $ echo ${vGPU_UUID} | sudo tee /sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/${vGPU_TYPE}/create 

Et supprimez - ceci:

 $ echo 1 | sudo tee /sys/bus/mdev/devices/${vGPU_UUID}/remove 

Note du traducteur :
Vous pouvez générer un UUID pour vGPU à l'aide de la commande uuidgen sans arguments. La variable $ {vGPU_TYPE} désigne l'un des types répertoriés dans le répertoire mdev_supported_types . Il convient également de noter que le vGPU doit être recréé à chaque redémarrage, il n'est pas enregistré entre les lancements du système d'exploitation.

Étape 3: Cortana vous crie dessus

La prochaine étape est beaucoup mieux prise en charge et chose beaucoup plus lente et douloureuse - l'installation de Windows 10. N'utilisez pas de torrents ou de téléchargements non officiels, ou l'ancienne version de Windows, le lien correct est ici . Il vaut également la peine de télécharger l'image disque avec des pilotes virtio conçus spécifiquement pour accélérer les invités ici . Installez libvirt et virt-manager et exécutez libvirtd :

 # systemctl start libvirtd 

Exécutez virt-manager et assurez-vous que vous êtes connecté à la session système libvirt , pas à la session utilisateur:

Note du traducteur :
Pour que virt-manager puisse se connecter à la session système, vous pouvez l'exécuter en tant que root, mais il est préférable de configurer l'autorisation, par exemple, comme suggéré sur Arch Wiki .

Une fois cela fait, vous pouvez commencer à créer une machine virtuelle. Dans la boîte de dialogue des paramètres, sélectionnez le téléchargement à partir de l'iso-image locale et recherchez l'image téléchargée. Si virt-manager ne le reconnaît pas comme une image Windows 10, sélectionnez-le manuellement, car cela accélérera Windows, car virt-manager dans ce cas fournit certaines interfaces de virtualisation de Microsoft. Créez une image disque ou une partition LVM et configurez-la selon vos besoins. L'interface de configuration avant l'installation est très limitée, donc je démarre généralement l'installation et l'arrête immédiatement pour tout configurer complètement. Voici quelques paramètres:

Note du traducteur :
Malgré le fait que l'article sur la configuration d'une machine virtuelle sur un ordinateur portable, pour une raison quelconque, la question de la distribution du réseau à l'aide d'un adaptateur sans fil est omise. Le fait est que les paramètres réseau par défaut de virt-manager ne conviennent pas à un réseau sans fil. Dans cette situation, la réponse à cette question et ses commentaires peuvent aider. L'auteur suggère également d'utiliser le BIOS au lieu d'UEFI, probablement en raison du fait qu'UEFI nécessite une configuration supplémentaire. De plus, il semble que tianocore ne fonctionne pas encore avec GVT-g, voir bug 935 . Dans mon cas, cependant, la machine virtuelle a démarré, mais Windows n'a pas reconnu le moniteur auquel la carte vidéo intégrée était connectée.

Si vous avez besoin d'un accès rapide au disque ou même de la capacité de la machine virtuelle à compresser l'image disque lors de la suppression des fichiers de la machine virtuelle (sondage TRIM, pour cela, vous devez créer l'image avec la commande qemu-img create -f qcow2 -o preallocation=metadata,lazy_refcounts , l'instruction complète est ici ), configurer le lecteur principal pour utiliser SCSI. Vous aurez besoin de pilotes pour la machine virtuelle pour Windows pour comprendre ce format, alors branchez le disque du pilote virtio précédemment téléchargé pour Windows 10. Par défaut, ils utilisent un IDE, mais vous pouvez accélérer l'installation plusieurs fois et utiliser moins de code hérité si vous utilisez à la place pour les DVD SCSI. Windows prend cela en charge dès le départ. Vous pouvez également:

• Forcer USB à utiliser USB 3.0
• Ajoutez des canaux spice, spice-webdav et qemu-ga pour que le copier-coller et le partage de fichiers entre la machine virtuelle et l'hôte fonctionnent
• Supprimer le matériel virtuel inutilisé
• Basculez la carte vidéo émulée sur QXL et basculez l'affichage sur SPICE, sans écouter le réseau (même en boucle) ( Note du traducteur: sinon la VM se bloque simplement ).
• Basculez le type de puce sur Q35, à côté des paramètres du BIOS.
• Nourrir le chien

Vous pouvez également vous habituer à votre nouvel ami virsh edit . Si vous l'exécutez en utilisant sudo -E , vos variables d'environnement, en particulier EDITOR, seront utilisées pour l'édition, et vous utiliserez la session système libvirt, pas celle utilisateur. Dans ce fichier, par exemple, vous pouvez affecter une correspondance entre les processeurs physiques et virtuels, grâce à laquelle les caches de processeur sont plus cohérents et le planificateur ne se comporte pas si étrangement. Voici un exemple XML que vous pouvez y mettre:

 <vcpu placement='static'>6</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> <vcpupin vcpu='1' cpuset='2'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='7'/> </cputune> <features> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <runtime state='on'/> <synic state='on'/> <stimer state='on'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='3' threads='2'/> </cpu> 

Dans cet extrait de code, je configure la machine virtuelle afin qu'elle voit un processeur avec trois cœurs physiques, chacun ayant deux hyperthreads. De plus, chaque processeur / hyper-thread s'attache à son propre hyper-thread, et cette correspondance ne change pas. Windows Scheduler connaît les hyperthreads et peut les utiliser correctement, sans les compter comme des processeurs distincts. J'active également certaines interfaces Hyper-V qui sont désactivées par défaut et peuvent ne pas avoir d'effet. Si vous utilisez SPICE, vous pouvez ajouter les lignes suivantes pour désactiver la compression, car le réseau externe n'est toujours pas utilisé pour accéder à la machine virtuelle.

 <graphics type='spice'> <listen type='none'/> <image compression='off'/> <jpeg compression='never'/> <zlib compression='never'/> <playback compression='off'/> <streaming mode='off'/> <!-- <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/>     ,     libvirt --> </graphics> 

Vous pouvez maintenant configurer l'ordre de démarrage et démarrer l'installation de Windows. Si vous utilisez un lecteur virtio ou SCSI, Windows ne le trouvera pas. Vous devrez installer le pilote SCSI à partir du lecteur que vous avez connecté, ils se trouvent dans le virtscsi/amd64 . Tout devrait bien se passer et Windows devrait démarrer dans un mode lent et misérable non accéléré. Cortana commencera à vous crier dessus et votre réseau ne fonctionnera pas. Parcourez tout cela sur le bureau. Là, lancez le gestionnaire de périphériques, recherchez tous les périphériques non identifiés et mettez à jour leurs pilotes à partir du disque que vous avez connecté. Vous obtiendrez un Windows légèrement plus rapide.

Étape 4: La partie amusante

Il existe trois façons d'obtenir l'affichage accéléré de la machine virtuelle virtuelle à partir de Windows sur l'écran de votre machine.

• VNC ou un autre protocole d'accès à distance (généralement c'est une très mauvaise solution). Dans cette option, il vous suffit de connecter vGPU et de désactiver tous les autres écrans et cartes vidéo. Réglez également le paramètre display='off' . Vous n'avez pas besoin de l'option igd-opregion présentée plus loin.
• SPICE (je ne pouvais pas atteindre 30 FPS ou plus, mais le transfert général du presse-papiers et des fichiers entre la machine virtuelle et l'hôte fonctionne).
• Interface QEMU intégrée sur GTK + (le presse-papiers partagé et le transfert de fichiers ne fonctionnent pas, mais vous pouvez atteindre 60 FPS avec un patch).

Quoi que vous ayez l'intention d'utiliser, vous devez toujours utiliser la deuxième option pour installer les pilotes du GPU. Les pilotes intégrés de Microsoft ne fonctionnent pas très bien avec GVT-g au moment de la rédaction et cassent souvent. Avant de connecter le vGPU à la machine virtuelle, il est conseillé de télécharger le dernier pilote d'Intel (Apparemment, Intel change son approche de la distribution des pilotes , donc à l'avenir cette étape peut être différente ou pas du tout nécessaire). Assurez-vous maintenant que vous avez créé vGPU. Ouvrez virt-manager et remplacez le bon QXL rapide par un Cirrus lent pour éviter les conflits. Pour connecter vGPU à la machine virtuelle, vous devez ouvrir virsh edit et ajouter le fragment suivant quelque part:

 <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='on'> 

 <address uuid='fff6f017-3417-4ad3-b05e-17ae3e1a4615'/> 

  <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> <rom enabled='no'/> </hostdev> <graphics type='spice'> <listen type='none'/> <image compression='off'/> <jpeg compression='never'/> <zlib compression='never'/> <playback compression='off'/> <streaming mode='off'/> <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/> <!--      , virt-manager     ,        GL. ,      ,   auto. --> </graphics> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.hostdev0.x-igd-opregion=on'/> <!-- libvirt     ,      --> </qemu:commandline> </domain> 

Remarque: Lorsque je fournis un extrait XML comme celui-ci, vous devez l'ajouter à l'actuel si possible, sans rien remplacer.

Vérifiez que vous avez créé des UUID uniques pour tous les vGPU que vous utilisez et que les numéros d'emplacement ne sont en conflit avec aucun des autres périphériques PCI. Si le numéro d'emplacement est après le GPU Cirrus, la machine virtuelle se bloque. Vous pouvez maintenant démarrer la machine virtuelle. Vous devez installer virt-viewer pour voir les deux écrans! Vous pouvez vous connecter à une machine virtuelle à l'aide de la commande

 $ sudo -E virt-viewer --attach 

L'un des affichages sera vide ou non initialisé, le second est un affichage familier, petit et non accéléré. Développez-le et, après avoir entré, installez le pilote du GPU. Si vous avez de la chance, tout fonctionnera immédiatement. Sinon, vous devez éteindre et redémarrer la machine virtuelle (ne pas redémarrer) à l'aide de l'écran de travail. Il est maintenant temps d'ouvrir un terminal et d'exécuter dmesg -w intérieur. Cette commande vous donnera des informations utiles sur les problèmes et la progression globale de l'utilisation de vGPU. Par exemple, au démarrage, KVM se plaindra des MSR bloqués, alors vous devriez obtenir des messages d'accès incorrects lorsque vGPU est initialisé. S'il y en a trop, quelque chose ne va pas.

Si le système démarre, vous pouvez ouvrir les paramètres d'affichage et désactiver l'écran non accéléré. Un écran vierge peut être masqué via le menu Affichage dans virt-viewer . En principe, les machines virtuelles peuvent déjà être utilisées, mais il y a quelques choses qui peuvent être faites pour obtenir une résolution et une vitesse plus élevées.

L'utilitaire CRU est très utile. Vous pouvez jouer avec, et même si vous tombez sur des artefacts graphiques ou même presque sur un écran complètement noir, comme cela s'est avéré pour moi, vous pouvez exécuter le fichier Restart64.exe fourni avec le programme pour redémarrer le sous-système graphique Windows. Personnellement, j'utilise cet utilitaire pour utiliser une résolution plus élevée sur un vGPU plus modeste.

Pour obtenir un excellent 60 FPS, vous devez basculer vers le moniteur QEMU intégré sur GTK + sans prendre en charge un presse-papiers partagé avec l'hôte et des petits pains similaires, ainsi que changer une ligne et reconstruire QEMU. Vous devrez également ajouter un tas d'arguments de ligne de commande désagréables à votre XML. Supprimez l'écran SPICE et la carte graphique Cirrus et off attribut d' display de votre vGPU (libvirt ne prend pas en charge l'affichage sur GTK + et ne permettra pas le démarrage à partir de display='on' sans affichage).

  <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.hostdev0.x-igd-opregion=on'/> <qemu:arg value='-set'/> <qemu:arg value='device.hostdev0.display=on'/> <qemu:arg value='-display'/> <qemu:arg value='gtk,gl=on'/> <qemu:env name='DISPLAY' value=':1'/> <qemu:env name='GDK_SCALE' value='1.0'/> </qemu:commandline> 

La mise à l'échelle de HiDPI sur le moniteur QEMU fonctionne très mal, nous allons donc la désactiver. De plus, vous devrez définir la variable DISPLAY sur le numéro d'affichage que vous utilisez. Pour donner à l'utilisateur exécutant qemu un accès au serveur X, utilisez la commande:

 # xhost si:localuser:nobody 

Si cela ne fonctionne pas, essayez xhost + , mais assurez-vous que vous utilisez un pare-feu. Sinon, essayez une méthode plus sûre.

Avec de telles astuces, vous n'obtiendrez toujours pas au-dessus de 30 FPS à cause de ce stupide bug dans QEMU, si vous ne le corrigez pas en changeant la ligne, comme indiqué dans le lien de commentaire. Assurez-vous que vous construisez uniquement QEMU pour x86-64, sauf si vous avez l'intention de l'utiliser sur une autre plate-forme. J'ai attaché mon PKGBUILD, ce qui ne change pas la ligne, mais ne collecte ici que QEMU pour x86_64 sans prise en charge du stockage réseau.

Si vous vous perdez quelque part en cours de route, vous pouvez voir mon XML actuel pour libvirt .

Liens utiles

Guide de réglage officiel GVT-g
Guide de l'utilisateur Dma-buf
Article sur la configuration d'Intel GVT-g sur le wiki NixOS
Article d'Arch Wiki sur libvirt
Configuration du réseau dans KVM sur l'interface sans fil
Site Web Intel GVT-g

PS: Merci aNNiMON pour son aide dans la relecture du texte de traduction et la correction des erreurs.