PCI passthrough - Xorg a windows na jednej grafike (vyřešeno)

Chapes to spatne. PCI passthrough funguje na mnohem nizsi urovni nez Xorg, musel bys killnout vsechno co pouziva grafiku (tj vcetne virtualnich textovych konzol atd) a ovladaci grafiky rict at se unbind-ne z daneho PCI zarizeni, jestli to podporuje - jestli ne tak komplet unload modulu grafiky.

PCI zarizeni ktere prodavas virtualni masine musi byt komplet volne, bez ovladace ktery by ho pouzival (logicky..). Teoreticky bys to mohl zkusit naskriptovat nebo neco, ale 1) je to vopruz, a 2) stejne bys potreboval vzdalenou konzoli na testovani. Jo a Xorg grafiku neinicializuje, to dela ovladac v jadre, uz nejakej patek...

Nejjednodussi je mit 2 grafiky a hlavne HW (CPU + MB) co to podporuje. Mam to rozbehane na svym AMDcku s QEMU, ale jestli to chodi na beznych Intelech netusim - Intel obvykle z jednoho kremika udela asi tricet CPU s ruzne povypinanymi flagy, takze buchvi...

12.1.2017 15:27 sysel
Rozbalit Rozbalit vše Re: PCI passthrough - Xorg a windows na jednej grafike

Tak, tak: sběrnice (plural) PCI, používané v architektuře i386/amd64, umožňují předání kompletního zařízení, které je přes PCI připojené, virtuálnímu stroji (VM = Virtual Machine) za splnění následujících podmínek:

- motherboard podporuje iommu*) (nevím jak lze zjistit před koupí) - CPU podporuje iommu (něco leze vygooglit; z poznámek pod čarou lze soudit, že Intel core iX nepodporuje iommu v řadě procesorů iXnnnnK - podstatné je to "K" na konci) - linuxové jádro podporuje iommu (kernel >3.9, ale lepší šance dává kernel >4), nezapomenout, pokud si kernel kompilujete sami - nutné jsou dvě grafické karty (vysvitne později) - jádro je nutné spustit s parametrem "amd_iommu=on" (popřípadě "intel_iommu=on" ) - jádro je zkompilováno s moduly "vfio-pci", které pak za běhu musíme přidat - grafická karta, určená pro VM, se musí odpojit od všech modulů (driverů) jádra (buď se její ovladač přidá na blacklist modulů nebo lze provést pci-unbind) - takto je nutné odpojit všechny PCI zařízení (karty), náležející do stejné iommu_group (skupiny, kterou IO memory management spravuje společně) !! pokud se ve skupině nachází "PCI Host bridge", nelze tuto skupinu odpojit, protože PCI Host bridge je používán i pro připojení jiných skupin a jádro jej neuvolní, zato PCI Bridge uvolnit lze, ale následky nejsou predikovatelné - již odpojená PCI zařízení, která chceme předat VM (pouze ta, která chceme používat ve VM) je nutné připojit k "dudlíkovému" driveru "vfio-pci"

Po této náročné přípravě (lze najít celkem dobré skripty, které to celé provedou) je potřeba správně nastavit parametr "-device vfio-pci,..." v spouštěcí příkazové řádce qemu. Protože je virtuálnímu stroji předaná kompletní PCI grafická karta, linux již na ní nemůže zobrazovat ani Xwindow ani terminálovou konsoli. Jistě, opravdovému linuxáři by to nevadilo a připojil by se k počítači po síti přes ssh, nakonec i Xwindow umožňují připojení přes síť, ale pro běžného uživatele by to znamenalo definitivní ztrátu kontroly nad Linuxem. A bez té by nebylo možné ani vrátit grafickou kartu po ukončení virtuálního stroje zpět pod ovladače kernelu ani linux korektně vypnout.

Tím však problémy zdaleka nekončí: - zhruba od poloviny 2016 nVidia provedla zásadní podraz na uživatele virtualisovaných OS MSWindows, protože ve svých nejnovějších driverech provádí detekci běhu ve virtuálním stroji a pokud shledá test pozitivním, driver se znefunkční (račte hledati "error 43 + BSOD"). Rovněž zmizely z internetu všechny starší nVidia drivery a kdo dosud nevyhodil instalační DVD nemá vyhráno, protože windowsy mohou bez jeho vědomí driver změnit v rámci medvědí služby windows-update. Panují obavy, že AMD/ATI již podniklo podobné nepěkné kroky při přechodu z driveru Catalyst na Crimson. Existují více či méně úspěšné workarroundy vycházející ze snahy lépe skrýt skutečnost, že systém běží ve virtuálním stroji, ale to je velmi obtížné provést, mj. i vzhledem k odlišným sadám a chování virtualisačních instrukcí v ring -1 a ring 0 u AMD a Intel. BTW údajně hlavním důvodem nVidie k provedení takovéhoto bezpredsedentního zásahu do práv svých řádných zákazníků, který porušuje i její vlastní licenční ujednání, byl fakt, že sama vlastně vyrábí jen několik málo skutečně odlišných čipů, které s různými cenami prodává pouze s jiným vybavením pamětí a konektory, což se v systému projeví různými id-Vendor/id-Product signaturami. Pokud šikovný hacker při předání levné GPU MSWindows hostu zamaskuje původní označení a podvrhne jiné, které odpovídá kartě s typově stejným čipem, ale z podstatně dražší řady, podvedený driver aktivuje i funkce, za které zákazník, dle názoru nVidie, nezaplatil, ale čipy je umožňují. Vzhledem k tomu, že o takové podvodné využití "nezaplacených" funkcí mají zájem především horníci bitcoinů, pro něž je cenový rozdíl v řádu 150 tisíc korun velmi zajímavou pobídkou, je hromadné potrestání všech uživatelů grafických karet námět na jednání evropské komise. Na vině je ovšem i samotná nVidia, která si má svá tajemství lépe a korektně střežit. Z jiného úhlu pohledu nVidia vpodstatě usilovně podvádí zákazníky, kterým prodává sportovní auta s omezovačem rychlosti pro jízdu v obytné zóně. Inu, kurvítka mohou být i softwarová.

