Administrace komentářů

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ěť).