Tuskin tehdään yhtään mitään, varsinaisia haavoittuvuuksiahan ei löydetty.
Ja kyse ei varsinaisesti ole way-predictorista joka olisi kytkettävissä pois päältä vaan L1-cache on tagattu vain tuolla microtagilla.
Olet näköjään edelleenkin pihalla siitä, miten välimuistin kirjanpito toimii.
Ja näistä Zenin microtageista:
AMD Family 17h software optimization manual sanoi:
The L1 data cache tags contain a linear-address-based microtag (utag) that tags each cacheline with the linear address that was used to access the cacheline initially. Loads use this utag to determine which way of the cache to read using their linear address, which is available before the load's physical address has been determined via the TLB.
Edelleenkin; se, että välimuisti
tagattaisiin millään muulla kuin täysikokoisella tagillä johtaisi siihen, että ei tiedettäisi, mitä dataa siellä välimuistissa on, ja luettaisiin sieltä väärän osoitteen dataa. Siellä on
pakko olla jossain ihan täysimittainen tag jotta tiedetään varmuudella, että data jota välimuistista ladataan on varmasti se oikea data.
Yritin tätä selittää sinulle jo joskus kauan sitten, mutta ei tunnu uppoavan sitten millään.
Tuon microtagin merkitys on nimenomaan toimia way predictionina; Ensin ladataan kaikkein kahdeksan wayn microtagit oikeasta indeksistä (indeksi on osoitebitit 6-11, eli ollaan neljän kilotavun sisällä, eli siihen riittää virtuaaliosoite) , ja niiden perusteella tarkastetaan osuma (verrataan microtagia hashiin koko virtuaaliosoitteesta).
Mikäli löytyy osuma jostain waystä, valitaan se way, ladataan rinnakkain siitä waystä data sekä että varsinainen tagi. Ja siinä vaiheessa kun nämä on saatu ladattua, on myös virtuaaliosoitteen muunnos fyysiseksi osoitteeksi valmis, ja voidaan tehtä tarkastus täyteen fyysisillä osoitteilla toimivaan tagiin.
Way predictor on aikaisemmin ollut vihje jonka mukaan cachesta on tarkastettu vihjeen osoittama linja ensin ja loput jos ei tullut osumaa. Microtagilla AMD:n tapauksessa cache-setistä tarvitsee tutkia maksimissaan vain 8 bittiä jokaisesta setin 8:sta linjasta joten kaikki linjat tutkitaan kerralla ja hudin tulessa siirrytään L2:een.
Tässä nyt menee välillä jotain oikein, tosin syy on ymmärretty väärin.
Zenin L1:n rakenne tosiaankin on sellainen, että mikäli siinä way prediction sanoo, että dataa ei löydy, niin sitten mennään kerralla L2een asti, ja ladataan data sieltä, eikä koskaan yritetä ladata sitä muista L1-wayistä. Ja syy tähän on se, että tilanteet joissa se data löytyisi jostain muusta L1-waystä ovat äärimmäisen harvinaisia, johtuen mm. seuraavasta rajoitteesta:
AMD optimization manual sanoi:
It is also possible for two different linear addresses that are NOT aliased to the same physical address to conflict in the utag, if they have the same linear hash. At a given L1 DC index (11:6), only one cacheline with a given linear hash is accessible at any time; any cachelines with matching linear hashes are marked invalid in the utag and are not accessible
Eli siis, meillä on neljä mahdollista skenaariota:
1) Halutun osoitteen data on L1-välimuistissa siinä wayssä mikä ennustettiin. Kaikki hyvin ja nopeaa. Hyvin yleinen tilanne.
2) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa ja way prediction sanoo että sitä ei siellä ole. Tällöin pitää ladata se L2-välimuistista (seuraavaksi yleisin tilanne). Kaikki hyvin mutta tulee se ~8 kellojakson hidastus kun data ladataan L2-välimuistista (tai vielä pidempi, jos sitä ei ole sielläkään). Seuraavaksi yleisin tilanne.
3) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa, mutta way prediction ennustaa väärin, ja sanoo että se löytyy waystä, jossa tosiasiassa on jotain muuta(false positive). Tämä tilanne huomataan siinä vaiheessa, kun ne oikeat täysikokoiset TAGit tarkastetaan, ja ne ei matchääkään sen fyysisen osoitteen kanssa, minkä osoitteenmuunnos virtuaalisesta fyysiseksi antoi antoi, ja tässä vaiheessa käynnistetään L2-access datan hakemiseksi sieltä.
Jos niitä täysikokoisia TAGejä ei olisi ja tarkastettaisi, tässä tapauksessa ladattaisiin kiltisti mitään tajuamatta väärä data
4) Softassa on mappaus samalle samaan fyysiseen osoitteeseen useammalla eri virtuaaliosoitteella, mikä mahdollistaa eri hashin samaan fyysiseen osoitteeseen. Tällöin way prediction voi antaa false negativen; Sanoa että dataa ei löydy L1-välimuistista, vaikka se tosiasiassa on siellä Tällöin se ladataan L2-välimuistista, mikä on teoriassa epäoptimaalista.
Tämä tilanne on kuitenkin hyvin harvinainen; Usealla virtuaaliosoitteella on tyypillisesti mappays samaan fyysiseen osoitteeseen lähinnä vain kun kyse on jostain nollasivuista (käyttiksen optimointi muistinkulutuksen vähentämiseksi). Ja koska tämä tilanne on hyvin harvinainen, tuo "aina kun way prediction sanoo että data ei löydy L1stä, mennään suoraan L2een" on järkevä rajoite; Se, että ruvettaisiin välissä katsomaan niitä muita L1-waytä olisi ihan turhaa haaskausta niissä yleisissä tilanteissa tämän hyvin harvinaisen tilanteen nopeuttamiseksi.
Eli jos jotain kytkettäisiin pois niin se olisi koko L1-cache.
Mutta tässä olet todennäköisesti oikeassa, että tuota way predictionia ei todennäköisesti saa kytkettyä pois päältä, koska se on niin oleellisessa roolissa siinä, että
yritetäänkö mitään edes ladata L1-välimuistista; Mitään accesseja ei Zenissä tosiaankaan tehdä L1-cacheen muuta kuin sellaiseen wayhin joka on saanut way prediction hitin.
