Messages in this thread | | | Date | Fri, 15 Sep 2023 01:33:14 +0100 | From | andrew.cooper3@citrix ... | Subject | Re: [PATCH v10 03/38] x86/msr: Add the WRMSRNS instruction support |
| |
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
| |