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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 12.01.18 at 19:37, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Windows is the only OS which pages out kernel datastructures, so chances are
>> good that this is a vestigial remnant of the PV Windows XP experiment.
>
> This is based on what? How do you know there are no other OSes
> doing so, including perhaps ones which none of us has ever heard
> of? The diffstat of the change here is certainly nice, but as always
> with something being removed from the ABI I'm rather hesitant.
>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1942,11 +1942,8 @@ int domain_relinquish_resources(struct domain *d)
>>          {
>>              for_each_vcpu ( d, v )
>>              {
>> -                /*
>> -                 * Relinquish GDT mappings. No need for explicit unmapping 
>> of
>> -                 * the LDT as it automatically gets squashed with the guest
>> -                 * mappings.
>> -                 */
>> +                /* Relinquish GDT/LDT mappings. */
>> +                pv_destroy_ldt(v);
>>                  pv_destroy_gdt(v);
>
> The domain is dead at this point, so the order doesn't matter much,
> but strictly speaking you should destroy the GDT before destroying
> the LDT (just like LDT _loads_ always need to come _after_ GDT
> adjustments).
>
> Everything else here looks fine, but the initial comment may need
> further discussion. For example we may want to consider a
> two-stage phasing out of the feature, with a couple of years in
> between: Make the functionality dependent upon a default-off
> command line option for the time being, and issue a bright warning
> when someone actually enables it (telling them to tell us).

One of the problems we have is that people seem to wait for 2-3 years
after a release has been made to start updating to it.  So we'd have
to leave such a warning for probably 5 years minimum.

 -George

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