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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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