[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/pv: Deprecate support for paging out the LDT
>>> On 25.07.18 at 14:08, <andrew.cooper3@xxxxxxxxxx> wrote: > On 29/06/18 06:27, Jan Beulich wrote: >>>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 06/28/18 6:10 PM >>> >>> On 28/06/18 14:35, Jan Beulich wrote: >>>>>>> On 26.06.18 at 13:35, <andrew.cooper3@xxxxxxxxxx> wrote: >>>>> --- a/xen/arch/x86/Kconfig >>>>> +++ b/xen/arch/x86/Kconfig >>>>> @@ -161,3 +161,24 @@ endmenu >>>>> source "common/Kconfig" >>>>> >>>>> source "drivers/Kconfig" >>>>> + >>>>> +menu "Deprecated Functionality" >>>>> + >>>>> +config LEGACY_PV_LDT_PAGING >>>>> + def_bool n >>>>> + prompt "PV LDT Paging-out support" >>>>> + ---help--- >>>>> + For a very long time, the PV ABI has included the ability to page >>>>> + out the LDT by transitioning its mapping to not-present. This >>>>> + functionality is believed to only exist for the PV Windows XP port >>>>> + which never came to anything. >>>>> + >>>>> + The implementation contains a vCPU scalability limitation in a >>>>> + position which is prohibitively complicated to resolve. As the >>>>> + feature is believed to be unused in practice, removing the feature >>>>> + is the easiest remediation. >>>>> + >>>>> + If you discover a usecase which is broken by this option being off, >>>>> + please contact xen-devel@xxxxxxxxxxxxxxxxxxxx urgently. Baring >>>>> + something unexpected, the code and this option will be removed. >>>> I think it should be said here explicitly when (or to be precise, no >>>> earlier >>>> than when) this is going to happen. >>> I'm open to suggests, but decided not to name a specific release (if >>> only to avoid second-guessing our future numbering and release schedule). >>> >>>> I also think the security support status with the option enabled needs to >>>> be clarified. Perhaps we'd go in stages: Introduce the (default off) >>>> option, >>>> then (e.g. for 4.13) switch its use to security unsupported, and finally >>>> drop the code (e.g. for 4.14). >>> I presume you mean that we should hide it behind EXPERT at that point? >> That's the best way to express it I guess, yes. Plus some form of remark in >> SUPPORT.md. >> >> >>> What does the middle step gets us. If its going to be off by default >>> and unable to be enabled by default, that is as good as deleted. >> Think of people only using released code: They'd notice the removed >> functionality only in 4.12. Removing the code right away for 4.13 could >> therefore be too early. > > How can we unblock this patch? I stand by my original point of "that's > as good as deleted and isn't actually useful for distros". I don't see how the patch is blocked - I've clearly outlined how I think this (or in fact any such) removal should be done. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |