Re: [Xen-devel] [PATCH] x86/pv: Deprecate support for paging out the LDT

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Jul 25, 2018 at 1:29 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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.

Since Andy seems to be soliciting other opinions:

* If it were entirely up to me, I'd probably go with deprecating it
over 2 releases instead of 3.  I don't see much benefit in a release
without security support.
* But I don't think it hurts that much to have it 'deprecated' for two releases.
* On the whole I don't think this matters much; I'd be happy with
flipping a coin to settle it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel