KVM et passthrough afin de se passer du dual-boot

Support Debian
#1

Salut
Toujours le même, et pour le même projet à terme.
A savoir celui de ne plus avoir de dual ou tri-boot…
Avec quelque chose d’intégré au noyau, KVM, d’après les vidéos que j’ai pu voir sur Youtube
ça fonctionne plutôt bien !
http://www.youtube.com/watch?v=VGdqRuHBY64
Avec Xen, il y a quelques temps, j’ai pu jouer à Battlefield 4 dans les mêmes conditions que si j’avais booter directement sur Windows 8.1 :slightly_smiling:

Qemu est vraiment impressionnant, au delà d’émuler le x86, x86_64 il est capable de faire de même avec le PowerPC, ARM…

Donc voilà, je me suis lancé dans KVM, et pour le moment et bien, c’est moins simple :confused:
Si vous voulez m’aider je suis un noob sur KVM :frowning:

#2

Plop,

Je n’ai pas vu de question, donc je ne ferais aucune réponse.

Perso j’ai 3 vm sous XP et deux sous Debian, l’hôte étant sous Debian, qui communiquent entre elles et avec l’hôte sur un switch virtuel, et si besoin j’active une connexion réseau en pont sur eth0 pour aller sur internet.

Si tu veux plus simple regarde du côté de virtualbox.

Usti

#3

Pardon, mais en fait je cherche comment faire du PCI Passthrough avec Qemu-KVM ?
malheureusement VirtualBox ne permet pas de faire du PCI Passthrough pour la carte graphique :confused:

#4

Je suis moi aussi satisfait des possibilités de Qemu-Kvm.

Il faut pour cela que ton matériel (CPU + CM) supportent la technologie VTd (rien à voir avec VTx).
Voici la liste des CPU Intel VTd, mais si c’est celui qui est cité dans ta signature (i5) => OK.
Relis la doc de ton matériel, les docs sur Kvm et vérifie tout avant.

Pour ta carte mère, j’ai eu plus de difficultés à trouver, mais tu devrais avoir la documentation de ta carte mère, et le dernier lien de ce post (Xen) confirme que les ASRock H87 peuvent le faire.
Ensuite il faudra voir du côté de ta/tes cartes graphiques (l’idéal étant d’utiliser une carte avec la machine virtuelle et l’autre pour l’hôte).

linux-kvm.org/page/How_to_as … T-d_in_KVM
Le lien (Xen) donné dans la page ci-dessus est mort mais j’ai quand même trouvé la page citée,
et le lien est ci-dessous.
wiki.xen.org/wiki/VTd_HowTo

#5

Mon carte-mère supporte bien le Vt-d, mon cpu 4770s aussi.
Là où je bloque c’est sur l’attribution de la carte graphique en passthrough à la VM Windows :frowning:
Si vous savez comment faire ?

J’ai suivi ce tutoriel, mais adapté sur ma Debian Jessie
https://bbs.archlinux.org/viewtopic.php?id=162768&p=1

Preparing the GPU so we can bind it to vfio

For the next step we need to:

Blacklist radeon or nouveau or nvidia or fglrx on /etc/modprobe.d/blacklist.conf

Example, blacklisting the opensource radeon module:

    echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf 
Use pci-stub

In my case since i have 2 radeon cards blacklisting the radeon module is not an option, so i use pci-stub.

NOTE: If pci-stub was built as a module, you'll need to modify /etc/mkinitcpio.conf and add pci-stub in the MODULES section, after that you need to update your initramfs like this.

mkinitcpio -p linux-mainline

lspci

    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 7950] <-- radeon 7950
    01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 7900 Series] <-- radeon 7950 audio
lspci -n

    01:00.0 0300: 1002:679a <-- radeon 7950
    01:00.1 0403: 1002:aaa0 <-- radeon 7950 audio
Now add this to your grub cfg file:

    pci-stub.ids=1002:679a,1002:aaa0
dmesg | grep pci-stub

    [    2.096151] pci-stub: add 1002:679a sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
    [    2.096160] pci-stub 0000:01:00.0: claimed by stub
    [    2.096165] pci-stub: add 1002:AAA0 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
    [    2.096174] pci-stub 0000:01:00.1: claimed by stub
    [    2.096178] pci-stub: add 1B21:1042 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000

Setting up vfio and kvm modules

If your board doesn’t enable interrupt remapping, you need to add this to your grub cfg:

vfio_iommu_type1.allow_unsafe_interrupts=1

Or if vfio-pci was built as a module ( default on arch )

echo “options vfio_iommu_type1 allow_unsafe_interrupts=1” > /etc/modprobe.d/vfio_iommu_type1.conf

Some applications like Passmark Performance Test and SiSoftware Sandra crash the VM without this:

echo "options kvm ignore_msrs=1" >> /etc/modprobe.d/kvm.conf

Binding a device to vfio-pci

Assuming the kernel, qemu and seabios are built and working, lets bind some devices.
You can use this script to make life easier:

#!/bin/bash

modprobe vfio-pci

for dev in "$@"; do
        vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
        device=$(cat /sys/bus/pci/devices/$dev/device)
        if [ -e /sys/bus/pci/devices/$dev/driver ]; then
                echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
        fi
        echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id
done

Save it as /usr/bin/vfio-bind

chmod 755 /usr/bin/vfio-bind

Bind the GPU:

vfio-bind 0000:01:00.0 0000:01:00.1

J’en suis ici, et je ne sais pas comment recompiler un noyau ou Qemu avec leurs options :frowning:

J’obitens:

    qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: Device does not support requested feature x-vga
    qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get device 0000:01:00.0
    qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
    qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized
#6

Salut,
Je te fais part de ma propre expérience. J’ai globalement la même configuration que toi et j’ai voulu faire exactement la même chose que toi il y a 5 mois avec Xen puis KVM. J’ai testé tous les fichiers de conf possibles et trouvables. Le Passthrought pour les ports USB ça marchait nickel, pour le son aussi mais pour la carte graphique ça n’a jamais voulu. Je me suis condamné à garder un dual boot pour utiliser cette saloperie de logiciel d’archi.

#7

Je n’ai pas eu le temps d’essayer le Passthrought vidéo car je n’avais pas encore de deuxième carte graphique, mais j’ai pû l’utiliser pour le son, le contrôleur USB, la carte réseau et le [strike]contrôleur SATA[/strike] (je m’étais trompé, pas le contrôleur SATA).
Du coup, ce fil m’intéresse…
J’avoue que j’ai d’abord tenté en ligne de commande, puis avec virt-manager, qui m’a aidé à trouver des solutions toutes faites que je n’avais plus qu’à récupérer avec virsh (XML).
La lecture des fichiers de log de virt-manager m’a aussi beaucoup aidé.
Ensuite, je suis revenu en ligne de commande.
Je projetais de tenter un accès à ma carte nvidia, mais je me suis vite rendu compte que le pilote propriétaire devait bloquer quelque part (enfin, c’est l’impression que j’ai eu).
Il est clair qu’il faut adapter le “initramfs” et le noyau pour que les ressources ne soient pas réservées dès le démarrage du système.

Une idée me vient : Proxmox permettrait peut-être cette disponibilité de ressources, mettant ainsi les deux systèmes (ancien hôte et ancienne machine virtuelle)au même niveau. Mais ça fait bien 1 ans que je n’y suis pas revenu.
Il y a peut-être aussi les forums et documentations des distributions Red hat et Gentoo.

Je vais suivre ce fil…

EDIT: J’avais oublié de dire que ma carte mère était une Asus P5KPL AM EPU, c’est je pense, ce qui m’avait permis tout ça.
Depuis, je ne suis pas arrivé au même résultat avec d’autres cartes mère.

#8

@MicP

Avec cette commande:

    echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf

Le chargement du pilote radeon dans mon cas est donc bloqué au démarrage, dans ton (votre?) cas, ça sera le pilote nvidia ou nouveau qu’il faudra “blacklister”

#9

Oui, mais ça c’est après que le système ai démarré et donc utilisé initramfs.
Il faudrait aussi l’hiniber dans la liste des modules chargés par initramfs et reconstruire le fichier avec “update-initramfs”.

wiki.debian.org/fr/KernelModuleBlacklisting

voir : "/etc/modprobe.d/"
et update-initramfs

Mais si on blackliste le pilote propriétaire, il faudra peut-être dé-blacklister le pilote libre (“nouveau” pour nvidia)

#10

Oui pardon le

update-initramfs -u

est nécessaire.

le lspci -k nous donne:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950]
	Subsystem: PC Partner Limited / Sapphire Technology Device e210
	Kernel driver in use: vfio-pci
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series]
	Subsystem: PC Partner Limited / Sapphire Technology Device aaa0
	Kernel driver in use: vfio-pci

Ce qui je pense est ok pour le passthrough mais après on fait comment ?

NB: Pensez à poster votre config dans votre signature, ça sera plus clair
NB2: http://www.gaminganywhere.org/index.html Du streaming réseau adapté aux jeux

#11

Avec ces commandes là, je trouve bien ma carte graphique dans ma VM Windows 8.1 mais malheureusement celui-ci plante :confused:

