[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:18, <andrew.cooper3@xxxxxxxxxx> wrote: > On 25/07/18 13:16, Jan Beulich wrote: >>>>> 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. > > ... which I disagree with and thing should be done in the way presented > in this path. First of all - the end result (in a couple of years time) is going to be the same. And then note how I did say "perhaps" in my original reply. I'm not going to insist on the middle step. What I demand though is that two full release cycles lie between deprecation and removal, to allow people (of which we hope there to be none) relying on the functionality but not trying out development versions to be able notice the issue and report their needs. And I strongly think this should be spelled out, as suggested, in a "no earlier than" form. The doc aspect can hardly be controversial, and with this I'm having difficulty seeing much of a disagreement here. 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 |