No, jak...
Stálo mě to hromadu času vybíráním HW, abych mohl udělat pohodlný a funkční PCI-passthrough, bez nějakých extra patchů, overridů apod.
Tenhle soupis, vysvětluje vše:
OS:
Host: Ubuntu 18.04, dm-crypt, zfs, kvm, libvirt + qemu 5.1.0
Guest: Windows Server 2019 on q35-5.1
Host Specs:
MSI X470 Gaming Pro
Ryzen 2600, 6x core, 12 threads(only 1 dedicated core(2 threads) is accessible for Ubuntu)
32GB DDR4 2666MHz
AMD Sapphire RX580 8GB
Some shitty nVidia for host graphics
Samsung 950 Pro 500GB
Samsung 960 Evo 500GB
2x WD Raid Edition 2TB
2x WD Green 2TB
Guest Specs:
Host-model libvirt setting with 5x dedicated core(10 threads), pinned, isolcpus used
20GB RAM allocated via hugepages
120GB mirror on SSD
1,7TB mirror on HDD with SSD boost(2x 120GB ZFS L2ARC cache)
3,4TB stripped HDD with SSD boost(2x 120GB ZFS L2ARC cache)
AMD Sapphire RX580 8GB via pci-passthrough, vfio-pci
Mohu poskytnout i funkční konfiguraci libvirtu, kterou používám, podporuje kde co, od funkčního trimu pro prolínání volného místa na ZFS datasetu(na Ubuntu 18.04 mám extrémně špatnou zkušenost s blokovými vdevy ZFSka, nakonec je to v rawu souboru v datasetu(možná vyřešeno, jsem línej to zjišťovat)), po poslední hyper-v featury qemu, pro pohodlný běh Windows Server 2019.
Možná by tak fungovaly i Windows 10, ale nedávno mi poslední insider-build shazoval qemu, tak jsem dále nepátral, Windows Server mám kvůli pozvolnějším aktualizacím(předpokládám méně problémů v KVM) a pohodlnosti souběžných RDP přístupů.
Jen jsem tedy nečekal, že v systému od Microsoftu, nepůjde Xbox One gamepad bez obskurní instalace ovladačů na Xbox 360 gamepad z Windows Vista. A i tak, funguje jen po USB kabelu, přes bluetooth mám kompletně smůlu.
Asi nejobskurnější případ mě potkal s Red Dead Redemption 2, kdy mi hra po Naturalist Update, hned po hlavním menu padala na 0x000005 status_access_violation.
Náhodou jsem narazil na někoho na Redditu, co poradil rekompilovat qemu, kde se nahradí stringy BXPC a BOCHS třeba na FCKS "RCKS " a upravit veškeré možné sm-bios informace, kde se nahradí string QEMU, za cokoli jiného..
Bum, ono to začalo fungovat, nevěřil jsem vlastním očím.
2. 12. 2020, 20:05 editováno autorem komentáře
Mam celkem vyhodu, ze spolupracuji s firmou, co mi tohle licencne dokaze pokryt.
Ono je to vcelku hodne primitivni https://git.my-web.xyz/milan/qemu-builds-mm/src/branch/stable-5.1.0-rdr2-fix
Nasel jsem, ze diky unikatnosti vyskytu techto stringu, by to slo udelat bez rekompilace i takto:
hexdump -ve '1/1 "%.2x"' qemu-system-x86_64 |
sed -e 's/424f4348/434f4348/g' -e 's/42585043/44585043/g' |
xxd -r -p > qemu-system-x86_64.new
Uprimne, v hlave jsem to mel hodne dlouho, ani si nedokazu vzpomenout, kdy se mi v hlave zrodila myslenka o podobnem setupu.
Myslim ze prvni verze, byla hotova za tyden od koupi HW, ale delal jsem na tom jen ve volnem case. Za 6 mesicu pouzivani jako Gaming/Work station jsem zjistil par veci, ktere kdyz jsem v konfigu libvirtu zmenil, Windows pri urcitych operacich chciply, ale po reinstallu na ten a samej nove konfigurovanej virtualni HW, funguji uz skoro.rok skvele.
Ja ti nevim, on sel lag sem, lag tam, radek v konfigu sem, radek tam. Na vse jsem prisel postupnym pouzivanim.
Ted vim jen o jedne veci, co zpusobuje micro-lagy a to jsou CCX ve starsich Ryzenech nez rada 5000(ktery ma alespon 8 jader per CCX).
Ja totiz na CPU setril a mam 2x CCX po 3 jadrech.. No a zatim nevim, jak libvirt donutit, postavit si CCX dle sebe a predstavit to systemu tak, jak chci ja.
Druha moznost je mit ve virtualu jen 3 jadra, aby nedochazelo k cache-missum na L3, ale... To uz mam radeji microlagy, nez v pripade nutnosti rebootovat Win(ale nemam pokoumane pridavani/odebirani vCPU za behu systemu, treba to taky jde).
Threadrippery inzerujú svoju topológiu vrátane NUMA cells, práve kvôli CCX. Predpokladám, že Ryzeny to robia tiež.
virsh nodeinfo
na TR1900X vypíše niečo takéto:
CPU model: x86_64 CPU(s): 16 CPU frequency: 2066 MHz CPU socket(s): 1 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 2
každý vCPU je proces v host systéme, ktorý podlieha scheduleru hosta. Pre vCPU nie je alokovaný celý procesor! No a keďže je to proces, tým pádom nástroje ako numad môžu udržiavať afinitu v rámci CCX.
Pokiaľ by to nestačilo, možno by stálo za to vyskúšať nakonfigurovať guestovi numa topológiu explicitne <numa><cell cpus="..."></numa>
.
Bohužel, Ryzen 2600 se tváří takto:
root@ryzen-main:~# virsh nodeinfo
CPU model: x86_64
CPU(s): 12
CPU frequency: 3643 MHz
CPU socket(s): 1
Core(s) per socket: 6
Thread(s) per core: 2
NUMA cell(s): 1
Memory size: 32886000 KiB
Zkusím si pohrát s tou topologií, je možné, že to nějak půjde. :-)
Mít virtuál jen na jednom CCX je řešením, nicméně příjdu o 2 jádra(4 thready), které se v době, kdy potřebuji výkon, dost hodí.
Něco o tom načtu, možná libvirt přesvědčím, aby CCX pro guesta rozdělil tak, že 3 jádra je jedno CCX, dvě jádra druhé CCX, každé má svou L3 a micro-lagy pominou..
Pokud se mi to povede, dám vědět. Asi je pravděpodobnější, že si pořídím Ryzen 5800x, kde je jen jedno CCX s osmi jádry a vůbec to nebudu muset řešit.