- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A workaround az, hogy nem hirdeti a megfelelő képességet, így a guest nem fogja őket használni:
https://lore.kernel.org/r/all/20241105160234.1300702-1-superm1@kernel.o…
Viszont ha ennek ellenére a VM-ben levő kernel mégis használja ezeket az utasításokat, ugyanúgy rebootolhatná a hostot?
(Mondjuk nem tudom pontosan, mire jó ez a két utasítás, lehet, hogy csak a host tudja ezeket használni, bár nested VM-nél a guest is egy host).
- A hozzászóláshoz be kell jelentkezni
Kicsit dejavu érzésem van a Zen1-es "performance marginality" problémára.
Fizikailag ugyanaz az IC van az EPIC-ekben, mint a desktop Ryzenben. Értem én, hogy a Ryzen-en "eleve nem volt támogatott" a nested VMSAVE/VMLOAD, de amint az látható, le volt implementálva és az EPIC-en továbbra is támogatott. Ezekszerint az AMD-nél házon belül azért valahogy tudták erre tesztelni és binnelni a lapkákat. Csak szokás szerint lapítottak róla, hogy a processzor bizonyos szempontból "kishibás", de ez nem elég indok arra, hogy letiltsák a problémás feature biteket.
Az az érzésem, hogy itt azért át van esve a ló túlsó oldalára. Értem én, hogy ők "nem olyanok", mint az Intel, akik teljesen működő feature-öket piac-szegmentálási céllal tiltanak le, de ha házon belüli teszteléssel tudják, hogy bizonyos feature tényleges instabilitást okoz, akkor a válogatásnál "rossz kupacba" került lapkáknál azért mégiscsak jobb ötlet lenne letiltani...
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
akkor a válogatásnál "rossz kupacba" került lapkáknál azért mégiscsak jobb ötlet lenne letiltani
Le volt tiltva, csak nem fixen a hardverben, hanem a firmware lett volna érte felelős.
https://lore.kernel.org/r/all/20241105160234.1300702-1-superm1@kernel.o…
Több CPU feature is létezik, amit a firmware kontrollál így vagy úgy. (Nekem a közelebbi tapasztalatom ezzel az volt, amikor nested vmx-hez az L1 VCPU-kon az L1 firmware-ben kellett MSR-t reszelni, hogy az L1 kernel aztán elhiggye, hogy a VCPU-k tudnak vmx-et, és így hajlandó legyen L2 guest-eket létrehozni: https://bugzilla.tianocore.org/show_bug.cgi?id=86.)
A szálban Sean Christopherson és Mario Limonciello kicsit elbeszélnek egymás mellett. Christopherson azon nyargalászik, hogy "a CPU bugos", Limonciello meg azt mondja, hogy "igen, de nem számít, mert amit az OS lát a CPU-ból, az by-design a BIOS-tól függ, és ez BIOS bug". Szerintem Limonciello-nak van igaza, mert x86_64 platformot lehetetlen firmware nélkül felhúzni (sajnos).
Most kényszerűségből a CPU és firmware bug-ot a kernelben kerülték meg. Gyakran nem azt javítjuk, amit kellene, hanem amit praktikus :(
- A hozzászóláshoz be kell jelentkezni
Ezt nagyvonalakban vágom.
Ami nem tiszta nekem, hogy a "Le volt tiltva" állítás honnan jön és valójában mit takar? Én annyi utalást találtam a threadben, hogy
"
These Zen4 SoCs advertise support for virtualized VMLOAD/VMSAVE
in some BIOS versions but they can lead to random host reboots."
Nekem arra utal (úgy hangzik) ez a megfogalmazás, mintha nem regresszióról volna szó, hanem inkább alaplap-vendoronként volna eltérő. De persze fene tudja, bele lehet magyarázni mindkét értelmezést... Talán a BIOS szó használata az ami nekem az alaplapgyártó fele tereli az értelmezést. És az a tény, hogy kernelben kell workaroundolni, nem lehet pl mikrokód frissítésre rábízni (amit a kernel is megtehet on the fly, nem kell feltétlen az alaplapgyártóra várni).
Átfogalmazva: én lényegében azt kérem számon, hogy ezt miért nem az AGESA firmware blob csinálja.
Afelett az AMD-nek teljes kontrollja van, az alaplapgyártók nem piszkálhatnak bele, garantáltan egységes. Az AMD házon belül ismerhette a hibát (feltételezhetjük, hiszen binnelnek rá), de az alaplapgyártó nem feltétlen tudja, hogy ez "komoly", és nem tesznek szívességet a felhasználónak azzal, ha mégsem tiltják le.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
hanem inkább alaplap-vendoronként volna eltérő
Szerintem is erről van szó; én rögtön így értelmeztem.
miért nem az AGESA firmware blob csinálja [...] az alaplapgyártók nem piszkálhatnak bele
Ez nagyon jó kérdés; én nem is gondoltam rá. Ezzel kapcsolatban kevés infóm van, mert zárt forrású ill. fizikai (nem virtuális) firmware-rel alig dolgoztam. Csak annyit tudok (hallomásból), hogy mire az x86_64 firmware végül rákerül az alaplapra, egy nagyon hosszú "supply chain" végén áll, és egy csomó minden félrecsúszhat. Az ellátási lánc hosszával kapcsolatban két közvetett bizonyítékom van:
- Amikor találtam olyan biztonsági hibákat az edk2-ben, amiből CVE lett, és fizikai firmware-eket is érintett, akkor irtózatosan hosszú ideig kellett várni az embargó feloldására, mert a fizikai firmware vendoroknál minimum fél évig, de inkább egy évig tart a javítás beépítése, tesztelése, és leszállítása. Ja és többnyire nem is hajlandóak egyeztetni, amikor az elején az ember az embargóról tárgyalni próbál.
- Mind a Microsoft, mind az Intel ellene van a git monorepo-nak (amit pl. a Linux-nál megszokhattunk, illetve open source fejlesztőként magunk is kedvelhetünk), fizikai firmware-ek tekintetében. Mindkét cég (de a Microsoft különösen) azt szereti, amikor több külön repo van, és abból "cherry pick"-elnek feature-öket, chipset ill. device driver-eket stb; a verziózást pedig külön python infrastruktúrával végzik, nem bízzák a git-re. Linuxos háttérrel ez észveszejtően körülményes (mi nyilván azt akarjuk, hogy minden legyen egy repo-ban; például a git-bisect így tud jól működni); ott viszont, ahol 15 proprietary beszállító bináris komponenseit kell integrálni, ennek valószínűleg van létjogosultsága.
El tudom képzelni, hogy adott platformon simán rossz verziójú AGESA-t építettek be. Vagy hogy valamilyen oknál fogva nem az AGESA állítja be a CPU-t, és a platform chipset kódjában egyszerűen elvétették a (nem is feltétlenül nyilvános) CPU manual-ból ezt a részt.
Én arra lennék kíváncsi, hogy a linuxos patch végül pontosan azokon a CPU-kon tiltja-e le az L1 VMLOAD/VMSAVE-et, ahol a firmware-nek is kellett volna. A patch a "cpuinfo_x86.x86_model" mezőt vizsgálja; elépzelhetőnek tartom, hogy a firmware-nek ennél "kifinomultabb" (részletesebb) vizsgálatot kellett volna végeznie. Vajon a linuxos patch letiltja a CPU-k egy olyan részhalmazán is a feature-t (az egyszerűség nevében), ahol nem kellene? Sosem fogjuk megtudni, gondolom :)
- A hozzászóláshoz be kell jelentkezni
Egyrészt elképzelem napi szinten micsoda fingerpointing game-ek mehetnek a háttérben a firmware beszállítók között... :)
Az AGESA lényege pont az lenne, hogy az AMD kezében van a "végső döntés", hogy mi megy a firmware-be. Lehet (biztos), hogy vannak benne 3rd party részek, de az utolsó szó az övék.
Elvileg van valami kötelezettség, hogy X évig kell az alaplap vendornak szállítania az új upstream agesa-val bios update-et. De tény, hogy néha fél éveket ülnek rajta.
Azt viszont szerintem ki lehet jelenteni, hogy az alaplapgyártók szeretnek úgy mekülönböztető featureöket csinálni, hogy egy-egy "hivatalosan nem támogatott" funkció náluk valahogy mégis bekapcsolható. Lásd AMD-nél nemrég a memóriavezérlő default overvoltolás, amivel az alaplapgyártók ki tudták tolni a hivatalosan támogatotton túlra a memória órajeleket. Csak éppen túltolták és elkezdtek leégni a processzorok tőle. Ugyanez Intel oldalon az turbo boost power cap limit végtelenre állítása volt, ugyanilyen következményekkel.
Rosszabb esetben ezek defaultból be is vannak kapcsolva.
Nekem kicsit erre emlékeztet ez a dolog. Mintha szándékosan nem implementálnák a BIOS-ban a cpu flagek lemaszkolását, mert így az ő alaplapjukban "többet tud" a processzor.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
a kínai barkácsolók tudhatnak mesélni, amikor hivatalosan nem támogatott, több generációval különbözőnek szánt memóriát / cpu-t / chipsetet kombinálnak :D
- A hozzászóláshoz be kell jelentkezni