Reprise du message précédent :
Aye...
Je n'utilise pas qemu directement, je passe par libvirtd.
VT-D est bien activé ? Tu peux faire un :

Est-ce que VFIO est bien chargé :

voici:

Ok, ça me paraît bon.
Comme tu as fait pour le script vfio-bind, peux-tu créer le script lsgroup suivant et l'exécuter :

(récupéré sur le site Archlinux, je ne me souviens plus de son auteur, désolé pour lui).

toujours la meme erreur...

Je n'ai pas eu beaucoup le temps de fouiller cette apres midi, mais j essaierai d y voir un peu plus clair ce soir.
 
merci pour tes conseils en tout cas, c'était très sympa

Je vois que /sys/kernel/iommu_groups est vide..
Je ne sais pas si cela peut aider...

ok, j'ai corrigé mon probleme en éditant le cfg de grub comme ici :
https://bbs.archlinux.org/viewtopic [...] 9#p1300729
 
avec dmesg | grep iommu j'ai maintenant intel-iommu:enabled
 
et maintenant, je n'ai plus d'erreur..
Je n'ai plus qu'à installer windows maintenant et à voir ce que ça donne !
 
J'essaierai de le faire dans la semaine pour voir ce que cela donne..
 
voici ma ligne de commande :
qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
-smp 6,sockets=1,cores=4,threads=1 \
-bios /usr/share/qemu/bios.bin \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1
 
Et mes notes qui peuvent servir de mini tuto pour ceux qui veulent reproduire ça sur debian wheezy :
http://lite4.framapad.org/p/HW78RN2d2p

Salut adejour
Merci pour ton mini tuto, très sympa !
Avec ta méthode, arrives-tu à rebooter ta VM windows sans que ton hôte plante ? si oui, je vais me rapprocher de ton tuto

 
Salut NHiX.
Pour l'instant, je n'ai pas encore eu le temps d'installer windows.
J'ai simplement validé le fait que je pouvais lancer qemu-kvm avec les bonnes options sans que ça plante, et ça j'en suis déjà très content!
 
Peut être aurais je le temps en 1h ce soir d'essayer.
 
Il me reste donc si je comprends les étapes suivantes :
 
- créer un disque pour ma nouvelle machine virtuelle
   -> as tu en tete les lignes de commandes à utiliser?
 
