Just ask!
Seriously. You can ask AMD. Maybe they won’t tell you, but they might. It might be really good info. Why not ask someone who is really knowledgeable about this stuff like a kernel developer who works on x86-64 or worked on the mitigations?
This is what I never understand about Phoronix. People link to them all the time but they run a bunch of benchmarks and then end on “there you go”. I’d like investigation into why. You won’t always get an answer but you should try.
Seriously? By far the most likely outcome is that they don't even bother responding.
That's how corporations operate in 2022. If you're a journalist from the Washington Post, you might get a three-line statement from a spokesperson. Everyone else gets a canned reply from a bot, or nothing at all.
I don't blame Michael for not even bothering to try. Phoronix is the only game in town for much of the topics it covers. The fact that it exists at all, and is effectively run by a single person, is nothing short of amazing.
This is not true, I write to AMD security team for spectre/meltdown/CPU flaws and get reasonable responses. Intel security team is also quite good. The usual wait time is 3-4 days.
Admittedly I do write from my work address.
So, "likely" the same outcome as when you don't ask, except unlike when you don't ask, there is a different outcome when you do ask? Sounds like you just made the argument in favour of always asking questions.
https://web.archive.org/web/20190322061230/https://plus.goog...
But it's Phoronix - short reprints, not well-done benchmarks, 1-3 paragraphs long "articles" and backlink spam on forums, wikis and wherever possible. They may ask AMD but that will be another "article" and another wave of spam.
> My theory is that fixing the Spectre V2 vulnerability on a hardware level would lead to fundamental architecture changes that AMD is not willing to make, because it may add so much more complexity to the architecture or it may just be too unconvenient. They probably realized that optimizing the code paths that the Linux kernel utilizes on the default mitigations mode is faster, simpler and it may involve less deeper changes, while still being secure.
> As far as I know, pretty much every CPU architecture that implements speculative execution is vulnerable to some version of Spectre, so note that this is not a fundametal flaw of AMD64.
The branch predictor is one of the most highly optimized pieces of the CPU core. Lots of discussion has been had about how the arm architecture's frontend is simpler, so for example Apple's chips have way more execution units. Intel and AMD's latest designs have also expanded the number of execution units, but the frontend instruction decode and dispatch is the "serial" part of the process, reading the incoming instruction stream. And the x86 instruction set is hard to decode, with a lot of variation in the number of bytes per instruction. So for the instruction decoder to even know there's a branch coming up is a "hard problem," and then it predicts which way the branch will go.
I mean, in the humorous extreme: imagine if some enterprising group at AMD got together and realized they could "optimize" all that retpoline code by making the RET instruction aware of the branch prediction cache!
"Fundamental architecture changes" are, in fact, what is actually required here.
So maybe even something like "if PCID is not set, flush the cache" vs "if PCID changes, flush the cache".
I think that would certainly account for this, and they could have improved the performance with PCID by increasing the PCID cache size.
