Vlákno názorů k článku
Intel vyzývá: neinstalujte naše záplaty
od pc2005 - Ví někdo v čem měl ten update microkódu...
-
lopata (neregistrovaný)
V čem byl problém Intel asi nikdy neřekne, nicméně Linus se k mikrokódu a souvisejícím patchům kernelu vyjádřil nějak takhle: https://lkml.org/lkml/2018/1/21/192
As it is, the patches are COMPLETE AND UTTER GARBAGE.
They do literally insane things. They do things that do not make sense. That makes all your arguments questionable and suspicious. The patches do things that are not sane.
WHAT THE F*CK IS GOING ON?
-
Zde je mnohem lepší vysvětlení, co ty patche dělají na různých architekturách místo Linusovy tirády "it's utter garbage": https://lkml.org/lkml/2018/1/22/598
-
Palo (neregistrovaný)
Presne viem, pri preklade instrukcie QFMX do mikrokodu pomocou FB LD MC BU KV dochadzalo obcas k subehu s MA MT OV PI CI bez uzamknutia registra LF ... na co ti to je? Ty poznas Intel mikrokod instruction set a sposob prekladu jednotlivych instrukcii? To je cisty bordel ktoremu ak sa nevenujes cely zivot nemas sancu vnimat. Intel to nijako nedokumentuje a nikto nevie co sa za tou prekladovou barierou skryva. Za dalsie pre rozne procesory bude ten mikrokod iny.
-
j (neregistrovaný)
Zas bych z toho nedelal raketovou vedu ... vetsina problemu na tyhle urovni je zpusobena casovanim, kazdej tik hraje roli, mno a kdyz do toho hrabnes, a nektery akce zpomalis mozna i o rady ...
To se ti pak proste stane trebas to, ze si nekde po 30 taktech ctes nejaky data, ktery se prece bezne nactou za 10-15 ... ale po uprave za trebas za 26-31. Coz muze znamenat ze na jednom z desitek tisic prubehu tyhle konkretni instrukce ti to padne nadrzku, protoze tam ty data proste nejsou.
Navic vse souvisi se vsim, takze se to muze projevovat trebas jen pri nejaky konkretni sekvenci.
-
Myslim, ze tato uvaha je "wrooong on so many levels". Inteli mikrokod nie je skolsky seriovy automat, teda aspon by nemal byt. Frontend necha x86tkove "makroinstrukcie" rozpadnut na instrukcie vnutornej mikroarchitektury. Vzhladom k tomu, aka je x86 komplikovana predpokladam, ze potom nasleduje faza optimalizacie (eliminacia load-store parov a podobnych zjavnych volovin) a potom sa to vykonava tak, ako sa vykonava nativny kod na inych out-of-order architekturach. T.j. vec sa vykona vtedy, ked su k dispozicii data. Necakal by som, ze restarty sposobuje taka trapnost ako "toto tunak trva moc dlho a data sa zaseknu na polceste". Problem bude skor v tom, ze niektora zmena za istych okolnosti meni nejaky predpoklad a nejaka cast mikrokodu potom zazenie vnutornu architekturu do necakaneho stavu z ktorej je cesta von jedine skrz restart.
Vzhladom k tomu, ze sa saha do tak fundamentalnych veci ako branch prediktor a branch target buffer su moznosti rozpadu vnutorneho stavu CPU naozaj siroke. Staci ze sa zaviedol novy flag, ktory sa na 99 miestach kontroluje a na stom mieste nie a problem je na svete.
ČLÁNKY DO MAILU