I suggest you check this: https://www.grc.com/inspectre.htm Get the app, apply the Meltdown protection and see how it goes. You can always disable the protection...
I am running Win7 on a i7-3770 also and only applied the meltdown patch but not the microcode patch. Most Spectre patches are in BIOS updates and once you install that bios you can not downgrade to non-Spectre AFAIK
Yes both the meltdown patch and the Spectre microcode can cause minor to major cpu slowdowns on older systems. At the least you should patch the OS (least amount of slowdown compared to microcode)
That is all I know..
added: I did not update the bios to the "spectre" microcoded one on my i7-87770k either (the computer am on), just did the Meltdown...

As I recall, the most expensive mitigation in the whole Meltdown/Spectre mess was kernel page table isolation (called KVAS on Windows).

It relies on changing out the page table when switching between kernel and user space. In other words, rather than relying on x86 privilege levels to block user space from accessing kernel memory (because those aren't enforced during speculative execution, and the processor fails to adequately clean up all side effects from speculatively executing code that didn't have permission to execute), the OS must modify the page table or switch page tables such that kernel addresses aren't mapped to any physical address at all. This requires substantial changes to the OS and could not occur from a microcode update alone.

jakethompson1 wrote on 2025-05-06, 01:13:

As I recall, the most expensive mitigation in the whole Meltdown/Spectre mess was kernel page table isolation (called KVAS on Windows).

It relies on changing out the page table when switching between kernel and user space. In other words, rather than relying on x86 privilege levels to block user space from accessing kernel memory (because those aren't enforced during speculative execution, and the processor fails to adequately clean up all side effects from speculatively executing code that didn't have permission to execute), the OS must modify the page table or switch page tables such that kernel addresses aren't mapped to any physical address at all. This requires substantial changes to the OS and could not occur from a microcode update alone.

Agree ! Think that came with Win 10 1903 and above or maybe it was 1909 + MS patches.

I applied the the bios updates back when it was a daily driver.
Now that it's been downgraded to a WinXP/7 retro rig I'm not noticing any performance penalty.
However I also don't apply updates to my retro machines apart from service packs as they are mostly offline and even a fully patched copy of XP or 7 is full of security holes.
I also suspect that the hardware is so overpowered for my games that even if performance is taking a hit I've enough in reserve for it not to matter.

jakethompson1 wrote on 2025-05-06, 01:13:

As I recall, the most expensive mitigation in the whole Meltdown/Spectre mess was kernel page table isolation (called KVAS on Windows).

It relies on changing out the page table when switching between kernel and user space. In other words, rather than relying on x86 privilege levels to block user space from accessing kernel memory (because those aren't enforced during speculative execution, and the processor fails to adequately clean up all side effects from speculatively executing code that didn't have permission to execute), the OS must modify the page table or switch page tables such that kernel addresses aren't mapped to any physical address at all. This requires substantial changes to the OS and could not occur from a microcode update alone.

This is probably the Meltdown mitigation that everybody complains about. I think that InSpectre disables KVAS with the registry dwords "FeatureSettingsOverride" and "FeatureSettingsMask" set to 3? Yet I saw people complaining that InSpectre is outdated and more mitigations have been introduced since 2018.

I recall something about the mitigations being different depending on whether you have hyperthreading enabled or disabled, but again there's so much bunk info on this topic online.

Shouldn't be that difficult to verify. Install Linux and disable or install a version of win10 pre-updates. Run benchmarks. Enable mitigations on Linux or install updated windows 10 and verify enabled. Run benchmarks. Compare. If there is a concern about firmware then downgrade and benchmark.