- configurer correctement les options -m -smp -bios
actuellement j'ai -m 1024 -smp 6,sockets=1,cores=4,threads=1 -bios /usr/share/qemu/bios.bin
* un peut faible pour la mémoire ? je mettrais bien 4096, je vois que toi tu mets 8192, mais ça c'est la totalité de ma mémoire sur le host !
* -smp : que veux dire le 6, que veux dire le 4 et threads (bon je pourrai faire l'effort de chercher aussi si besoin)
* -bios => le bios par défaut est il correct ? j'ai pris /usr/share/qemu/bios.bin pour le test, mais je vois que tu as un autre bios : /home/nhix/VM/seabios.1.7.4
 
- mapper le cdrom (iso) au démarrage de la machine
   -> idem, as tu en tete ce que je dois mettre comme option? dans mes souvenirs c'est -cdrom xxxxx.iso ?
 
dans ton code, je vois que tu mets -vnc 127.0.0.1:8 -> quel est l'intéret de faire ça exactement par rapport à un affichage traditionnel ?
 
ensuite, une fois que windows est installé, tu installe directement les drivers de la carte graphique?

Bonjour à vous deux,
 
@adejour, ah oui, désolé, je n'avais pas vu que tu n'avais pas activé l'iommu au niveau de grub.
Quelques petits conseils pour la suite :
- j'ai vu dans ton tuto que tu as installé Gnome sur ta Debian. Ce n'est pas indispensable si tu n'utilises pas l'hôte (mais si tu débutes et que c'est plus simple pour toi, pourquoi pas). Sur mon hôte, je n'ai aucune interface, je gère tout en ssh.
- pour te simplifier la vie pour la gestion de tes VM, je te conseille d'installer libvirtd-bin. C'est une API qui te permet de gérer tes VM plus simplement que par des commandes Qemu. Une fois installé et que tu as ajouté ton user au groupe libvirt, tu utilises la commande virsh pour manipuler les VM. Quelques exemples :
  - virsh help : te donne les commandes possibles.
  - virsh list : liste les VM démarrées.
  - virsh list --all : liste toutes les VM.
  - virsh start ta_vm : démarre la VM. Il va générer pour toi la ligne qemu (que tu pourras retrouver dans /var/log/libvirt/qemu/*.log).
  - virsh shutdown ta_vm : arrête proprement la VM si elle supporte l'ACPI.
  - virsh destroy ta_vm : arrête brutalement la VM (à éviter).
  - virsh edit ta_vm : édite la configuration de la VM. Elle est défini au format XML, et il vaut mieux connaître un peu VI.
  - ...
Ca te permet aussi t'utiliser virt-manager (une interface graphique, par contre je ne sais pas si elle existe sous Windows) et les VM ne sont plus lancées par root.
- si tu ne t'en sors pas avec la méthode VFIO, je te conseille d'essayer la méthode pci-assign, plus simple dans un premier temps, même si elle a des inconvénients. Pour ça, soit tu changes vfio-pci par pci-assign dans ta commande qemu, soit tu ne charges pas vfio avant de lancer ta VM via libvirt, soit tu ajoutes <driver name='kvm'/> dans la partie hostdev de la définition XML de ta VM.
- pour l'installation de Windows, il vaut mieux l'installer d'abord sans la carte passée en passthrough, puis l'ajouter après et installer les drivers.
- une fois tout installé, pour les perfs, je te conseille les drivers virtio, notamment pour les disques. Voir les échanges que nous avons eu avec NHiX sur le sujet.
 
En espérant que ça puisse t'aider.

gnome oui tu as raison, mais pratique dans un premier temps.
ce  qui est bien c'est qu avec mon tuto, c'est reproductible et ça me prend  20-30 minutes de tout refaire de zéros (install de debian inclus)
merci pour l'astuce virsh que j'utiliserai surement par la suite
 
 
Mmm..
j'avance, mais que cela soit avec virtio ou en sata, j'ai un problème juste apres la copie des fichiers d'installation windows. En fait la copie (qui est la première étape de l'installation) est presque instantanée et ensuite, j'ai un message d'erreur sous virtio (impossible de trouver les fichiers), qqc comme ça.
voici la commande lancée :  
 
* launch & install windows without the PCI card and with virtio

 
ou
 
* launch & install windows without the PCI card and without virtio (sata)

Je sais toma222, tu vas me dire d utiliser virsh ou virtmanager !

Est ce que ca peut etre le bios par defaut qu'il faut changer?

Non, c'est tout à fait possible avec qemu    
Je dirais qu'il faut installer Windows d'abord sans virtio (les drivers n'étant pas gérés dans l'install), en IDE (je n'ai plus la syntaxe exacte via qemu). Ca sera assez long mais ça devrait passer, et ensuite tu pourras installer les drivers virtio et modifier ton disque.
Ca fait longtemps que je n'ai pas réinstallé mon Windows, donc je ne saurais pas beaucoup t'aider là-dessus, mais peut-être que NHiX le pourra ?

oui, ok, au pire je vais essayer cela...

je télécharge la version anglaise pour voir le message en anglais et faire une petite recherche

Pour l'installation de ton Windows, celle-ci doit se faire effectivement avec ton ou tes disques en IDE, sans PCI Passthrough. Il s'installera normalement sans soucis, testé avec Windows 7 x64 Fam et Windows x64 8.1 Pro

 
Ou sinon il faut simplement donner 2 iso lors de l'installation de Windows (comme si on avait 2 lecteurs): 1 avec l'iso de Windows et 1 avec les drivers virtio.
Au démarrage Windows ne voit pas de disque dur, on choisi de charger un pilote et on navigue sur le "2ème" lecteur pour y trouver les pilotes. Et hop, l'installation de Windows se fait directement avec les drivers virtio pour le disque dur, la carte réseau et la mémoire si besoin.
Je procède toujours ainsi pour gagner du temps.

C'est ce que je fais, mais chez moi, et bien l'install finit par m'afficher un message d'erreur..
 

Et là, c'est soit infiniment long, soit ca plante, ce qui revient au même (le guest ne répond pas, voire fait planter mon host)
 
Ces 2 méthodes donnent le même freeze :

ou

ok ok ok...
Bon, ca ne fonctionne toujours pas avec virtio mais c'est bon en sata (ou plutot, ça fait 20 minutes que c'est bloqué sur extraction des fichiers, mais il parait qu'il faut attendre...)..
 
Pourquoi ça ne marchait pas vous allez me demander? En réalité, vous allez rire (ou pas ), je travaillait dans ~/ en root, c'est à dire dans /home/root et je ne savais pas que ce chemin fait parti de la partition racine / et non pas la partition /home
bref, j'avais saturé ma partition / (de 10Go) en créant mon disque virtuel de 30 Go (et d'où certainement le freeze de la mort ).

/home/root ? /root tu veux dire ?
 
XaT

j'utilisais ~/ et comme j'étais loggé en root, il me semble que sur ma machine :
"~/" = "/home/root"
et que ce répertoire doit en fait être mappé sur la partition communément appelée "root" c'est à dire point de mapping "/"
 
En gros j'ai une partition "root" de 10 Go pour "/" qui doit contenir aussi /home/root
et une partition "home" de 100 Go qui doit contenir /home/* sauf /home/root
 
une truc comme ça j'imagine..
 
En tout cas quand j'utilisais ~/ cela saturait mon disque

J'ai réussi à installer Windows en sata ça prend environ 1h sur mon ordi.
Ensuite j'ai redémarré plusieurs fois sans problème.
 
Les étapes suivantes :
- démarrer en déclarant simplement virtio + le cdrom de virtio
- installer les drivers
- redémarrer
-> là toujours ok
 
- ensuite, j'ai démarré en ajoutant ma carte graphique.
- et là windows me dit que j'ai changé trop de composants matériels et que ma version n'est pas authentique.
-> et là impossible d'aller sur internet pour télécharger les drivers, IE plante à toute tentative de téléchargement !
 
Je pensais qu'on avait 8 jours pour activer windows non?
C'est un peu gênant car j'ai une licence, mais je crois que le nombre d'activations est limité, alors je ne vais pas le faire avant d'être sûr de mon coup.
 
Sinon, l'autre option c'est peut être de réinstaller windows mais en déclarant le maximum de matériel (carte vidéo + mettre un disque non utilisé en virtio, même si je pense que pour windows, ce qui importe c'est le matériel du disque dur principal.)
 
Sinon, c'est dommage que j'ai cette erreur lors de l'installation de windows avec virtio activé.
J'explique ce qu'il se passe :  
Avec virtio, mes disques sont bien détectés, et je peux les formater.
Ensuite il y a la première étape de copie, qui est quasi instantanée.
Puis l'étape "Expanding Windows Files" et là instantanément une erreur
du type (je ne peux pas présentement vérifier le message exact) : "Windows cannot install required files. The file does not exist. Make sure all files required for installation are available, and restart the installation."
 
Je me dis que lors de cette étape "décompression des fichiers" soit effectivement il y a une erreur d'écriture sur le disque virtuel,
soit il recherche à nouveau lors de la décompression les drivers virtio et il ne les trouve pas.
Même si je penche pour la première solution.
 
Peut être qu'apres le formatage, je devrais redémarrer puis lancer la console de réparation pour voir si les accès disques sont corrects...
Bizarre en tout cas.

salut adejour es tu sur de ton iso ou de ton dvd d installation  ?? car j avais deja eu ce probleme auparavant  
ce que je te conseil c est de verifier l integrité de ton support d installation (controle md5 si il s agit d une iso )  

Salut furhma.
Je suis sur de mon iso dans le sens où cela fonctionne en sata mais pas avec virtio

hum... et le pilotes virtio c est quelle version??

furhma, pour les drivers, il s'agit de cette version :
http://alt.fedoraproject.org/pub/a [...] 0.1-74.iso

ok j ai la meme version je suis en win 7 64b et je n ai aucun soucis lors de l installation  
essaye avec une autre iso car ormis cela je ne vois pas d ou viendrais le soucis

Je vais donc essayer avec un autre cd (windows 7 normal et non le SP1) (Il s'agit de windows 7 familial 64b)
 
Et si ça ne marche pas je testerai cela :

ok tiens nous au jus  

salut adejour çà va ??
bon j ai une autre solution pour toi si tu n'y arrive toujours pas  
tu installe ta vm avec les pilote sata  
un fois l installe complète tu éteint ta vm tu rajoute un disque virtio a ta vm en laissant le premier en sata et tu monte également un deuxième lecteur virtuel avec ton iso virtio 1.72 tu démarre
win va te dire nouveau matériel détecté donc la tu installe tes pilote redhat scsi virtio un fois cela fait tu éteint une nouvelle fois ta vm et tu change ton premier disque sata en virtio et tu démarre et normalement c est bon

@furhma
 
oui, c'est exactement ce que j'ai fait et ça marche.
Donc c'est la solution de replis, mais ça m'énerve toujours de ne pas comprendre pourquoi ça ne marche pas alors je vais creuser la question si j'ai le temps.
 
Sinon, donc j'ai réussi à démarrer windows, pour l'instant, ma carte video est bien visible, avec les bons identifiants matériels, mais le périphérique n'est pas correctement démarré.

qu est ce que tu entend par " le périphérique n'est pas correctement démarré. "??

il y a un triangle jaune a coté du périphérique dans le gestionnaire de périphérique..
Je vais essayer d'installer toutes les mises à jour windows et voir ce que ça donne ensuite

Bonjour adejour,
 
Il semblerait que tu sois touché par le même problème que moi avec le secondary passthrough en VFIO dans une VM Windows...
Est-ce que quand tu ouvres ta Radeon dans le gestionnaire de périphériques tu as le message : code 12 : Ce périphérique ne peut pas trouver suffisamment de ressources libres utilisables. Si vous voulez utiliser ce périphérique, vous devrez désactiver l'un des autres périphériques sur ce système ?
Si tu trouves une solution, ça m'intéresse, je pense avoir déjà à peu près tout essayé...
La même configuration avec une VM sous Linux fonctionne parfaitement.
Sinon, il faudra que tu passes soit à pci-assign (avec le problème des reboot), soit au primary passthrough avec kernel patché.
 
Pour revenir aux histoires de licences Windows, c'est casse-pied... J'ai changé le chipset de ma VM de i440fx à q35 et ma licence n'est plus valide, il va valoir que j'appelle Microsoft pour la faire réactiver.

Non, j'avais une autre erreur et je ne l'ai pas notée; avec ces histoires de licence, j'ai réessayé une installation, mais ce n'est pas terminé (pas mal de bug incompréhensibles suite à l'installation de catalyst, voire avec les drivers virtio (impossible de lancer les consoles de gestions type windows update, propriétés de l'ordinateurs, etc..).
Ton essai infructueux, c'était aussi sous Debian?

Tu veux dire que une VM sous linux reconnait bien la carte graphique et qu'elle fonctionne en passthrough?

A choisir, le Kernel patché me semble la solution idéale. Simplement je ne me rends pas compte de la difficulté à recompiler le kernel avec les bonnes options, mais c'est sûrement la meilleure solution!

Très pénible.. J'hésite même à faire mes tests en XP.. La radéon a un driver sous xp, mais que en 32bits...

Sinon faites les test sur un windows non validé, puis quand c'est bon vous validez le bouzin
 
XaT

Oui, mon hôte est sous Wheezy (avec Kernel 3.14 et qemu 2.0 actuellement, mais j'avais les mêmes résultats avec les versions précédentes).
Ma VM sous Ubuntu 14.04 fonctionne sans souci, je joue à Metro Last Light dans de bonnes conditions (dans la limite de ma Radeon 7850 et des drivers catalyst sous Linux bien sûr).
Pour le kernel à patcher pour x-vga, je pourrais t'aider.  
Par contre, il faut avoir qemu 2.0 pour ne pas avoir de problèmes.
Il faut le configurer avec les bonnes options et appliquer les patchs fournis dans le package dispo sur le forum Archlinux, de mémoire :
- i915 pour corriger un bug avec le VGA Arbiter du driver Intel.
- acs override si les groupes VFIO ne sont pas bons (soucis avec certains chipset Intel à priori).
- fix_memleak pour un éventuel souci de non libération de la RAM à l'arrêt des VM.
Mais avant de te lancer là-dedans, je te conseille d'essayer la méthode pci-assign, pour t'assurer que ça fonctionne comme ça déjà.

pour le kernel patché je suis preneur aussi (sous opensuse 13.1) mais si mais souvenir sont bon a la prochaine maj du kernel le pach est a refaire ?

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é.