On 15/09/2023 1:12 am, Thomas Gleixner wrote: > 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. It's an assumption about what "definitely won't" be paravirt in the future. XenPV stack handling is almost-FRED-like and has been for the better part of two decades. You frequently complain that there's too much black magic holding XenPV together. A paravirt-FRED will reduce the differences vs native substantially. ~Andrew
