Re: [Xen-devel] [PATCH 4/5] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen <puwen@xxxxxxxx>]

On 2019/4/5 17:38, Jan Beulich wrote:
> On 04.04.19 at 22:26, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel