Re: [Xen-devel] [PATCH v2 4/6] xen/x86: disable global pages for domains with XPTI active

[Juergen Gross <jgross@xxxxxxxx>]

On 09/03/18 09:34, Jan Beulich wrote:
>>>> On 09.03.18 at 06:23, <kevin.tian@xxxxxxxxx> wrote:
>>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>> Sent: Thursday, March 8, 2018 9:39 PM
>>>
>>>> --- a/xen/include/asm-x86/domain.h
>>>> +++ b/xen/include/asm-x86/domain.h
>>>> @@ -622,7 +622,8 @@ unsigned long pv_guest_cr4_fixup(const struct
>>> vcpu *, unsigned long guest_cr4);
>>>>              X86_CR4_SMAP | X86_CR4_OSXSAVE |                \
>>>>              X86_CR4_FSGSBASE))                              \
>>>>        | ((v)->domain->arch.vtsc ? X86_CR4_TSD : 0))         \
>>>> -     & ~X86_CR4_DE)
>>>> +     & ~(X86_CR4_DE |                                       \
>>>> +         ((v)->domain->arch.pv_domain.xpti ? X86_CR4_PGE : 0)))
>>>
>>> With this you manage to turn off global pages when switching to
>>> a PV vCPU. But I can't see how you turn global pages back on when
>>> switching away from it. I can see they would be turned back on e.g.
>>> on the first entry to a VMX guest, but how about an SVM one? And
>>> how about the time between switching away from the PV vCPU and
>>> that VM entry? Granted all flushes are global ones right now, but
>>> that should change with the modification here: If you look back at
>>> 4.2 code, you'll see that FLUSH_TLB was handled differently in that
>>> case, retaining Xen's global mappings. Any flush IPI not requesting
>>> global pages to be flushed could then leave intact Xen's own TLB
>>> entries, which takes as a prereq that CR4.PGE gets turned back on
>>> earlier.
>>
>> btw does PGE really matter regarding to entry to HVM guest? Xen's 
>> mappings are either all flushed (vpid disabled) or all sustained
>> (vpid enabled) at VM entries, regardless of global setting. then if 
>> PGE is anyway turned off for PV and doesn't matter for HVM is it 
>> still useful to keep it turned on between switches?
> 
> Well, yes indeed, but that's only half of where we may want to
> retain them (if possible). The other half is the time between
> context switching in a HVM vCPU and the subsequent VM entry (or
> to be precise the point in time when interrupts get turned off
> before that VM entry, as that's where flush IPIs can still arrive).

I'd like to move loading cr4 from *_ctxt_switch_to() to write_ptbase()
in order to minimize TLB flushes. This will make it much easier to use
the optimal flushing strategy as all intermediate states are handled in
one place.


Juergen

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