2016-08-10 46 views
5

Jak dobrze wiadomo, Intel musiał wyłączyć TSX w procesorach Haswell poprzez aktualizacje mikrokodu. Było to spowodowane błędem w implementacji TSX, który mógł dać błędne wyniki, gdyby te instrukcje były używane.Jaki jest status błędu TSL związanego z TSX SKL-105?

To, co zdaje się być mniej znane, to fakt, że istnieje najwyraźniej errata wpływająca na TSX na nowszą architekturę, Skylake. Konkretnie errata "SKL-105" tu wymienić:

http://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html

To wyraźnie stanowi, że przy użyciu TSX może prowadzić do nieprzewidywalnych zachowań systemu. Zauważa jednak, że BIOS może mieć poprawkę. Pozostaje jednak pytanie, co oznacza ta poprawka. Czy wyłącza TSX w ogóle jak "poprawkę" do mikrokodu Haswell? Googling "SKL105" nie daje żadnych wyników, więc wydaje się, że społeczność jest na ogół tego nieświadoma?

Niektórzy użytkownicy zauważyli funkcję TSX coraz „steathily” wyłączone (ale pozornie będąc nieświadomy errata powyżej):

https://www.reddit.com/r/hardware/comments/44k218/intel_disables_tsx_transactional_memory_again_in/

To dziwne, jeśli dotyczy tylko niektóre warianty procesorów, ponieważ można by przypuszczać, że wszyscy dzielą tę samą mikroarchitekturę, a tym samym będą w równym stopniu dotknięci tym błędem.

Innymi słowy, taka "naprawa" mikrokodu mogłaby działać, a która mogłaby być jeszcze bardziej ukradkowa: Przypuszczam, że byłoby możliwe wykonanie aktualizacji mikrokodu, która nadal naraziłaby na obecność TSX (sprawiając wrażenie, że jest to funkcja nadal był włączony), ale zastąpiłby implementację nowych instrukcji TSX "fikcyjnymi implementacjami", które w rzeczywistości nigdy nie byłyby w stanie usunąć tych blokad i zasadniczo po prostu wykonały kod w staroświecki sposób, unikając w ten sposób błędu, ale także powodując poprawę wydajności TSX oferta. Jedynym sposobem ustalenia, czy tak się stało, są pomiary wydajności.

Ktoś ma więcej informacji na temat statusu TSX w Skylake? W każdym razie jest dziwne, że nie ma więcej informacji i trzeba odgadnąć, co jest dotknięte, a co nie. I rzeczywiście, jeśli funkcja jest bezpieczna w użyciu.

Mam 6700 K i funkcja jest nadal dostępna. Ale zależy to również od tego, czy producent systemu BIOS podjął aktualizacje mikrokodu, a także czy nie zmierzyłem wydajności, więc nie mogę wykluczyć, że nadal można go było wyłączyć. poprzedni akapit.

+1

Nawiasem mówiąc, należy pamiętać, że SKL-054 (w tym samym arkuszu erraty) również dotyczy TSX. Ten sam status/komentarze/pytania w moim wpisie dotyczącym SKL-105 mają również zastosowanie do SKL-054. – Morty

Odpowiedz

5

Z tego co mi wiadomo, jest on przypuszczalnie ustawiony na najnowszym publicznym pakiecie aktualizacji mikrokodu z 2016-07-14. W przypadku Skylake będzie to wersja 0x9d/0x9e mikrokodu Base Skylake (sygnatury procesorów 0x406e3 i 0x506e3).

Ta nowa errata TSX wydaje się być obecna również na Broadwell. Zakładam, że został on również naprawiony przez nową partię aktualizacji mikrokodowych Broadwell- *, które zostały opublikowane wraz z nowymi aktualizacjami mikrokodu Skylake.

W przypadku systemu Linux, który aktualizuje mikrokod przez dane wysyłane przez program rozruchowy, zastosowanie aktualizacji jest trywialne i jest już dostępne w większości (poważnych) dystrybucji. W przypadku systemu Windows musisz zaatakować dostawcę systemu, aby uzyskać aktualizację EFI/BIOS.

Niestety, nie mam możliwości przetestowania TSX w najnowszym mikrokodzie Skylake/Broadwell, aby sprawdzić, czy jest to blokada blokująca lub "zawsze się nie udaje". Jeśli chodzi o wyłączanie TSX, musisz zrozumieć, że ma on rzeczywisty wpływ na skuteczność L3 (to nie jest przychodzą za darmo!) i poboru mocy, byłoby sensownym wyłączenie TSX przez BIOS na czymkolwiek z mniejszym L3.

Co ciekawe, informacje na temat "bita kurczaka" TSX nie są publiczne, nie mamy pojęcia, jak je wyłączyć (lub ponownie włączyć).

+1

Czy masz jakieś odniesienia do TSX, używając zasilania po włączeniu, nawet jeśli nie jest używane? A także dla zmniejszenia skuteczności L3? Chciałbym przeczytać więcej. –

+0

W dokumentach dotyczących działania TSX wyjaśniono, że dzieli pamięć podręczną, aby zachować stan transakcji w celu wycofania. Nie jest to problem, który ktokolwiek poza najbardziej agresywnym HPC zauważyłby na Xeonach, ale mniejsze układy mają o wiele mniej pamięci podręcznej. Dodatkowe zużycie energii przez samą funkcję jest prawdopodobnie zbyt małe, aby można było sobie z tym poradzić, ale w trakcie transakcji żaden z trybów niskiego poboru energii, które usuwają pamięć podręczną, nie może zostać uruchomiony, więc albo Intel musi przerwać transakcję, albo zablokować zmianę trybu. Nie mam referencji pod ręką, szukam papierów TSX, a także papierów analizy bezpieczeństwa SGX ... – anonymous

+2

Z tego co przeczytałem, dzieje się to w L1 rdzenia wykonującego transakcję. Według Davida Kantera [HSW writeup] (http://www.realworldtech.com/haswell-cpu/5/), nawet L2 nie jest transakcyjna, nie mówiąc już o L3. Mówi, że jego spekulacje na temat tego, w jaki sposób Haswell to wdroży, były poprawne; że używa dodatkowych bitów dla każdej linii pamięci podręcznej L1. (Zobacz jego wcześniejsze artykuły: http://www.realworldtech.com/haswell-tm/ oraz http://www.realworldtech.com/haswell-tm-alt/). Kanter twierdzi, że TM jest jednym z jego głównych zainteresowań zawodowych, więc prawdopodobnie nie ma w tym żadnych poważnych błędów. –