7 ms·

https://lkml.org/lkml/2023/2/22/982 https://lkml.org/lkml/2023/2/22/982 Seems to be a known errata which was fixed by a microcode update

sp332 4y ago
https://mobile.twitter.com/taviso/status/1630695259935219713 https://mobile.twitter.com/taviso/status/1630695259935219713 Apparently some Ryzen models have no fixed microcode available. You can boot with clearcpuid=xsaves as a workaround, probably at some performance cost.
- stefan_ 4y ago
  As I understood the email thread, they do have microcode updates but they weren't actually released anywhere but in some crusty vendors BIOS update, so you can only get them if someone fished them out of there. i.e. thats what this repo seems to be: https://github.com/platomav/CPUMicrocodes https://github.com/platomav/CPUMicrocodes
  - deleted 4y ago
    [deleted]
  - caf 4y ago
    The person who reported the bug in their family 0x17 model 0x60 Renoir SoC said it wasn't fixed even by the latest BIOS-supplied microcode available.
    - lathiat 4y ago
      The reality is most consumer motherboards rarely post updates especially after the first year or so. You'll tend to get updates to fix CPU compatability for newer CPUs if the motherboard is still on sale, but otherwise most long term BIOS updates seem largely to be from enterprise vendors (Dell, Lenovo, etc) and much less common on consumer or gaming type hardware. I think most people rely on the operating system to (amazingly) hot patch it during boot. Intel and AMD both publish them and are integrated regularly into most distros (and the linux-firmware git tree). Surprising/weird that they haven't released the Renoir ones. Also seems Tavis had a bug where Debian wasn't applying them on boot for one reason but didn't give details. Wonder what it was.
      - Semaphor 4y ago
        > The reality is most consumer motherboards rarely post updates especially after the first year or so I can’t confirm that. My current board is the MSI X570-A PRO. First BIOS was 2019-06-20, the latest 2022-08-19. And that’s still updating versions and settings. After 3 years, and I’m expecting more. This has also been my experience with other boards. MB updates tend to last several years.
      - kllrnohj 4y ago
        You have that like exactly backwards. You'll get a lot fewer bios updates from Dell or Lenovo than you will from MSI, Asus, Gigabyte, etc.. consumer / gaming motherboard lines. My 5 year old X370-F GAMING is still getting BIOS updates. Others, like MSI, practically forced AMD to continue issuing AGESA updates for X370 & X470 chipsets after AMD had announced official end of support - they got AMD to change course and add new CPU support to those old chipsets. But otherwise all the major consumer / gaming motherboards pick up new AGESA updates quickly & consistently, even when they're EOL platforms.
      - oynqr 4y ago
        I have a really old GA-Z87X-UD5H, it got NVME support five years after release. Probably by accident, but still.
  - jabl 4y ago
    Since this is about Linux, the microcodes it applies on boot can be found in the linux-firmware repository. For AMD microcode, in particular https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... However, for some unexplainable reason AMD doesn't tend to update the microcodes in that repo particularly often, leaving it up to BIOS vendors and users updating their BIOS.
- amluto 4y ago
  No obvious reason for a performance cost. If XSAVEC is available, performance should be essentially identical to XSAVES.
- BoardsOfCanada 4y ago
  I had to look up the difference between XSAVES and XSAVEC: "Execution of XSAVES is similar to that of XSAVEC. XSAVES differs from XSAVEC in that it can save state components corresponding to bits set in the IA32_XSS MSR and that it may use the modified optimization."
  - caf 4y ago
    In this case it seems like the "modified optimization" is where the bug lies.
