Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active

[Juergen Gross <jgross@xxxxxxxx>]

On 27/03/18 10:33, Jan Beulich wrote:
>>>> On 27.03.18 at 09:37, <jgross@xxxxxxxx> wrote:
>> On 27/03/18 09:23, Jan Beulich wrote:
>>>>>> On 27.03.18 at 09:14, <jgross@xxxxxxxx> wrote:
>>>> On 22/03/18 17:30, Jan Beulich wrote:
>>>>>>>> On 21.03.18 at 13:51, <jgross@xxxxxxxx> wrote:
>>>>>> Instead of flushing the TLB from global pages when switching address
>>>>>> spaces with XPTI being active just disable global pages via %cr4
>>>>>> completely when a domain subject to XPTI is active. This avoids the
>>>>>> need for extra TLB flushes as loading %cr3 will remove all TLB
>>>>>> entries.
>>>>>
>>>>> I continue to be not entirely convinced of this move. I had an
>>>>> alternative in mind: Since retaining global pages is particularly
>>>>> relevant for switches between guest user and guest kernel
>>>>> modes, what if we made a shortcut from e.g. lstar_enter through
>>>>> switch_to_kernel to restore_all_guest without ever switching to
>>>>> the full page Xen tables?
>>>>>
>>>>>> --- a/xen/arch/x86/mm.c
>>>>>> +++ b/xen/arch/x86/mm.c
>>>>>> @@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>>>>>  void write_ptbase(struct vcpu *v)
>>>>>>  {
>>>>>>      struct cpu_info *cpu_info = get_cpu_info();
>>>>>> +    unsigned long new_cr4;
>>>>>> +
>>>>>> +    new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
>>>>>> +              ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
>>>>>
>>>>> I'm not overly happy to see any new uses of mmu_cr4_features.
>>>>> This should really only be used for priming certain values imo,
>>>>> which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
>>>>> so too, and perhaps better wouldn't). Hence I wonder whether
>>>>> this shouldn't be read_cr4() | X86_CR4_PGE, not the least
>>>>> because we've just got rid of the blanket reversion to
>>>>> mmu_cr4_features in VMX code.
>>>>
>>>> I just realized that using read_cr4() | X86_CR4_PGE is wrong. We would
>>>> keep bits switched on which a pv domain is allowed to modify (plus
>>>> CR4_TSD eventually).
>>>>
>>>> Do we really want that?
>>>
>>> Does it matter what exact CR4 settings we run with when it's not
>>> a PV guest that's in context, and when we don't depend on the
>>> settings ourselves? I don't think it does, and HVM guests run with
>>> their own CR4 anyway. In fact there may end up being cases
>>> where we won't need to switch CR4 another time when we come
>>> here the next time with v being a PV vCPU.
>>
>> I could imagine that there is some performance impact. cr4.tsd set
>> might make rdtsc a little bit slower as an additional privilege level
>> check is needed.
> 
> Quite possible, indeed. Another opinion on the route to take
> would be helpful here. Andrew?

I could mask away tsd, of course. I need to do so for pcide already,
so that would be just another bit reset in the mask.


Juergen

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