Si quelqu’un est dans le même cas que moi, je veux bien un peu d’aide

Je lance ma VM Windows 8.1 avec Virt-Manager, avec les paramètres de base la première fois pour l’installation.
Et au deuxième démarrage je passe ma 01:00.0 et 01:00.1 à la VM afin d’y installer les drivers, et là… c’est le drame :frowning:
plantage de Windows :frowning:

#12

Une idée me vient:

Pour l’instant, tu essaie de faire fonctionner le passthrough avec win. Mais il est difficile (euphémisme ?) de savoir ce qui peut clocher dans ce système.

Alors je me suis dit qu’il serait peut-être intéressant de commencer par tester le passthrough avec une debian guest dans debian host.
Si là ça ne fonctionne pas, il y aura toujours moyen de savoir pourquoi (du moins du côté soft).
Il sera donc plus facile (sources + contacts avec les développeurs, forums, etc) de dire: le problème ne vient pas du soft, donc, il vient très probablement du matériel.

#13

Une idée comme ça le passthrough sous Xen réclame que l’OS invité soit avec un kernel HVM, ne serait-il pas du même besoin sous KVM :think:

#14

Oui tu as absolument raison, je vais tester ce soir avec une debian en guest
En fait, j’espère avoir des soucis aussi :slightly_smiling:

J’ai même tenté la dernière version de seabios et de charger la VM avec le fichier
Bios de ma carte graphique, mais rien n’y a fait :frowning:

#15

Sous ma VM Debian 7.2
mon lspci me trouve bien mes 2 périphériques AMD !

http://imagik.fr/view-rl/68466

#16

Bonne nouvelle en tout cas :slightly_smiling:

On peut en conclure que KVM fonctionne comme tu voulais et que le problème serait plutôt à chercher du côté du SE virtualisé.

Ne serait-ce pas une histoire de pilote au niveau du SE virtualisé ?
En fait, il faudrait trouver un moyen de vérifier que ces ports PCI sont bien accessibles depuis le SE virtualisé,
et ensuite trouver le pilote ou driver qui saura les utiliser dans ce contexte.

#17

Salut,

J’ai aussi un projet de GPU passthrough pour transformer mon ancien ordi gamer en serveur avec plusieurs VM, me permettant de me passer du dual-boot entre mon Windows de jeu et mon Arch de travail, et de streamer Steam sur la tv du salon.

Est-ce que tu as réussi à faire fonctionner le passthrough dans ton cas ? J’ai aussi une HD7950 mais je ne parviens pas à faire fonctionner le passthrough, KVM me renvoie une erreur:

 kvm: -device vfio-pci,host=01:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0,x-vga=on: vfio: Device does not support requested feature x-vga 
 kvm: -device vfio-pci,host=01:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0,x-vga=on: Device initialization failed

Et en effet si j’enlève cette option la machine se lance sans erreur mais:

  • en interactif un message s’affiche: kvm: -device vfio-pci,host=01:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0: VFIO 0000:01:00.0 BAR 0 mmap unsupported. Performance may be slow
  • une VM windows n’affiche rien avec vnc, et je ne peux pas m’y connecter avec Microsoft Remote Desktop
  • une VM linux affiche “Guest has not initialized display yet” avec VNC et je ne répond pas au ssh

Ma config:

  • Intel i7-3770
  • MSI Z77A-G45
  • 24Go DDR3
  • Sapphire Radeon HD7950-3072

Je vous mets le détail de ce que j’ai fait dans le post suivant.

#18

J’utilise Proxmox 4.2 (basé sur debian).

J’ai suivi les indications de cette page: https://pve.proxmox.com/wiki/Pci_passthrough et un autre (blog vfio) mais je n’ai pas le droit de mettre plus de lien en tant que nouveau sur le forum.

Modifié /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

> update-grub

Créé: /etc/modules

vfio vfio_iommu_type1 vfio_pci vfio_virqfd

La commande dmesg | grep ecap répond:

[    0.037273] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c9008020660262 ecap f0105a

Le code après ecap fini par un “a” donc normalement mon système supporte le interrupt remapping donc je ne crée pas le fichier /etc/modprobe.d/iommu_unsafe_interrupts.conf

J’ai trois devices dans le groupe 1 avec find /sys/kernel/iommu_groups/ -type l

