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