On 2019/4/5 17:38, Jan Beulich wrote:
On 04.04.19 at 22:26, <andrew.coop...@citrix.com> wrote:
+ else
+ /* Successfully enabled! */
+ __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
Down the road we may want to make this another helper function
shared by AMD any Hygon code.
It sounds good.
+ /*
+ * If the user has explicitly chosen to disable Memory Disambiguation
+ * to mitigiate Speculative Store Bypass, poke the appropriate MSR.
+ */
+ if (opt_ssbd && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
+ value |= 1ull << 10;
+ wrmsr_safe(MSR_AMD64_LS_CFG, value);
+ }
Like the above, this lacks a model check. Is it really expected for
all future Hygon models to supports both in exactly the same
For current Hygon family 18h, all models will have the same meaning.
fashion? Even if there's just a small chance of this not being the
case, rather than fiddling with MSRs which have an entirely
different meaning in future models, I'd prefer if model checks
were added in cases like these.
In future for some other Hygon CPU families(such as maybe family 20h ?),
the bits definition of this MSR may have different meaning. But I think
it should be dealt with by then, since there would be some other
features to be adjusted by the way for those families.
I do realize that in the former case there's effectively an "all
models except a few" logic already in the original AMD code,
which I would too question whether it's really desirable. After
all we've learned recently that MSRs indeed can go away
It's a good thing that MSRs can go away.
(albeit in that case it was a change to the MSR simply becoming
meaningless, rather than obtaining a new meaning). Based on
this I could accept just the SSBD logic to gain a model check.
--
Regards,
Pu Wen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
