Reprise du message précédent :
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.

Bonjour à tous,
 
Tout d'abord, un grand merci!
J'ai réussi à monter une configuration en PCI Passthrough.
 
Ça fait un bout de temps que j'avais vu des tuto sur le net, mais ça me semblait compliqué ...
Ce poste m'a donné envie de tenter le coup.
Et comme ça fonctionne je vais partager mon expérience :  
 
Mes références :  
- Ce poste lui même    
- http://edencomputing.com/index.php [...] u-support/
- http://edencomputing.com/index.php [...] an-jessie/
- http://edencomputing.com/index.php [...] ebian-way/
- et surtout ce post : https://bbs.archlinux.org/viewtopic.php?id=162768
 
Matériels :
- CPU = Intel(R) Xeon(R) CPU X3460  @ 2.80GHz
- CM = DELL (Chipset Intel Corporation 5 Series/3400)
- RAM = 8Go
- CG = ATI HD7750
- CG = de la carte mère MGA G200eW WPCM450
- Carte Son Creaive XFI
 
Logiciels :  
- Host : Debian SID (qemu 2.0
- Guest : Win8.1 / Debian SID
 
- Kernel : 3.14.1 recompilé en suivant les instructions du post sur edencomputing.com
Linux eva 3.14.1kvm.1 #1 SMP PREEMPT Sat Apr 26 13:03:29 CEST 2014 x86_64 GNU/Linux
 
Options passées au kernel :  

Je pense en avoir mis beaucoup (trop). En tout cas ça fonctionne.
 
Blacklist du driver de carte graphique qu'on veut utiliser sur la VM (ne pas installer les drivers propriétaires sous Linux):  

 
Utilisation du script vfio-bind (disponible sur le lien du forum archlinux)

 
Gestion du réseau :

 
 
Le script de lancement de la VM sous Win8.1

Ce qui donne :  
- Pci PassThrough pour la CG ATI HD7750
- disque dur en RAW, VirtIO
- clavier USB / souris USB
- carte son "émulée"
- réseau en mode "bridge"
 
Remarque :
Pour l'installation des périphériques virtio (disque dur à l'installation, carte réseau), ne pas oublier de monter l'iso avec les drivers.
-drive file=/data/datastore1/iso/virtio-win-0.1-74.iso,id=virtiocd -device ide-cd,bus=ide.1,drive=virtiocd \
 
J'ai lancé un bench (Heaven Benchmark 4.0) et cela me semble pas mal niveau perf.
Je suis en train de reinstaller un vrai jeu ...
 
Projet :
- Comme [Albator] j'aimerai passer ce script dans une version xml utilisable avec libvirt ...
- Réussir à utiliser le lecteur DVD de l'hôte.
- Faire du pci passthrough pour la carte son.

Ok, merci pour le partage bobdanov !
 
Tu confirmes que tu peux redémarrer la VM sans plantage ?
 
Je vois que tu arrives à passer sans problème tes devices USB. As tu désactivé le USB3/xHCI dans le bios?
 
Si je ne trouve pas de solution rapide, je pense que je vais essayer de reprendre le post edencomputing pour la recompilation du noyau (en gros reprendre tout identique à toi, avec wheezy en base par contre) et voir ce que ça donne.

Salut,
moi ma cartè mère expose 4 contrôleurs USB en tout.

