On Fri, Sep 15 2023 at 00:46, andrew wrote:
> On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>> So no. I'm fundamentally disagreeing with your recommendation. The way
>> forward is:
>>
>> 1) Provide the native variant for wrmsrns(), i.e. rename the proposed
>> wrmsrns() to native_wrmsr_ns() and have the X86_FEATURE_WRMSRNS
>> safety net as you pointed out.
>>
>> That function can be used in code which is guaranteed to be not
>> affected by the PV_XXL madness.
>>
>> 2) Come up with a sensible solution for the PV_XXL horrorshow
>>
>> 3) Implement a sane general variant of wrmsr_ns() which handles
>> both X86_FEATURE_WRMSRNS and X86_MISFEATURE_PV_XXL
>>
>> 4) Convert other code which benefits from the non-serializing variant
>> to wrmsr_ns()
>
> Well - point 1 is mostly work that needs reverting as part of completing
> point 3, and point 2 clearly needs doing irrespective of anything else.
No. #1 has a value on its own independent of the general variant in #3.
>> That function can be used in code which is guaranteed to be not
>> affected by the PV_XXL madness.
That makes a lot of sense because it's guaranteed to generate better
code than whatever we come up with for the PV_XXL nonsense.
Thanks,
tglx