caf 4y ago
It's erratum #1386 (see https://www.amd.com/system/files/TechDocs/56323-PUB_1.00.pdf https://www.amd.com/system/files/TechDocs/56323-PUB_1.00.pdf ): The XSAVES instruction may fail to save XMM registers to the provided state save area if all of the following are true: • All XMM registers were restored to the initialization value by the most recent XRSTORS instruction because the XSTATE_BV[SSE] bit was clear. • The state save area for the XMM registers does not contain the initialization state. • The value in the XMM registers match the initialization value when the XSAVES instruction is executed. • The MXCSR register has been modified to a value different from the initialization value since the most recent XRSTORS instruction.
pabs3 4y ago
Linux folks also plan to apply a workaround for systems running old microcode.
alex_duf 4y ago
As an outsider from the hardware world, I find it astounding that it's possible to fix the behaviour a CPU instruction by changing code. (assuming I understand correctly) In my mind a CPU instruction is hardwired on the chip, and it blows my mind that we keep finding workarounds to already released hardware. Maybe someone could dumb that down for me?
- fhars 4y ago
  The CPU only pretends to be a CPU. In reality, it is a small datacenter comprised of several small special purpose computers doing all the work. I gave up understanding CPUs in depth by the time I read an introducion to Intel's then-new i860 CPU in the April issue of a magazine and it turned out to be a real device.
  - psychphysic 4y ago
    Best explanation in my opinion. Almost like a CPU has an JIT emulator for x86.
    - yvdriess 4y ago
      ucode cracking is relatively straightforward, I wouldn't call it a JIT. https://intelxed.github.io/ref-manual/ https://intelxed.github.io/ref-manual/ It's more like an intepreter for x86, seeing as it is actually executed on a dataflow architecture.
      - psychphysic 4y ago
        Macro op fusion is more what I had in mind when I called it JIT and not interpretation. Not sure what the distinction is but that's where it is to my mind
        yvdriess 4y ago
        It's true that the distinction is a bit vague, the term JIT is overloaded to enough that it stopped being a useful technical term. Compared to 'JVM JIT' or 'LuaJIT': there is no instrumentation to detect what is hot or not. The CPU frontend will crack x86 instructions into micro-ops, while looking for some patterns to merge certain instructions or uops into larger micro-ops. The micro-coded instructions (like many of the legacy instructions) are likely just lookups. Most of this is my speculation, mind. Modern CPU frontends are still kind of a black magic box to me, but I think they are limited by relatively simple transformations by virtue of being on the critical execution path.

sp332 4y ago

https://mobile.twitter.com/taviso/status/1630695259935219713 https://mobile.twitter.com/taviso/status/1630695259935219713 Apparently some Ryzen models have no fixed microcode available. You can boot with clearcpuid=xsaves as a workaround, probably at some performance cost.

stefan_ 4y ago
As I understood the email thread, they do have microcode updates but they weren't actually released anywhere but in some crusty vendors BIOS update, so you can only get them if someone fished them out of there. i.e. thats what this repo seems to be: https://github.com/platomav/CPUMicrocodes https://github.com/platomav/CPUMicrocodes
- deleted 4y ago
  [deleted]
- caf 4y ago
  The person who reported the bug in their family 0x17 model 0x60 Renoir SoC said it wasn't fixed even by the latest BIOS-supplied microcode available.
  - lathiat 4y ago
    The reality is most consumer motherboards rarely post updates especially after the first year or so. You'll tend to get updates to fix CPU compatability for newer CPUs if the motherboard is still on sale, but otherwise most long term BIOS updates seem largely to be from enterprise vendors (Dell, Lenovo, etc) and much less common on consumer or gaming type hardware. I think most people rely on the operating system to (amazingly) hot patch it during boot. Intel and AMD both publish them and are integrated regularly into most distros (and the linux-firmware git tree). Surprising/weird that they haven't released the Renoir ones. Also seems Tavis had a bug where Debian wasn't applying them on boot for one reason but didn't give details. Wonder what it was.
    - Semaphor 4y ago
      > The reality is most consumer motherboards rarely post updates especially after the first year or so I can’t confirm that. My current board is the MSI X570-A PRO. First BIOS was 2019-06-20, the latest 2022-08-19. And that’s still updating versions and settings. After 3 years, and I’m expecting more. This has also been my experience with other boards. MB updates tend to last several years.
    - kllrnohj 4y ago
      You have that like exactly backwards. You'll get a lot fewer bios updates from Dell or Lenovo than you will from MSI, Asus, Gigabyte, etc.. consumer / gaming motherboard lines. My 5 year old X370-F GAMING is still getting BIOS updates. Others, like MSI, practically forced AMD to continue issuing AGESA updates for X370 & X470 chipsets after AMD had announced official end of support - they got AMD to change course and add new CPU support to those old chipsets. But otherwise all the major consumer / gaming motherboards pick up new AGESA updates quickly & consistently, even when they're EOL platforms.
    - oynqr 4y ago
      I have a really old GA-Z87X-UD5H, it got NVME support five years after release. Probably by accident, but still.
