passthrough_handbook-french.txt

## CECI N'EST PAS UN TUTORIEL, MAIS UN BLOC-NOTE.
IL RÉCAPITULE LES ÉTAPES POUR UN PCI-PASSTHROUGH PROPRE PAR SON AUTEUR PRIMAIRE.
--------------------------------------------------------------------------------

## AVERTISSEMENT : la configuration du pci-stub déclaré dans de nombreux tutoriels ne concerne que les kernels antérieurs à la version 4.1.
Toutes les distributions actuelles ou correctement mises à jour ont des kernels supérieurs à 4.1, il n'y a donc pas lieu de tenir compte de cette configuration.

## Identification de la machine test :
-------------------------------------
CPU : AMD Ryzen 5 1600 Six-Core @ 3.80GHz (6 Cores)
Motherboard: Gigabyte AX370-Gaming K3
Bios : last
Chipset : AMD Family 17h
Memory : 32 Go
Guest Graphics : Gigabyte NVIDIA GeForce GTX 1060 3GB 3072MB pcie x16 slot
Host : EVGA NVIDIA GeForce GTX 1060 6GB 6144MB pcie x8 slot
OS: Fedora 27 Mate
Pilote Nvidia propriétaire.

## carte graphique et configuration Xorg
----------------------------------------
La carte graphique dédié à la VM doit être configurée dans le xorg.conf comme désactivé pour éviter toutes prise en charge automatique par l'environnement Linux.
Le fichier xorg suivant est un exemple depuis la machine test et doit etre modifié aux besoins :
(obtention des BusID avec : lspci -nn | grep -e "VGA")

** Avertissement ** Il n'as pas été possible de lancer proprement la VM en utilisant un seul écran sur des connexions différentes (HDMI, DVI. HDMI, Display-port n'as pas été testé), l'EFI de l'invité n'étant à même
d'initialiser un connecteur désactivé. Deux écrans sont obligatoirement prérequis.

``
Section "Monitor"
    ## écran dédié à la VM
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Idek Iiyama PL2530H"
    HorizSync       30.0 - 83.0
    VertRefresh     55.0 - 76.0
EndSection

Section "Monitor"
    ## écran dédié au système
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Idek Iiyama PL2530H"
    HorizSync       30.0 - 83.0
    VertRefresh     55.0 - 76.0
EndSection

Section "Device"
   ## carte dédiée à la VM
	Identifier	"Device0"
	Driver		"nvidia"
	VendorName	"NVIDIA Corporation"
	BusID		"PCI:9:0:0"
EndSection

Section "Device"
	## carte dédiée au système
	Identifier	"Device1"
	Driver		"nvidia"
	VendorName	"NVIDIA Corporation"
	BusID		"PCI:6:0:0"
EndSection

## La section 'ServerLayout" est généralement mieux placée en tête du fichier xorg.conf.
## La position donnée ici est uniquement pour permettre une meilleure lecture du procédé.
Section "ServerLayout"
	Identifier	"Layout0"
	Screen 1	"Screen1" 0 0
	## désactivation de la carte dédiée à la VM
	Inactive	"Device0"
EndSection

Section "Screen"
	## configuration minimale pour le matériel dédié à la VM
	## pci bus x16
	Identifier	"Screen0"
	Device		"Device0"
	Monitor		"Monitor0"
EndSection

Section "Screen"
   ## configuration normale pour la carte dédiée au système
   ## pci bus x8
	Identifier	"Screen1"
	Device		"Device1"
	Monitor		"Monitor1"
	Option	"NoLogo" "true"
	Option	"UseEDID" "true"
	Option	"ProbeAllGpus" "false"
	Option	"SLI" "Off"
	Option	"MultiGPU" "Off"
	Option	"BaseMosaic" "off"
	Option	"Coolbits" "8"
	Option	"TripleBuffer" "true"
	Option	"Stereo" "0"
	Option	"RenderAccel" "true"
	Option	"DPI" "96 x 96"
Endsection
``