J'associe seulement le 00:14.0 et le 00:1a.0 à la VM, pourtant, après avoir testé, la totalité des ports USB de ma carte mère se retrouvent dans la VM ...
Du coup, je perd la possibilité d'utiliser l'hôte (ce qui dans mon cas n'est pas gênant).
 
Je pense que l'explication est donnée dans le mode d'emploi de la carte mère:

Par contre je ne comprends pas pourquoi j'ai à la fois un chip USB3 "Intel" et un autre USB3 "Asmedia" ...

Pas de soucis lors d'un reboot / arrêt de la VM.
D'ailleurs je n'ai pas encore eu de BSOD  

C'est une CM d'un serveur, pas d'USB3. Réglages par défaut pour tout ce qui est USB.

La recompilation n'est pas trop compliquée, le post explique tout ce qu'il faut faire de manière assez clair. Par contre c'est un peu long.
J'ai gardé le .deb (compilé avec les options de base debian Jessie + activation des options décrites sur le post) je peux te l'uploader quelque part si tu es intéressé.
Par contre prévoir de la place ! il faut environ 10Go sous /usr/src, et du temps

Sinon je pense que je ne pourrais pas passer ma carte son en pci passthrough  
Si j'ai bien compris il est nécessaire de faire le passthrough sur tous les périphériques du groupe ?

car j'ai :

Et je ne veux pas passer la carte RAID et la carte réseau ...  

J'ai aussi ajouter l'option :
-smp 6,sockets=1,cores=6,threads=1 \
et je me retrouve bien avec 6 cores, alors que sans l'option j'en avais qu'un.

Premier test avec un "vrai jeu" : Starcraft 2 ;
Je vois pas la différence entre un Windows natif et la VM  

salut bobdanov pour ton probleme decarte son en vfioje croi que la seule solution soit de patcher ton kernel avec le patch acs override j ai le meme souci pour ma cg et ma carte son

apperrement le kernel 315 serait deja patche

Merci pour l'info, je vais attendre que le 3.15 passe en stable.

par contre tu peut faire du passthroough en pci-assign en tout cas chez moi ca marche

Tu aurais un tuto pci-assign ou un comparatif pci-assign vs vfio-pci ?  
J'ai plus trop envie de toucher vu que pour le moment ça fonctionne  

Merci, c'est super sympa de ta part
En réalité, j'ai déjà recompilé le noyau pour mes premiers tests et ça m'a pris 15 minutes.
C'est probablement parce que j'ai un SSD, j'imagine.
 

A bon?
Tiens je n'ai jamais fait attention à ces histoires de "groupes".

Bonjour,
 

 
Bizarre, je n'ai jamais eu cette erreur. Dans mon log libvirt, mon paramètre chardev est configuré comme ça :

Il faudrait que tu nous montres ton xml quand tu fais ce test pour voir s'il n'y a pas quelque chose d'étrange.
 

 
- Pour libvirt, normalement c'est assez simple (hormis les divers soucis dont on parle avec furhma...).
- Pour le lecteur DVD (bluray chez moi), j'avais essayé mais je n'ai pas trouvé de solution quand il n'y a pas de disque dans le lecteur. Par contre j'ai un lecteur externe USB, donc pas de soucis.
- pour la carte son, c'est celle intégrée à la carte mère ? Si oui, normalement pas de soucis (si pas de problèmes de groupes ACS).
 
@adejour :
Pour l'USB 3, personnellement je m'en passe pour l'instant (pas de périphériques dans cette norme). Tu as essayé l'USB passthrough ? Il faut par contre bien définir le contrôleur (nec-xhci il me semble). Par contre chez moi, ça consomme un peu de CPU, et on ne peut pas passer deux périphériques qui ont le même ID (chez moi deux manettes PS3). J'avais aussi testé en ajoutant une carte USB 2.0 en PCI, car dans l'idéal j'aurais besoin de 3 contrôleurs (un pour ma VM Windows ou Ubuntu, un pour le tuner TNT de ma VM MythTV et un pour l'hôte), mais là j'ai les problèmes d'ACS (et plein d'erreurs DMAR dans les logs).

 
 
si c est le ml de ma vm ue tu veux je l ai poster plu haut mais le revoil

Il faudrait que tu essaies de supprimer tout ce qui est superflu :

(tu ne peux pas utiliser spice en primary passthrough).

tien voici le tuto que je m etais fait  
configuration sous Intel carte graphique amd 7850 (4core ,16 giga de ram)
préparation de la machine qui va accueillir le système d exploitation nécessaire (ici opensuse 12.3 )
installation de Open Suse 12.3  
installation des requis pour la virtualisation (kvm lib-virt )le pont réseau se creera automatiquement
ajout de la ligne intel-IOMMU=on pour activer la fonction vt-d
il faut interdire le chargement des  modules correspondant a la carte graphique (ici "radeon" (ou "nouveau" et "nvidia" )ainsi que "snd_hda_codec_hdmi" ) en les rajoutant au fichier "50-blacklist.conf".  
ensuite via yast on demarre le gestionnaire de machine virtuelle on crée la machine dont on a besoin (windows linux...)
l interface nous demande le type de processeur la quantité de ram ainsi que l espace disque que l on veut dédier a la machine et on la démarre  ainsi que le support d installation (iso  de ton os)
l'installation se déroule normalement  
une fois que l on obtient une installation complète on installe les logiciel dont on a besoin et on clone la machine cela nous permet de la sauvegarder
pour le vga-pass-throug :via le gestionnaire de machine virtuelle on dedie la carte graphique a la vm en l'assignant grâce a son adresse PCI  
on installe les pilote sous windows et on installe également dev-eject c'est un logciel qui va nous permettre de  connaitre l adresse matérielle de la carte graphique sous windows  
on edit le fichier gpedit.msc afin de  "détacher" la carte graphique automatiquement a l'arrêt de windows (sinon on obtient un jolie écran bleu (bsod)au redémarrage)

bon ben je  viens de faire tes modif mais j ai le drois a ca  

Avec le cgroup_device_acl = [ "/dev/vfio/1" ] dans /etc/libvirt/qemu.conf ?

oui

Ok, alors j'ai plus d'idées... Si quelqu'un d'autre à autre chose à te proposer ?
Soit on est passé à côté de quelque chose, soit il y a particularité dans ta conf, soit il y a une spécificité sous OpenSuse.
En tout cas tu as le pci-assign qui fonctionne, c'est déjà ça.
 
Sinon, tu pourrais essayer de prendre le problème à l'envers, essayer en commandes qemu directes en t'inspirant de ce que les autres ont fait.

ben je pense avoir  trouver (enfin un ami qui a la meme config que moi m as dit )que mn soucis est lie au acs et donc comme  je n ai pas  patche  mon kernel (ni avecle patch acs ni avec le patch i915) le soucis vien peut etre de la  
pour rappel ma config :
cm: gigabyte ga-z77x-d3h
proc : intel 3770 non k
cg en passtroug: radeon 7850

Pas convaincu pour les patchs :
- l'i915 : sans, ça devrait juste te provoquer des bugs graphiques sur ton hôte, mais ça ne devrait pas t'empêcher de lancer la VM.
- l'acs override : il est normal d'avoir les deux périphériques 01:00.0 et 01:00.1 (plus le bridge) dans le groupe 1, chez moi c'est comme ça aussi. Donc je ne pense pas que ce soit un problème lié à tes groupes.
Mais ça vaut le coup de tenter. Par contre, je ne peux pas t'aider pour la recompilation sous OpenSuse, je ne connais pas cette distrib (mais tu devrais trouver la procédure sur le net). Par contre, tu as un kernel 3.11 c'est ça ? Ca vaut peut-être le coup d'avoir une version plus récente.
 
Bonne chance !

bon je vins de passr en  kernel 3.14 je peut tenter de recreer une vm de a a z pour le vfio (celle  de test etait une en pci-assign cree a  partir de virt-manager

bon je viens vous donner quelques news  
j ai enfin reussis a demarrer un vm en vfio et au passage j ai fait un vfio-bind avec tout mon groupe 1 pour ne pas avoir le probleme acs  
mon precedent soucis etait que j utilisait un xml creer par virt-manager que j essyait de modifier a la volee donc desole a ceux qui ont perdu du temps pour tenter de m aider   bon le principal est que j ai reussi (surtout grace a ma muse...)
voici le debut de ma nouvelle config  

il me reste a regler quelques parametres mais je suis en bonne voie
 merci a tous

Oui effectivement, ceci explique cela..!
Mais alors pas pratique de tout donner au guest comme tu dis. Pour moi, c'est genant sauf si je désactive l'usb3 (donc au final pas genant tant que je n'ai pas besoin de l'usb3) ou que j'arrive à passer chaque appareil séparément (pas encore fonctionnel chez moi).
 
Je te confirme que moi je n'ai pas ce 3ème controleur. Il ne semble pas être sur le même bus(?) -> 03 au lieu de 00, donc, peut être que tu auras encore quelques ports USB exploitables (à tester). Peut etre que ce sont des ports à connecter sur la carte mere (pour les connecter au boitier par exemple) ou des ports qui sont sur une carte PCI..?
 
Bon sinon, j'ai repris exactement les mêmes options que toi dans la config de grub + pour la compilation du noyau, et j'ai toujours un plantage lors du deuxième démarrage de windows , juste à la fin du chargement et au moment où l'environnement du bureau windows apparait (quand on passe de l'écran de chargement à fond noir, à l'environnement de bureau) -> c'est à ce moment là qu'il y a un changement de résolution.. et alors là j'ai l'écran bleu de la mort..

Finalement bobdanov, je suis intéressé par ta proposition : si tu peux m'uploader le kernel (les 2 .deb : header + image), je regaderai si ça marche. En réalité je suis quasi sur que le pb ne provient pas de là, et ça permettra de vérifier.
bobdanov, tu me confirmes que tu n'as pas patché ton kernel (acs / i915?)
 
Plus ça va plus je me dis que ça peut provenir de la compilation que j'ai faite de qemu car j'ai un peu galéré et je me suis peut être un peu emmelé les pinceaux entre la version wheezy, les backports jessie et les sources de qemu telechargeables en ligne.
Je devrais désinstaller tout et réinstaller une version propre avec la méthode checkinstall de tom222 ou peut etre encore mieux en utilisant les repository de sid et essayer de jongler avec les dépendances (c'est à cela que sert l'apt-pinning dont tu me parlais toma222?)...
 
Et enfin, si tout cela échoue, alors je partirai à regret sur une version non wheezy sans savoir ce qui ne fonctionnait pas.

Le même problème que moi ici : https://bbs.archlinux.org/viewtopic [...] 8#p1403248

Ici aussi avec Xen : http://wiki.xen.org/wiki/Talk:Xen_ [...] d_Adapters : "XL toolstack: Windows 7 DomU works flawlessly on first boot. I have to reset the entire system after DomU shutdown/reboot so DomU will not BSOD. "

Je vais essayer de réinstaller les drivers sur la VM

 
Oui, l'apt pinning sert à ça. En gros on ajoute les différents dépôts dans le sources.list et on joue sur le fichier préférences pour définir les priorités.
Chez moi :

 
Clairement, c'est assez dangereux, on peut facilement tout casser, mais ça dépanne (chez moi j'ai Wheezy, 78 paquets de testing, il faudra d'ailleurs que je fasse le ménage, qemu d'unstable et le kernel d'experimental + celui compilé à la main).
Un outil pratique quand on joue avec ça : apt-show-versions.

Ok, merci pour l'astuce...
 
Bon bon bon..
J'ai désinstallé les drivers AMD qui dataient de octobre 2013.
Et alors là, avec les drivers génériques, ça marche très bien, je redémarre autant de fois que je veux..
Ensuite, j'ai installé les drivers les plus récents. Et là, le premier démarrage a fonctionné, mais le 2eme... Ecran bleu snif..

drap

Non aucuns patchs, juste les modifications expliquées dans le post d'edencomputing
linux-headers-3.14.1kvm.1_3.14.1kvm.1-10.00.Custom_amd64.deb - 6.4 MB
linux-image-3.14.1kvm.1_3.14.1kvm.1-10.00.Custom_amd64.deb - 30.2 MB

Merci bobdanov pour ton kernel compilé
Je testerai avec, afin de voir si ça peut régler mes soucis de plantage au reboot de la VM.

Merci beaucoup, moi aussi je testerai.
 
Pour notre problème NHIX Gneville m'a répondu sur le forum archlinux ( https://bbs.archlinux.org/viewtopic [...] 4#p1410374 )..  Il existe une solution de contournement qui consiste lors de l'arrêt de windows d'"éjecter" la carte graphique et de désactiver le driver radeon. Windows retrouve donc son driver générique (la résolution est dégradée), puis, apres le redémarrage sous ce driver générique, on réactive le driver AMD. Ça peut se faire de manière automatique avec un script, alors c'est mieux que rien et je pourrais m'en contenter, mais on ne sait toujours pas d'où vient le problème :  
 
Hypothèses:
- Un problème avec le driver; le driver ne réinitialise pas correctement la carte au chargement : par exemple tout n'est pas remis a zéro).
 
- Un problème avec la gestion du driver par windows au démarrage ou a l'arrêt.
 
- Un problème avec le BIOS sous qemu : ne serait-ce pas à lui de réinitialiser la carte qui est passée en VGA passthrough, que ce soit au démarrage ((ré)initialisation) ou a l'arret (suspendre le fonctionnement)? Ce n'est pas le cas car quand windows s'arrête, la VM finit par s'arrêter mais la dernière image affichée par la carte reste persistante : la VM est arrêtée mais la carte ne s'éteint pas, et l'écran non plus par le même coup, qui affiche toujours le font bleu avec "arrêt en cours" -> c'est gênant a l'usage car on souhaite que l'écran s'éteigne..  
 
-> Pour ceux pour qui ça fonctionne, l'écran s’éteint-il chez vous après l'arrêt de la VM sous windows ?
 
Sinon, y a t il un moyen plutôt que de passer seulement la carte vidéo 00.01.0, de passer tout le bus (ou quelque chose similaire)? Ce que je me dis c'est que peut-être que l'ordre d'extinction est passé a un niveau inférieur, et que si qemu n'y a pas accès, il ne peut pas arrêter la carte.. C'est con comme idée?

Oui

salut tout le monde
adejour: a tu essayer deveject ?? c est un logiciel en ligne de commande (il existe une version avec interface graphique mais qui ne fonctionnait pas lors de mes tests) qui te donne l adresse materielle de ta carte graphique sous windows ensuite tu creer le script sous gpedit.msc et ta carte se "detachera" a l extinction de la vm (ne marche pas avec un redémarrage)

Non, je n'ai pas essayé ce logiciel, mais dans ce sujet de blog, http://blog.ktz.me/?p=219, ils en utilisent un autre : http://www.nirsoft.net/utils/device_manager_view.html, et je pense que c'est exactement le même principe..

Ok, alors quelque part, c'est une information très intéressante ! A voir maintenant pourquoi ça ne fonctionne pas chez moi : pourquoi la carte reste allumée...
 
 

Après quelques recherches sur google, quelqu'un a eu le même soucis et on lui a proposé de modifier un fichier dans les sources de qemu. Pour lui ça a fonctionné (avec quelques problèmes si il voulait passer 2 cartes à la fois passthrough).
 
https://lists.gnu.org/archive/html/ [...] 00905.html

à suivre..

La personne qui avait un problème avait la carte R9 290X, et moi j'ai la carte R7 260X.. Peut être le même problème..
 
Il semble qu'il puisse y avoir un rapport avec un flag de power management.
Que donne pour vous la commande lspci -vvv pour votre carte concernant le power management?
 
Exemple :

ok, intéressant : moi j'ai un +, et c'est sur ça que se base le bout de code pour la réinitialisation apparemment.

vdev->has_pm_reset passe de true à false selon la valeur de NoSoftRst, et ensuite la réinitialisation a lieu ou pas (vdev->needs_reset = true)

Pas la possibilité de tester maintenant par contre...

Avec cette modification, l'écran s'éteint lors de l'arret de la VM, ce qui est une nouveauté intéressante !
 
En revanche, j'ai toujours le BSOD au second démarrage de windows.
Savez vous pourquoi j'aurais ce NoSoftRst+ ?
-> ce qui semble signifier "pas possible de réinitialiser la carte sans redémarrer".
 
Est ce que ça peut etre un problème de driver?
bobdanov par exemple, ta carte est bien intitulée avec lspci :  "Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750]"
Alors que moi j'ai un vulgaire "ATI Device 6658" alors que avoir un "[Radeon R7 260X]" aurait été plus prometteur (et plus la classe).

Voici ce que j'obtiens avec la commande lspci -vvv sur Ubuntu 14.04