- jabl 4y ago
  Since this is about Linux, the microcodes it applies on boot can be found in the linux-firmware repository. For AMD microcode, in particular https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... However, for some unexplainable reason AMD doesn't tend to update the microcodes in that repo particularly often, leaving it up to BIOS vendors and users updating their BIOS.
amluto 4y ago
No obvious reason for a performance cost. If XSAVEC is available, performance should be essentially identical to XSAVES.
BoardsOfCanada 4y ago
I had to look up the difference between XSAVES and XSAVEC: "Execution of XSAVES is similar to that of XSAVEC. XSAVES differs from XSAVEC in that it can save state components corresponding to bits set in the IA32_XSS MSR and that it may use the modified optimization."
- caf 4y ago
  In this case it seems like the "modified optimization" is where the bug lies.

caf 4y ago

It's erratum #1386 (see https://www.amd.com/system/files/TechDocs/56323-PUB_1.00.pdf https://www.amd.com/system/files/TechDocs/56323-PUB_1.00.pdf ): The XSAVES instruction may fail to save XMM registers to the provided state save area if all of the following are true: • All XMM registers were restored to the initialization value by the most recent XRSTORS instruction because the XSTATE_BV[SSE] bit was clear. • The state save area for the XMM registers does not contain the initialization state. • The value in the XMM registers match the initialization value when the XSAVES instruction is executed. • The MXCSR register has been modified to a value different from the initialization value since the most recent XRSTORS instruction.

pabs3 4y ago

Linux folks also plan to apply a workaround for systems running old microcode.

alex_duf 4y ago

As an outsider from the hardware world, I find it astounding that it's possible to fix the behaviour a CPU instruction by changing code. (assuming I understand correctly) In my mind a CPU instruction is hardwired on the chip, and it blows my mind that we keep finding workarounds to already released hardware. Maybe someone could dumb that down for me?

fhars 4y ago
The CPU only pretends to be a CPU. In reality, it is a small datacenter comprised of several small special purpose computers doing all the work. I gave up understanding CPUs in depth by the time I read an introducion to Intel's then-new i860 CPU in the April issue of a magazine and it turned out to be a real device.
- psychphysic 4y ago
  Best explanation in my opinion. Almost like a CPU has an JIT emulator for x86.
  - yvdriess 4y ago
    ucode cracking is relatively straightforward, I wouldn't call it a JIT. https://intelxed.github.io/ref-manual/ https://intelxed.github.io/ref-manual/ It's more like an intepreter for x86, seeing as it is actually executed on a dataflow architecture.
    - psychphysic 4y ago
      Macro op fusion is more what I had in mind when I called it JIT and not interpretation. Not sure what the distinction is but that's where it is to my mind
      - yvdriess 4y ago
        It's true that the distinction is a bit vague, the term JIT is overloaded to enough that it stopped being a useful technical term. Compared to 'JVM JIT' or 'LuaJIT': there is no instrumentation to detect what is hot or not. The CPU frontend will crack x86 instructions into micro-ops, while looking for some patterns to merge certain instructions or uops into larger micro-ops. The micro-coded instructions (like many of the legacy instructions) are likely just lookups. Most of this is my speculation, mind. Modern CPU frontends are still kind of a black magic box to me, but I think they are limited by relatively simple transformations by virtue of being on the critical execution path.