/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/1/devices/0000:01:00.0
/sys/kernel/iommu_groups/1/devices/0000:01:00.1
/sys/kernel/iommu_groups/2/devices/0000:00:14.0
/sys/kernel/iommu_groups/3/devices/0000:00:16.0
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0
/sys/kernel/iommu_groups/7/devices/0000:00:1c.1
/sys/kernel/iommu_groups/8/devices/0000:00:1d.0
/sys/kernel/iommu_groups/9/devices/0000:00:1f.0
/sys/kernel/iommu_groups/9/devices/0000:00:1f.2
/sys/kernel/iommu_groups/9/devices/0000:00:1f.3
/sys/kernel/iommu_groups/10/devices/0000:03:00.0

Ils correspondent à:

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series]
Je n’ai pas compris si c’était grave d’avoir les trois dans le même groupe. À priori je n’ai bien que les deux composantes de la carte graphique qui ont le driver vfio:

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09) Kernel driver in use: pcieport 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] [1002:679a] Subsystem: PC Partner Limited / Sapphire Technology Device [174b:3000] Kernel driver in use: vfio-pci 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series] [1002:aaa0] Subsystem: PC Partner Limited / Sapphire Technology Device [174b:aaa0] Kernel driver in use: vfio-pci

J’ai crée /etc/modprobe.d/vfio.conf

options vfio-pci ids=1002:679a,1002:aaa0 disable_vga=1

avec les numéros venant de > lspci -n -s 1:.

Et /etc/modprobe.d/blacklist.conf

blacklist radeon

J’ai aussi créé après pour essayer de règler le soucis un fichier /etc/modprobe.d/radeon.conf contenant aussi:

blacklist radeon

Puis
depmod -ae
update-initramfs -u

Au boot l’écran branché sur la carte graphique reste figé sur:

Mais en dehors de ça Proxmox fonctionne très bien.

Pour ma carte graphique, je suis un peu perdu, à priori elle ne possède pas de Rom EFI. Le programme rom-parser renvoie:

Valid ROM signature found @0h, PCIR offset 238h PCIR: type 0 (x86 PC-AT), vendor: 1002, device: 679a, class: 030000 PCIR: revision 0, vendor revision: f18 Last image
Alors que si j’ai bien compris, cette carte (Sapphire Radeon HD7950-3072) devrait en avoir une.

J’ai essayé les 4 options proposées pour /etc/pve/qemu-server/.conf, à savoir avec ou sans PCIexpress et avec UEFI ou avec un BIOS mais rien ne fonctionne.
Avec OVMF:

TASK ERROR: start failed: command '/usr/bin/kvm -id 150 -chardev 'socket,id=qmp,path=/var/run/qemu-server/150.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/150.pid -daemonize -smbios 'type=1,uuid=2ff66503-20a6-4997-8d88-17744469e300' -drive 'if=pflash,format=raw,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd' -drive 'if=pflash,format=raw,file=/tmp/150-OVMF_VARS-pure-efi.fd' -name WinTest -smp '8,sockets=4,cores=2,maxcpus=8' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000' -vga none -nographic -no-hpet -cpu 'kvm64,hv_vendor_id=proxmox,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_relaxed,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce,kvm=off' -m 8192 -k en-us -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'vfio-pci,host=01:00.0,id=hostpci0,bus=pci.0,addr=0x10' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:ad28f62a7aaf' -drive 'if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' -drive 'file=/dev/pve/vm-150-disk-1,if=none,id=drive-scsi0,cache=writeback,format=raw,aio=threads,detect-zeroes=on' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -drive 'file=/dev/pve/vm-150-disk-1,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa' -netdev 'type=tap,id=net0,ifname=tap150i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=62:66:36:33:32:63,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -rtc 'driftfix=slew,base=localtime' -global 'kvm-pit.lost_tick_policy=discard'' failed: exit code 1

Avec BIOS:

TASK ERROR: start failed: command '/usr/bin/kvm -id 150 -chardev 'socket,id=qmp,path=/var/run/qemu-server/150.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/150.pid -daemonize -smbios 'type=1,uuid=2ff66503-20a6-4997-8d88-17744469e300' -name WinTest -smp '8,sockets=4,cores=2,maxcpus=8' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000' -vga none -nographic -no-hpet -cpu 'kvm64,hv_vendor_id=proxmox,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_relaxed,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce,kvm=off' -m 8192 -k en-us -readconfig /usr/share/qemu-server/pve-q35.cfg -device 'usb-tablet,id=tablet,bus=ehci.0,port=1' -device 'vfio-pci,host=01:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0,x-vga=on' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:ad28f62a7aaf' -drive 'if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -drive 'file=/dev/pve/vm-150-disk-1,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap150i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=62:66:36:33:32:63,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -rtc 'driftfix=slew,base=localtime' -machine 'type=q35' -global 'kvm-pit.lost_tick_policy=discard'' failed: exit code 1

Vous voyez ce que j’ai de mauvais ?
Merci !