Reprise du message précédent :
Pour le kernel, malheureusement je pense que la méthode sera un peu différente sous OpenSuse... A voir si le kernel est déjà compilé avec l'option CONFIG_VFIO_PCI_VGA en faisant un cat /boot/config-3.14-trunk-amd64 | grep VFIO, dans quel cas tu pourras probablement testé le x-vga=on sans passer par la recompilation.
Je confirme que ce n'est pas la solution idéale, il faudra le recompiler pour les prochaines versions.  
En simplifié, voici la méthode que j'utilise :
- prévoir pas mal d'espace disque pour le build (30 Go de mémoire), j'ai déjà rempli mon /...
- les packages nécessaires à la compilation doivent être installés (build-essential au moins, je ne sais plus s'il y en a d'autres).
- cd emplacement_du_build
- apt-get source linux-image-3.14-trunk-amd64 (version à adapter en fonction du kernel qu'on veut).
- cd linux-3.14.1
- cp /boot/config-3.14-trunk-amd64 .config
- vim .config (ou nano si vous préférez).
- modifier les options souhaitées (notamment CONFIG_VFIO_PCI_VGA=y) et sauvegarder.
- télécharger linux-mainline.tar.gz sur le forum Archlinux, l'extraire et copier les patchs i915_314.patch et override_for_missing_acs_capabilities.patch dans votre répertoire des sources. Attention, les derniers patchs sont pour le 3.14, à voir s'ils passent sur une autre version (je dois encore avoir ceux de la 3.13 qui traînent).
- patch -Np1 -i override_for_missing_acs_capabilities.patch (pour ceux qui ont un problème d'acs, à vérifier avec le script lsgroup).
- patch -Np1 -i i915_314.patch (si vous voulez pouvoir utiliser le driver Intel sur l'hôte sans bug graphique).
- le patch fix_memleak.patch ne semble plus nécessaire pour le 3.14.
- export CONCURRENCY_LEVEL=5 (pour utiliser tout vos CPU pour la compilation, nombre de cores +1, ici c'était sur mon core i5, à mettre à 9 je pense pour un core i7).
- fakeroot make-kpkg --append-to-version "-vfio" --revision "1" --initrd kernel_image kernel_headers (de mémoire ça met 30 bonnes minutes sur un core i5 2500).
- ça va générer les .deb, il n'y aura plus qu'à les installer avec dpkg -i.
Je ne suis pas spécialiste en compilation de noyau, il y a peut-être d'autres méthodes mais c'est la plus simple que j'ai trouvé.

merci pour la manip du kernel mais vu mon niveau de competence en linux je vais d abord faire une backup complete avant de tout planter...
j ai tout de meme tester : cat /boot/config-3.14-trunk-amd64 | grep VFIO
et ca me dit "aucun fichier ou dossier de ce type
et le grep VFIO ne donne rien du tout

bon je me repond tout seul en fait il fallait que je remplace par cat /boot/config-3.11.6-4-desktop | grep VFIO
et la ce me dit:
 config_VFIO_IOMMU_TYPE1=m
config_VFIO=m
config_VFIO_PCI=m
config_VFIO_PCI_VGA=y

OpenSuse a activé l'option config_VFIO_PCI_VGA donc tu devrais pouvoir tenter le x-vga=on (à voir si le kernel 3.11 est suffisant et si tu as une version suffisamment récente de qemu). Il n'y a que Debian qui semble à la traîne sur ce coup là (mais bon, c'est leur politique, c'est encore considéré comme experimental).

pour recapituler  
je fait le scrit vfio_bind et le lsgroup  
je les rend executable via chmod  
je redemarre la becanne ensuite je lance les script vfio_bind 1:00:0.0 1:00:0.01 et pareil pour lsgroup  
enfin je cree une vm en ligne de commande avec l option x-vga=on  
c est ca ??

Le script lsgroup ne sert qu'à vérifier comment sont organisés les périphériques dans les groupes iommu, donc ça ne sert à lien de le lancer.
Tu auras peut-être une erreur du type vfio: error opening /dev/vfio/1: Permission denied. Si c'est le cas :

(si tu utilises sudo, sinon en root).
Par contre, tu as quelle version de qemu (qemu-system-x86_64 -version) ? En dessous de 2.0, je ne sais pas si ça fonctionnera.

j ai la version qemu 2.0  
ben ecoute je vais copier les script ce soir et faire la sauvegarde de mon hote  demain et je teste ca mais d apres un ami qui a la meme config que moi il faudrait patcher le kernel pour resoudre un soucis ACS a cause du chipset intel donc je te tiens au jus demain en fin de journee
 

je viens de faire le script vfio et j ai ensuite fait un chmod 755 /usr/bin/vfio-bind
mais en faisant     "sudo chmod g+rw /dev/vfio/1" et "sudo chmod o+rw /dev/vfio/1" ca me dit aucun fichier ou dossier de se type" ...

Ok cool.
Et quand tu fais tout ça, théoriquement, tu peux lancer en primary passthrough?! Ou alors il y a encore d'autres choses compliquées à faire?
 
sinon, tom222, je te confirme que l'erreur que j'ai est bien "Ce périphérique ne peut pas trouver suffisamment de ressources libres pour son fonctionnement (Code 12).
Si vous voulez l'utiliser, vous devrez désactiver l'un des autres périphériques de ce système"

En recherchant l'histoire du code 12, je suis tombé sur ce thread
https://lists.gnu.org/archive/html/ [...] 02417.html
 
D'apres ce que je comprends, ils indiquent dans le premier paragraphe que quand on redémarre la guest, la carte graphique n'est pas reinitialisée. Peut etre que c'est ce qui fait planter la machine pour NHIX...?
 
Ici, un correctif xen pour le code 12 http://lists.xen.org/archives/html [...] 00041.html
 
qqn qui a réussi à corriger le code 12 : http://forums.linuxmint.com/viewto [...] 40#p809107
 
ici peut etre une solution aussi :
https://www.mail-archive.com/qemu-d [...] 74075.html <-EDIT en fait, en relisant ce matin, je ne suis plus trop sur de l'intéret de cet article !

Salut,
 

C'est à faire uniquement si tu as une erreur. Tu as exécuté le script vfio-bind ? Si oui, c'est bizarre, regardes si tu as quelque chose sous /dev/vfio/. Normalement tu devrais avoir un répertoire par groupe IOMMU + un répertoire vfio.
 
Pour le patch ACS, je ne suis pas sûr qu'il soit obligatoire, c'est effectivement si les groupes IOMMU ne sont pas bien organisés (à vérifier avec le script lsgroup) avec les chipset Intel.
 
@adejour : oui, j'avais cherché aussi pour ce code 12, mais je n'ai rien trouvé d'utile. Ce qui est bizarre c'est qu'il n'y a aucun problème sous Linux.
 
J'ai recompilé le kernel Debian 3.14.1 provenant d'experimental avec la méthode que j'ai donné (donc avec l'option config_VFIO_PCI_VGA=y et les patchs i915_314.patch et override_for_missing_acs_capabilities.patch) et je vous reconfirme que ça fonctionne très bien chez moi avec ma VM Windows en primary passthrough (j'en ai profité pour réactiver ma licence, quelle plaie !).
Pour ceux qui utilisent libvirtd, il est possible de passer l'option x-vga=on dans la configuration de la VM. Editer la VM avec virsh edit la_vm.
Modifier la première ligne et ajouter à la fin les commandline :

Pour ceux qui utilisent les commandes qemu directement, je vous laisse trouver la commande adéquate  

hello tom222
bon  j ai essyer ce quetu ma dit et j obtiens ca:
possible problem:
qemu-system-x86_64: -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:62:c4:4c,bus=pci.0,addr=0x3: pci_add_option_rom: failed to find romfile "efi-rtl8139.rom"
qemu-system-x86_64: -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1: Bus 'pcie.0' not found
 
 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1168, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 866, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: early end of file from monitor: possible problem:
qemu-system-x86_64: -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:62:c4:4c,bus=pci.0,addr=0x3: pci_add_option_rom: failed to find romfile "efi-rtl8139.rom"
qemu-system-x86_64: -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1: Bus 'pcie.0' not found
 
une idee??

Salut,
 

 
Pour la première erreur, c'est lié à la carte réseau virtuelle que tu essayes de passer. Essayes avec un autre modèle (par exemple e1000, le plus performant sera virtio, mais il faudra que les drivers soient installés sur ton hôte).
Pour la seconde (Bus 'pcie.0' not found), j'ai oublié que ma conf libvirt est pour un chipset q35. Je suppose que tu utilises le chipset par défaut i440fx (qui ne simule pas de pci express, uniquement du pci).
Donc :
- soit tu changes ton chipset en q35 (il faut éditer avec virsh edit, passer le type de machine en q35, supprimer toutes les lignes <address /> et les blocks <controller /> ).
- soit tu gardes le chipset i440fx (j'avais testé et ça fonctionne) et tu changes ta conf en :

merci j essaye ca cet aprem

bon je viens de regarde le xml de ma vm et j ai la meme chose que toi :

donc  je ne vois pas  ce que je doit
ps: changer j ai regle le soucis de ma carte reseau

Elle est bizarre ta conf.
Essayes avec :
 

Ca y est, j'ai enfin réussi à monter ma config en passthrough !!!
Comme quoi il ne faut pas désespérer.
 
Le but: monter une "steambox virtuelle".
Le principe: faire fonctionner un Windows 7 en VM avec une carte graphique dédiée pour pouvoir lancer des jeux Windows.
Au départ, Windows 7 est déjà installé nativement sur un disque dur dédié (en réalité 2 disques durs dédiés).
Le but est de pouvoir exécuter ce Windows 7 en VM directement sans le réinstaller.
 
Matériel:
- Asus H81I-Plus (carte mère mini-ITX bas de gamme)
- Intel Core i5 4670
- Geforce GTX 760
 
Logiciels:
J'ai installé ArchLinux (première fois de ma vie) juste pour pouvoir suivre ce fameux tutorial:
https://bbs.archlinux.org/viewtopic.php?id=162768
 
Ingrédients:
- Kernel compilé à partir de "linux-mainline" 3.14.1 (cf. tutorial)
- Qemu 2.0 (issu du dépot "testing" de Archlinux, pas besoin de celui du tutorial)
- Seabios du dépôt stable de Archlinux (pas besoin de celui du tutorial)
 
=> Seul le kernel a été recompilé, en effet le kernel de base de Archlinux n'a pas les patches qui vont bien.
 

Une fois ce kernel installé, il faut encore configurer quelques trucs ...
 
Mes paramètres de conf relatifs à la VM:
 
Les options passées au kernel:

Les paramètres pour les modules noyaux mis en jeu:

Réservation de "huge pages" pour les VM (ok j'ai pas compris à quoi ça sert vraiment, mais à priori ça améliore les performances):

Liste des périphériques PCI(E) qui seront affectés à la VM et qui doivent utiliser le driver "vfio" dans l'hôte:

Aperçu du matériel correspondant ... Il s'agit de ma carte graphique Geforce + lapartie audio associée, un contrôleur USB 2.0 et un contrôleur USB 3.0  
J'associe carrément des contrôleurs USB à la VM car ça me parait plus simple que d'associer sélectivement des périphériques USB un par un (clavier, souris, gamepad ...)

Au niveau réseau, j'utilise simplement une interface bridge "br0" gérée par "netctl". Je n'ai qu'une seule carte réseau physique nommée "enp4s0" sur ce PC.
La encore, je ne connaissais pas du tout netctl avant aujourd'hui ... y a plein de chose faciles que je ne maitrise pas sous Arch :-)

Et enfin, le principal, mon script de démarrage de Qemu:
 

On trouve donc dans les paramètres de la ligne de commande (entre autres):
- 1 carte mère de type "Q35", à priori plus adaptée à ce genre de VM que l'ancestrale "440-fx"
- 1 carte réseau paravirtuelle "virtio" attachée au bridge "br0" (nécessite un driver spécial sous Windows)
- 1 bus PCI Express avec:
-- La carte graphique Geforce
-- La partie audio de la Geforce
-- 1 contrôleur disque de type AHCI avec:
--- Un disque dur virtuel SATA en passthrough vers le disque physique /dev/sda
--- Un disque dur virtuel SATA en passthrough vers le disque physique /dev/sdc
-- Le contrôleur USB 3.0
-- Le contrôleur USB 2.0
 
Voila, ça fonctionne bien, j'ai pas tenté de bench ni fait de tuning pour voir si je peux gratter quelques performances ...
J'utilise une souris, un clavier et un gamepad branchés en face avant de ce PC est ils sont bien détectés par la VM. La TV est reliée en HDMI.
Une fois Windows démarré, au premier démarrage, j'ai eu droit au célèbre problème de la carte graphique "Windows a arrêté ce périphérique car il a rencontré un problème (Code 43)".
J'ai lancé "Geforce Experience" qui m'a réinstallé le pilote, et après reboot, tout fonctionnait.
 
Prochaine étape: faire fonctionner la VM avec libvirt
=> convertir le script shell en fichier XML

Bonjour,
 
J'ai recompilé le noyau, ça se fait plutôt bien.
Après cela xvga=on fonctionne : l'affichage se fait bien sur la carte vidéo.
en revanche windows s'initialise mais ne démarre pas complètement (soit ça freeze, soit l'initialisation ne s'arrete jamais, soit ça plante) je n'ai pas cherché à aller plus loin.
 
Donc j'ai repris un peu ton tuto Albator pour voir un peu les différences avec ma config (pour rappel, moi je suis sous Debian Wheezy par contre).
 
Voici les principales différences que j'essaie de corriger :
* J'avais Qemu 1.7, donc il faut que j'installe qemu 2.0.0. Pour ça j'ai pris cette archive : http://wiki.qemu-project.org/downl [...] .0.tar.bz2 et j'essaie de recompiler, mais c'est assez long (en cours). Si vous voyez une méthode plus simple...
* kernel : je l'ai bien patché, la version téléchargée est https://www.kernel.org/pub/linux/ke [...] 4.1.tar.xz
uname -a donne :
Linux JAserver 3.14.1-customkernel #1 SMP Sat Apr 26 16:13:36 CEST 2014 x86_64 GNU/Linux
* options du noyau : je n'avais pas ajouté pcie_acs_override=downstream kvm.ignore_msrs=1
* je n'utilse toujours pas pci-stub, tom222 tu me disais que ce n'était pas la peine?
 
tests à suivre...

Bonjour,
 
@[Albator] : chouette, je me sens moins seul à avoir des résultats ici ! En plus tu as réussi à passer une carte Nvidia (ça donne envie pour les VM Linux) et un Windows installé physiquement. Archlinux est très pratique pour ça (écrire ou récupérer le PKGBUILD qui va bien, un coup de makepkg et c'est fait). Par contre, dans mon cas ma machine tourne h24 et j'ai besoin de stabilité (serveurs) donc ce n'était pas un choix envisageable.
Pour le passage au format libvirtd, ce n'est pas très compliqué, vu qu'on peut passer des commandes qemu directement.
 
@adejour : tu commences à approcher du but ! Effectivement, de mon côté je n'avais pas réussi avec qemu 1.7, j'avais du compilé une version depuis git (1.7.50) pour commencer à avoir des résultats avec x-vga=on. De façon général je déconseille la compilation à la main. Pour garder ton système un minimum propre, je te conseille plutôt que de faire un make install de faire un checkinstall (ça te créera un .deb, qui sera plus facile à nettoyer).
Qemu 2.0 est actuellement dans unstable, dès qu'il sera dans testing il devrait être backporté vers Wheezy je suppose.
 
Autre piste, sur lequel j'ai eu des soucis. Le passage de la partie audio de la carte graphique (le périphérique 01:00.1 en général) peut poser problème.
Pour s'en sortir, il ne faut pas le mettre sur le même bus que la partie graphique :

 
Pour moi, toutes les options particulières (pcie_acs_override, ignore_msrs, emulate_invalid_guest_state, pci-stub, allow_unsafe_interrupts, hugepages...) ne semblent pas utiles, je pense qu'elles sont nécessaires que dans certains cas particuliers, mais à tester.

bon je vien de modifier mon  xml mais au démarrage j ai le droit a ca:

Vu le message d'erreur, il semblerait que tu essayes d'ajouter ta carte graphique deux fois. Si tu la mets dans <qemu:commandline>, il ne faut pas l'ajouter ailleurs.

ben ma config c est celle que j ai poster hier  avec  tes  modifs et la je viens de modifier les comandelines avec

et j ai ca:

Bon ba écoutez, merci à tous, je crois bien que ça marche.. (presque)!
J'ai mis à jour mon aide mémoire/tuto avec tout ce que j'ai fait depuis le début (désolé, c'est plutot en mode brouillon):
http://lite4.framapad.org/p/HW78RN2d2p
 
Par rapport à ce midi, je crois que je n'ai pas changé grand chose.
J'ai réinstallé qemu avec le .deb (checkinstall) et j'ai mis le minimum d'option pour le lancement du kernel (seulement GRUB_CMDLINE_LINUX="intel_iommu=on" ).
 
Maintenant, windows démarre (avec la carte en primary) et se charge completement !! Elle est correctement visualisée dans le gestionnaire de périphérique.
Je n'ai fait aucun test / benchmarck.
 
Par contre, j'ai encore un petit soucis : je n'arrive pas à passer mon clavier et ma clé USB au guest (pour l'instant, j'utilise donc VNC pour les controles, pas très pratique!).
 
Si je passe avec l'option

je reçois l'erreur suivante :  

 
lorsque je bind les controleurs usb, je perds bien le controle de ma souris et de mon clavier sur le host (ce qui me semble plutot positif) mais ensuite en lançant qemu avec l'option

je reçois ce message d'erreur

 
Mes controleurs usb:

 
Matériel usb :

Laisse tombé pour l'instant la partie audio (je ne l'avais volontairement pas mis dans la config que je t'avais donné), mets juste :

J'imagine que c'est parce que le driver du clavier reste chargé ou un truc comme cela ?
A terme je souhaiterais conserver un clavier usb sur le host et mapper le second sur le guest...

 
Et si tu passes uniquement un contrôleur USB (00:1a.0 ou 00:1d.0, à toi de voir sur lequel tes claviers/souris sont connectés) ?
Il me semble que j'avais bricolé dans mon BIOS pour désactiver l'USB 3.0, sinon j'avais des soucis.

alors si j utilise te commandelines j ai cette erreur:

et je viens de lancer le script lsgroup et j ai ca  

 
Pour le Permission denied, voir quelques postes plus haut :

(ce n'est probablement pas le plus propre, il faut sans doute mieux agir au niveau des cgroup_device_acl dans qemu.conf, mais ça devrait te dépanner).

C'est quoi ton proc ?
 
XaT

pour mon proco c est celui la http://ark.intel.com/fr/products/65719/

et meme apres

j ai

Aye.
J'ai retrouvé ces posts : https://bbs.archlinux.org/viewtopic [...] 62768&p=27 sur le sujet.
A priori, ils ont résolu le souci en éditant /etc/libvirt/qemu.conf et en ajoutant :

Il faut redémarrer libvirtd-bin ensuite.
Chez moi ça passe avec uniquement les chmod.

J'ai le même mais en.. K donc pas de VT-D
 
XaT

 
 
Salut, j'ai exactement le même message au lancement de Qemu, et moi aussi c'est sur le contrôleur USB3 ...
Mais à priori il fonctionne correctement dans ma VM ... je pense que ce message est un avertissement, pas une erreur.

emoi cest pas un k haha

a tous pour redemarrer libvirtd il faut   soit faire

ou soit :

 
et maintenant j ai ca en erreur :

j ai essyer avec   ca  mais ca marche pas :
https://bbs.archlinux.org/viewtopic.php?id=177483

 
A d'accord, et finalement, tu as laissé l'usb 3 activé?

bon ma derniere erreur

est apparue depuis que j ai rajouter ca dans qemu.conf

ma vm en pci -assign ne demarais plus nn plus j ai donc passé cette ligne en commentaire et tout est rentre dans l ordre enfin presque ma vm en vfio-pci ne demarre toujours pas  
erreur

bon apres un peu de lecture sur le fofo arch il semblerait que ce ne soit pas  reglable sans  le patch acs car ma cg n est pas seul dans son groupe iommu

Bonjour,
 
****** Pour le problème avec l'usb 3 ******  
 
Alors j'ai fait plusieurs tests en désactivant dans le BIOS ce que je crois être l'USB 3 (xHCI).
Avant désactivation lspci -nn:

Rappel du problème: lorsque je "bindais" les 2 controleurs, clavier et souris étaient toujours fonctionnels sur le host (ce qui n'est pas le comportement attendu). Ce n'était que quand je bindais le xHCI que ceux là étaient inactifs. Et quant à la prise de contrôle par le guest, je n'ai pas réussi, mais peut être qu'il faudra refaire des tests car je ne suis plus sur du ou des controleurs que je transmettais au guest.
 
Après désactivation lspci -nn :

Quand je bind l'un des deux controleurs, j'ai bien un certain nombre de ports USB qui restent actifs, et d'autres qui ne sont plus utilisables sur le host, ce qui est là le résultat attendu.
Et en plus la transmission du controleur au guest fonctionne.
 
-> par contre, c'est dommage de devoir désactiver le USB3 !
 
 
****** Pour le fonctionnement en passthrough ******  
 
Le démarrage fonctionne bien et j'arrive à avoir clavier, souris, carte vidéo fonctionnels, et ça c'est plutôt super!
 
En revanche le redémarrage de la machine (via Windows > Démarrer > Redémarrer) ou via un arret et relancement de la VM donne un beau BSOD avec l'erreur suivante :

(J'ai vérifié, le BSOD apparait aussi sans partage de l'USB)
Le problème a déjà été reporté comme tel sur le forum arch linux ici : https://bbs.archlinux.org/viewtopic [...] 3#p1353453 , même si cela semble être un problème isolé (c'est pas tout le monde qui a eu cette erreur). N'était-ce pas NHiX qui avait un problème lors du redémarrage de son guest?
 
Je n'ai pas encore exploré totalement google pour diagnostiquer d'où ça pourrait venir.
Sinon, heureusement, cela ne créé pas de plantage du host. mais je suis tout de meme obligé pour l'instant de redémarrer mon host pour redémarrer la VM.
 
Tout se passe comme si la carte vidéo n'était pas réinitialisée lors du redémarrage, comme si qemu réinitialisait bien la VM, mais ne prenait pas en compte la problématique de la carte vidéo. -> le changement de l'image BIOS pourrait peut être arranger qqc non ?
 
Sinon, y a t il une ligne de commande à faire sur le host qui permettrait de réinitialiser la carte PCI pour éviter une reboot du host ?
 
Enfin, petite note supplémentaire pour être complet sur le résultats de mes tests : je confirme que mettre "bus=root.1,addr=00.1" pour la partie son empeche le démarrage de windows (bug graphique puis redémarrage) et que mettre à la place "bus=pcie.0" fonctionne.
-> peut être encore qqc à diagnostiquer à l'avenir.