Takže výsledkem je, že se mi usilovným bojem se záludnostmi hardwaru, kernelu, OS i driverů, podařilo nalézt bezproblémovou cestu k instalaci dedikované grafické karty do linuxového guesta (linux běžící ve virtuálním stroji), ale s MSWindows se po překonání jedněch překážek objeví jiné problémy. Zprovoznil jsem sice GPU AMD R7 250 ve virtualisovaných MSW10 na stroji s CPU AMD FX 9590 na Motherboardu s čipsetem AMD990/950, avšak pouze s driverem Catalyst dodaným spolu s kartou, ale neodvažuji se VM připojit k Internetu, protože hrozí neustále update systému i driverů a tudíž i zhroucení OS MSW. S nVidií jsem se o passthrough ani nepokusil, zato jsem úspěšně rozchodil připojení grafiky na APU AMD A10 Godavari (pro hostinský linux je využívaná stará nVidia GX6600), stabilně bohužel jen s Linuxovým hostem. S hostujícím MSWindows je to stále stejné - systém si nainstaluje driver ale během instalace si z internetu stáhne aktualisaci a po restartu zhavaruje.

Myslím, že zájem o virtualisaci začíná narůstat a stálo by za úvahu, vytvořit nějaké čs. fórum. Qemu - KVM je linuxový projekt, který se velmi dynamicky rozvíjí (zvláště přispěním RedHet vývojářů) a kromě nepopiratelných výhod OpenSource má v některých ohledech velký náskok oproti jiným, zdánlivě uživatelsky příjemnějším virtualisérům (VBox, VMware ...)

Poznámka k mnohem výše zmiňovanému předání USB ve VirtualBoxu. Zde se nejedná o skutečné passthrough, protože o to by šlo jen v případě předání celého PCI USB řadiče. Zpřístupnění konkrétního USB zařízení dochází tunelováním skrze standardní ovladače linuxového kernelu (zajištuje KVM). Rozdíl se pozná snadno - pokud použijete kupř. USB GSM modul, který se zpočátku přihlásí v MSWindows jako CD s instalátory, provede kontrolu, zda jsou ovladače nainstalované a pak pošle do USB kanálu příkaz k uvolnění GSM modulu, který se následně objeví jako nové USB zařízení s jinou bus adresou a pochopitelně i s jinou signaturou id-Vendor/id-Product, virtualisované MSWindows toto nové zařízení nevidí, dokud uživatel nové zařízení do VM ručně nepřidá. V případě skutečného předání PCI zařízení virtuálnímu stroji již do komunikace mezi vitálním OS a zařízením kernel nemůže vstoupit, zatímco v případě tunelování lze USB komunikaci snadno odposlechnout nebo filtrovat (modifikovat). Rovněž rychlost, která je zvláště v případě GPU klíčovým parametrem, je v případě přímého přístupu virtualisovaného OS prakticky neomezovaná kernelem hostinského OS a testy uvádějí výkonnost takto provozovaných virtualisovaných strojů, určených především k "paření" her, přes 97% výkonnosti téhož OS provozovaného na témže hardwaru přímo. Při tunelování USB není rychlost tak kritická, protože ji může zbrzdit i jiná příčina než kernel - například pomalá periferie ve stejném USB HUBu.

*) IOMMU je obdoba MMU tedy velmi nepřesně projekce logických adres (generovaných instrukcemi CPU) do fysického adresového prostoru. Jen se jedná o prostor IO adres, které jsou na architektuře AMD/Intel oddělené od standardního paměťového prostoru (není tomu tak u jiných architektur, kupř. kdysi velmi úspěšná řada CPU Motorola 68000 používala tzv. memory maped IO, čili IO zařízení využívala stejný adresový prostor jako paměť).

Dotaz: PCI passthrough - Xorg a windows na jednej grafike

Odpovědi