[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.