## Détection de l'IOMMU.
------------------------
(le CPU doit supoorter les options VT-d ou AMD-Vi; l'option VT-x est moins conseillé, car moins sécurisée)
# l'option IOMMU doit être activés dans le BIOS (prérequis)
# Certains BIOS permettent de choisir le boot GPU, si possible autant choisir le bus pci x16 pour la VM.
# et passer le GPU sur bus pci x8 pour le boot et l'hôte.

## options grub à insérer soit directement dans le grub.cfg:
> amd: amd_iommu=on rd.driver.pre=vfio-pci iommu=pt hugepages=2048
> intel: intel_iommu=on rd.driver.pre=vfio-pci iommu=pt hugepages=2048
## soit dans (fedora; debian, arch):
# /etc/default/grub, ligne GRUB_CMDLINE_LINUX

## hugepages:
-------------
(source '2 Answers' https://unix.stackexchange.com/questions/163495/libvirt-error-when-enabling-hugepages-for-guest)
hugepages alloue de manière statique un montant X de mémoire par core.
Une fois allouée cette quantité de mémoire ne sera pas plus disponible pour le système et uniquement pour les applications configurées pour l'utiliser.
Hugepage alloue par défaut un bloc de 1024M par core.
Ainsi, on peut envisager des block allant de 1024 > 2048 > 3072 > 4096, selon la quantité disponible et les capacités du CPU (la plupart ne peuvent pas aller au-delà de 2048).
Hugepage est optionel.

# Calcul des pages à allouer (XX réprésentant la RAM à allouer à la VM):
XX*1024*1024/2048 = xxxx pages
> ex pour 8∕16Go de RAM :
8*1024*1024/2048 = 4096 pages
12*1024*1024/2048 = 6144 pages
16*1024*1024/2048 = 8192 pages

# insérer la nombre de pages allouées dans /etc/sysctl.conf :
(la ligne shm est optionnelle, mais il peut être préférable de définir un groupe dans shm)
vm.nr_hugepages = 4096
vm.hugetlb_shm_group = 36

# test direct :
Attention: la machine test (fedora 27) possède un point de montage déjà défini (/dev/hugepages/libvirt/qemu/).
Le point de montage défini ci-dessous n'est valable que pour le test avant reboot.
mount -t hugetlbfs hugetlbfs /dev/hugepages
sysctl vm.nr_hugepages=4096 vm.hugetlb_shm_group=36
# note :
> Si le point de montage n'apparait pas dans le répertoire /dev après redémarrage, il doit être ajouté à /etc/fstab (non, testé).
hugetlbfs    /hugepages    hugetlbfs    defaults    0 0
> La configuration de /etc/sysctl.conf n'est pas une obligation d'autant que le nombre de pages peut être soumis à de nombruex tests. Pour une configuration automatisée au démarrage décommenter et modifier la ligne 'systcl' dans le script 'vfio_bind' un peu plus bas dans le texte.

# note: Dans Fedora, l'attribution d'un bloc de 2048kB par page est automatisée par le système.
L'option dans grub.cfg 'hugepages=2048' n'est probablement pas nécessaire.

# > reboot
# > controle de la ligne de commende GRUB: cat /proc/cmdline

# cmdline de base pour un listing des blocs pci et des groupes:
> cmdline > listing des adresses pci du matériel graphique et des audios hdmi associés (s'il y a lieu) :
lspci -nn | grep -e "VGA" -e "Audio"
> cmdline > controle de l'activation de l'IOMMU et des groupes :
find /sys/kernel/iommu_groups/ -type l

script controlant l'IOMMU et désignant les groupes détachable du système (iommu_group.sh):
-----------------------------------------------------------------------------------------
(regroupe les 2 commandes ci-dessus de manière ordonnée)
``
#! /bin/bash

# define the elements to check, ex: VGA, Audio, USB, etc.
dev_type='VGA\|Audio'

ifs=$IFS
IFS=$(echo -en "\n\b")
pci_slot=( $(lspci -nn | grep -e "$dev_type"| sed -En "s/^(.*[0-9]) (.*): (.*) \[.*:.*\].*$/\1|\2|\3/p") )
if [ ${#pci_slot[@]} -gt 0 ]; then
	for slot in ${pci_slot[@]}; do
		pci_addr=$(printf "$slot"| cut -d'|' -f1)
		pci_devs=$(printf "$slot"| cut -d'|' -f2| awk '{print $1}')
		pci_brand=$(printf "$slot"| cut -d'|' -f3)
		pci_group=$(find /sys/kernel/iommu_groups/ -type l| sed -En "s/^.*\/([0-9]{1,2})\/.*$pci_addr$/\1/p")
		grp_members=$(find /sys/kernel/iommu_groups/ -type l| grep -c "$pci_group")
		if [ $grp_members -le 2 ]; then
			condition="detachable"
		else
			condition="multiple"
		fi
		echo -e "Grp: $pci_group\t$condition\t$pci_devs:\t$pci_addr > $pci_brand"
	done
else
	echo -e "## IOMMU is not set ##"
fi

exit 0
IFS=$ifs
``

## vfio bind script
-------------------
> créer et enregistrer dans /usr/local/sbin/vfio_bind :
``
#!/bin/sh

## modify the line below as needed. 
DEVS="0000:09:00.0 0000:09:00.1"

for DEV in $DEVS; do
    echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override
    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
modprobe -i vfio-pci
## (comment/uncomment) If /etc/sysctl.conf is leave unconfigured for hugepages allocation, you can setup
## it here (replace x by defined pages number) :
#sysctl vm.nr_hugepages=xxxx vm.hugetlb_shm_group=36
``
> et le rendre exécutable :
chmod 755 /usr/local/sbin/vfio_bind

## options à ajouter à l'initramfs
----------------------------------
# fedora:
> créer /etc/dracut.conf.d/local.conf (attention l'espace après les guillement est important) :
add_drivers+=" vfio vfio_iommu_type1 vfio_pci vfio_virqfd"
install_items+="/usr/local/sbin/vfio_bind" 
> recréer l'initramfs :
dracut -f --kver $(uname -r)

# debian:
(la méthode peut tout aussi bien être appliquée à Fedora à l'exception de la commande de l'initramfs)
> créer /etc/modprobe.d/vfio.conf
vfio vfio_iommu_type1 vfio_pci vfio_virqfd
update-initramfs -u

# arch:
> ajouter dans /etc/mkinitcpio.conf : (avant les pilotes graphiques s'ils sont charger par le fichier de config)
> ligne MODULES=""
MODULES="<liste des modules présents> vfio vfio_iommu_type1 vfio_pci vfio_virqfd <liste des modules graphiques>"
> ligne HOOKS="" : s'assurer de la présnce de 'modconf' dans la ligne de config.
ex: HOOKS="base udev autodetect modconf block filesystems keyboard fsck"
> reconstruire l'initramfs par défault :
mkinitcpio -g `ls -1 /boot | grep -iv "fallback"| grep "img"`
> si le répertoire 'boot' contient plusieurs images initramfs, selectionner celle qui convient
ou créer une nouvelle spécifique à l'usage et permettant un fallback en cas de problème :
mkinitcpio -g /boot/<image sélectionnée>.img
(dans le cas d'une image personnalisée, il convient de mettre à jour le fichier grub.conf avec celle-ci)
(section grub reconfig à ajouter sur demande)

# vérifié la prise en charge dans l'initramfs:
(tout les pilotes configurés doivent s'y trouver, ainsi que le script vfio_bind)
lsinitrd | grep -i "vfio"

# > reboot
# > controle de l'activation du bind (le pilote rapporté pour le carte virtualisée doit être vfio-pci) :
lspci -nnk -s :9
(et pour chaque réf VGA dans lspci, le chiffre étant la partie marquante de la réf dans le bus pci,
ex: 0000:09:00.0)

## création de la VM avec virt-manager
--------------------------------------
Installer virt-manager si ce n'est pas déjà fait :
> fedora : dnf install @virtualization
> debian :
> arch :

** Avertissement ** virt-manager a besoin d'avoir accès au système, il lui faut pour cela les accès root.
Il est possible que le fichier /etc/libvirt/qemu.conf ne soit pas configuré avec ces accès.
Décommenter les lignes suivantes dans /etc/libvirt/qemu.conf :
``
user = "root"
group = "root"
clear_emulator_capabilities = 0 > par défaut à 1 dans le fichier.
``

Suivre les instruction de ce lien:
http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-4-our-first.html

** Avertissement ** Il est préférable d'installer un environnement windows 10 propre soulagé de tout ce qui est à même de d'utiliser la mémoire et la bande passante inutilement. Ainsi, il sera possible par la suite d'ajuster la mémoire allouée à la VM et de permettre au 2 environnements de coexister paisiblement au maximum de leurs performances.

# La VM est configurée avec le boot UEFI de OVMF (ici avec ovmf-x64/OVMF_CODE-pure-efi.fd)
> fedora : dnf install edk2-ovmf (ou/et dnf install edk2.git-ovmf-x64)
> debian : apt-get install ovmf
> arch : pacman -S ovmf
Les fichiers OVMF sont installés généralement dans /usr/share/ovmf (/usr/share/edk2/ovmf pour fedora).
S'ils n'appraissent pas dans la liste de virt-manager, il est nécessaire de les déclarer dans le fichier
de config /etc/libvirt/qemu.conf :
(le nom des fichiers est un exemple, il peut diverger selon la distribution et le choix de l'utilisateur)
nvram = [
	"/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd"
]
Pour l'exemple de la machine test cela donnerait (cela n'a pas été nécessaire) :
nvram = [
	"/usr/share/edk2/ovmf-x64/OVMF_CODE-pure-efi.fd"
]
Il peut être ajouté autant de fichiers .fd que nécessaire.

# le chipset peut être mis en Q35 qui permet plus de performance (l'exemple du lien est par sécurité en i440FX, plus stable).
# il est plus simple de préparé la VM sur des disque matériels plutot que virtuels avec 2 partitions en GPT.
La seconde partition servant à contenir les paquets des applications indispensables ainsi que les pilotes et de pouvoir éxécuter rapidement une nouvelle installation en cas de besoin. Une image disque est tout 
aussi valable, cependant il faut s'assurer de la rapidité de lecteur hôte.
> A la création de la VM, dans le cas d'un disque matériel, entrer : 
/dev/sdX pour le stockage (X représantant le lettre du disque dur à dédier).

# listes des pilotes et applications:
> pilote Nvidia
> pilote audio (si une carte audio est dédié à la VM)
> l'iso des pilotes vfio (virtio-win.iso de Fedora: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/)
> l'iso des pilotes CPU et autres bus pci.
> dxwebsetup.exe (uniquement celui-ci, optionnel, certains jeux réclamerons l'installation de DirectX) https://www.microsoft.com/fr-fr/download/details.aspx?id=35
> tightvnc server (indispensable pour garder la main sur la VM si les choses tournent mal) https://www.tightvnc.com/download/2.8.11/tightvnc-2.8.11-gpl-setup-64bit.msi
> Open hardware Monitor (permettra de controler les performances de la VM et d'ajuster par la suite la mémoire selon l'usage) https://openhardwaremonitor.org/files/openhardwaremonitor-v0.8.0-beta.zip
> GPU-z (valeurs détaillées de la carte graphique) https://www.techpowerup.com/download/techpowerup-gpu-z/
(Si la VM est créée sur une machine faisant déjà tourner Win 10 en natif, il est plus simple d'utiliser
un copie de dossier /windows existant à l'exception des graphiques) ou un backup de :
(cette partie n'est pas encore testée)
\windows\System32 (\config \Configurations \drivers \DriverStore \*.dll \*.exe)
\windows\SysWow64 (est un hard link de System32, peut ne pas être nécessaire)
\windows\WinSxS (tout)

## sortie cat /proc/cpuinfo.
----------------------------
> Ryzen 5, 6 cores (6 réels + 6 virtuels)
# cat /proc/cpuinfo | grep -i -e "processor.*:" -e "core id"
** attention le partie 'core id' ne correspond pas nécessairement à la sortie de /proc/cpuinfo **
** le pin 'core id' dans virsh doit néanmoins respecter la chaine du processeur virtuel (0,1,2,3,4, etc) **
# cores réels:
processor	: 0  > core id		: 0 CPU 1
processor	: 2  > core id		: 1 CPU 3
processor	: 4  > core id		: 2 CPU 5
processor	: 6  > core id		: 3 CPU 7
processor	: 8  > core id		: 4 CPU 9
processor	: 10 > core id		: 5 CPU 11

# cores virtuel:
processor	: 1  > core id		: 0 CPU 2
processor	: 3  > core id		: 1 CPU 4
processor	: 5  > core id		: 2 CPU 6
processor	: 7  > core id		: 3 CPU 8
processor	: 9  > core id		: 4 CPU 10
processor	: 11 > core id		: 5 CPU 12

## insertion par virsh edit <nom_de_la_vm>
------------------------------------------
Le script dans section suivante permet de partiellement automatisé la section <cputune>.
# vi commande:
# inserer: i (esc pour annuler la commande)
# copier une ligne: yy
# coller une ligne: p
# écrire: :w
# sortir: :q
# écrire et sortir: :wq

## insertion dans la section <domain type='kvm'>
# au dessus de la section <os>
> hugepages (si défini) :
  <memoryBacking>
    <hugepages/>
  </memoryBacking>
> cpu pining (cores virtuels uniqument):
(ou utiliser le script en bas de page pour définir un exemple de configuration)
>> cores vituel uniqument:
  <cputune>
    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='3'/>
    <vcpupin vcpu='2' cpuset='5'/>
    <vcpupin vcpu='3' cpuset='7'/>
    <vcpupin vcpu='4' cpuset='9'/>
    <vcpupin vcpu='5' cpuset='11'/>
  </cputune>
>>> section <cpu mode> sous <features>
  <cpu mode='host-passthrough' check='partial'>
    <topology sockets='1' cores='6' threads='1'/>
  </cpu>"
> core matériel en threads (à vérifier, impossibilité de contrôle sur machine test):
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='2'/>
    <vcpupin vcpu='2' cpuset='4'/>
  </cputune>
>>> section <cpu mode> sous <features>
  <cpu mode='host-passthrough' check='partial'>
    <topology sockets='1' cores='3' threads='2'/>
  </cpu>

## section <features> (fix carte graphique Nvidia)
# sous la section <apic/>, insérer :
    <kvm>
      <hidden state='on'/>
    </kvm>

# suppresion de la partie <hyperv>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>

## section <clock offset='localtime'> (fix carte graphique Nvidia)
# suppresion de la ligne hypervclock
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/> ** ici
  </clock>

## script cpu_pining.
---------------------
> (ce script est un helper et doit être adapter aux besoins)
(améliorations nécessaire)
cpu_pining.sh
``
#! /bin/bash

n=0
cpu_virts=$(cat /proc/cpuinfo |grep -i "sibling" |sed -n "s/^.*: //p" |sort -u)
cpu_cores=$(cat /proc/cpuinfo |grep -i "cpu cores" |sed -n "s/^.*: //p" |sort -u)
if [ $cpu_virts -gt $cpu_cores ]; then
	tt_core=$cpu_virts
	virsh_tab_1b+=('  <cputune>\n')
	per_core=1
else
	tt_core=$cpu_cores
	virsh_tab_2b+=('  <cputune>\n')
	per_core=2
fi

until [ $n -eq $tt_core ]; do
core_tab+=( $n,$(cat /proc/cpuinfo |cat /proc/cpuinfo |sed -n "/^processor.*: $n$/,/core id.*$/p"| sed -n '$s/^.*: //p') )
((n++))
done
nr=0 ; nv=0
for core in "${core_tab[@]}"; do
	thread=$(printf "$core"| cut -d',' -f1)
	r_core=$(printf "$core"| cut -d',' -f2)
	if [[ -n $last_core && $last_core -eq $r_core ]]; then
		virsh_tab_1a+=( "processor :\t$thread > core id : $nv CPU $(($thread+1)) $virtual\n" )
		virsh_tab_1b+=( "    <vcpupin vcpu='$nv' cpuset='$thread'/>\n" )
		((nv++))
	else
		if [[ ! -n $last_core || $last_core -ge 0 ]]; then
			virsh_tab_2a+=( "processor :\t$thread > core id : $nr CPU $(($thread+1)) $virtual\n" )
			virsh_tab_2b+=( "    <vcpupin vcpu='$nv' cpuset='$thread'/>\n" )
			((nr++))
		fi
	fi
	last_core=$r_core
done
if [ $per_core = 1 ]; then
	virsh_tab_1b+=('  </cputune>\n')
	echo -e "# real core table:"
	echo -e " ${virsh_tab_2a[@]}"
	echo -e "# virtual core table:"
	echo -e " ${virsh_tab_1a[@]}"
	echo -e "## Section <cputune> above <os> :"
	echo -e "# CPU pining on virtual core only:"
	echo -e " ${virsh_tab_1b[@]}"
	
else
	virsh_tab_2b+=('  </cputune>\n')
	echo -e "# real core table:"
	echo -e " ${virsh_tab_2a[@]}"
	echo -e "## Section <cputune> above <os> :"
	echo -e "# CPU pining on real core (2 threads):"
	echo -e " ${virsh_tab_2b[@]}"
fi
echo -e "## Section <cpu mode> after <features> :"
echo -e "  <cpu mode='host-passthrough' check='partial'>
    <topology sockets='1' cores='$(($cpu_virts/2))' threads='$per_core'/>
  </cpu>"
```

## Note sur l'Audio HDMI
------------------------
** CRITIQUE ** La partie Audio HDMI des cartes Nvidia possèdant le même ID pci, le matériel audio des 2 cartes graphiques géré par Pulseaudio passe inévitablement à la VM lors de son lancement.
Il convient de stopper tous processus gèrés par Pulseaudio avant de lancer la VM pour palier à tous crashes de QEMU-KVM qui peuvent geler le système et contraindre au hard reboot.
ex: lecteur audio, lecteur video, jeux, etc.

## Benchmark.
-------------
Exemple Benchmark entre natif et VM avec FFXIV Stormblood Benchmark DX11 :
(les 3 tests sont conclus excellents)
NATIF Score : 10916 - img/s : 74.392 - temps de chargement des scènes : 17,649 sec - Performances graphiques : maximum - résolution : 1920x1080 75Mhz
VM Score (nvidia quality mode):     9283  - img/s: 64.694 - temps de chargement des scènes: 27.961 sec - Performances graphiques : maximum - resolution: 1920x1080 75Mhz
VM Score (nvidia performance mode): 9333  - img/s: 65.187 - temps de chargement des scènes: 28.138 sec - Performances graphiques : maximum - resolution: 1920x1080 75Mhz

## Sources des articles ayant servis pour l'édition de ce bloc-note :
--------------------------------------------------------------------
http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-1-hardware.html
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF
https://unix.stackexchange.com/questions/163495/libvirt-error-when-enabling-hugepages-for-guest
https://fedoraproject.org/wiki/Features/KVM_Huge_Page_Backed_Memory
https://help.ubuntu.com/community/KVM%20-%20Using%20Hugepages
https://forum.hardware.fr/hfr/OSAlternatifs/Logiciels-2/unique-passthrough-linux-sujet_74047_1.htm
https://ycnrg.org/vga-passthrough-with-ovmf-vfio/

## Lien iso virtio :
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/

## KVM et partage de clavier/souris.
------------------------------------
(il a été initialement supposé que l'utisation d'un KVM serait simple, ça n'a pas été le cas, au point de devoir ajouter ce mini-tutoriel au handbook et son script spécifique associé)
Le problème d'un invité en passthrough est que cela oblige à avoir 2 claviers et 2 souris en permanence. La solution la plus simple est d'avoir un KVM sous la main en attendant que le projet 'looking_glass' est fait de plus grand progrès (status actuel: alpha).
(https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387
https://looking-glass.hostfission.com/
https://github.com/gnif/LookingGlass/)

# Appareil :
N'importe quel KVM avec des port USB convient du moment où il permet de faire un switch aisé entre la l'hote et l'invité (matérielement ou par raccourci clavier), le port vidéo étant strictement optionnel.
Cependant, et si on n'en possède pas déjà un, le mieux est d'en acquérir un modèle adapté à l'usage.
Dans ce cas et si on compte utiliser le KVM autant pour l'USB que pour la vidéos, la gamme Roline (après de longue recherche) est celle qui se prête le mieux à l'utilissation virtuel et elle présente 2 modèles: HDMI/USB, Display-port/USB.

# Configuration de la VM:
** Attention ** Cette configuration fonctionne sur la machine test. Ceci ne garantit en aucune manière qu'elle fonctionnera de la même manière sur d'autre Carte-Mère avec une disposition différente du bus PCI.  

** Ajouter directement le port du HUB USB du KVM avec virt-manager s'est avéré disfonctionnel, l'invité s'étant trouvé incapable de reconnaitre l'intégralité des membres du HUB sur le KVM.
Le seul moyen a été d'isolé un port PCI détachable controlant un HUB USB de la Carte mère. **

# Trouver un port PCI détachable :
> Ajouter l'argument `USB` à la variable `dev_type` dans le script `iommu_group`. Repérer le matériel détachable dans la sortie.
> Lancer la commende `lsusb` pour afficher les matériels connecté (séléctionner en un aisement reconnaissable pour les tests).
> Exécuter la ligne de commande suivante où <pci_dev> correspond au controlleur détachable obtenu plus haut :
find /sys/devices/pci0000\:00/ -type l | egrep -i "^.*0000:<pci_dev>.*\/usb.*\/[0-9]{4}:.*:.*\..*$"| sed -En "s|^.*\/0000:(.*{2}:.*{2}.[0-9]{1})\/(usb[0-9]{1}).*\/[0-9]{4}:(.*)\..{4}\/.*$|\1 \2 \3|p"| sort -u
** la sortie (ex: 0a:00.3 usb5 09EB:0131) correspond respectivement à <port pci détachable> <bus usb> <id matériel> **
** la sortie 'usbX' correspond à la sortie 'Bus 00X' de `lsusb` **
> Exécuter la ligne de commande `lsusb` suivante de manière à clairement identifier le matériel usb test :
lsusb -d <id matériel>
> Répéter autant de fois que nécessaire les opérations pour une identication claire des conecteurs du controlleur PCI à détacher vers la VM.

# Connecter le KVM à la VM:
> Connecter le cable USB dédié à l'invité sur le KVM au connecteur USB du controlleur PCI détachable.
> Connecter le cable USB dédié à l'hote sur n'importe quel autre connecteur USB non lié au controlleur PCI détachable.
> Ajouter le périphérique PCI à la VM à l'aide de virt-manager.
> Lancer la VM. Le swicth devrait s'exécuter sans encombre.

Note : Si le controlleur PCI détachable possède plusieurs connecteurs USB, ils seront tous utilisable par la VM. 

## script kvm_usb:
> Ce script rassemble les actions de `iommu_group.sh` et les sous-commendes de recherche `lsusb` et `egrep` de manière ordonnée.
(peut être certainement amélioré)

## Gamme KVM Roline (à titre indicatif) :
https://www.ebay.fr/itm/ROLINE-DisplayPort-USB-2-0-KVM-Switch-1-User-2-PC/273386897896?hash=item3fa72101e8:g:iCgAAOSwEPtZZHK7