Re: Missing L3 linesize on AMD Ryzen 7940HS chip causes crash in amd_cpuid4.

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 31, 2023, Christian Lamparter wrote:
> This is because L3 cache's line_size is "0" (this is coming from the 80000006 edx
> value of 0x00009000).
> 
> This can't be right... or? Well, digging around. I found the following explanation
> in AMD's community forum:
> <https://community.amd.com/t5/processors/ryzen-7-3700x-cpuid-function-id-0x80000006-returns-wrong-number/td-p/376937>
> So there's an issue with "wonky L3 values" that happens even earlier with the
> AMD 3700X. In this forum post, the author talks about the
> "L3 cache associativity (bits 12-15) is 0x9".
> 
> And the same is happening with both AMD 7950X and 7940HS.
> The kicker is: this value of "9" means:
> "Please look at CPUID.8000_001D".

Ugh, that's just nasty.

> Which I think boils down to implementing X86_FEATURE_TOPOEXT
> for virtualbox to get over this issue?
> 
> Now, is there something I'm missing? I don't know if qemu is be affected.

AFAICT, QEMU should be fine, so long as the underlying hardware is sane.  Unless
I'm misreading things, QEMU doesn't generate the redirect to 0x8000001D when
synthesizing cache information, and when passing through host cache information,
both 0x80000006 and 0x8000001D are passed through verbatim.

> Or if there's another way around it.

At a glance, having virtualbox zero out EDX if its trying to redirect should also
work.