Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.03.18 at 14:04, <jgross@xxxxxxxx> wrote:
> On 26/03/18 12:43, Jan Beulich wrote:
>>>>> On 26.03.18 at 12:29, <jgross@xxxxxxxx> wrote:
>>> On 26/03/18 12:13, Jan Beulich wrote:
>>>>>>> On 26.03.18 at 10:55, <jgross@xxxxxxxx> wrote:
>>>>> I can change the scheme to use different values for guest PCIDs
>>>>> with XPTI on, of course. Are you fine with:
>>>>>
>>>>> - XPTI off: PCID 0 = kernel, PCID 1 = user
>>>>> - XPTI on:  PCID 0 = kernel/Xen, PCID 1 = user/Xen,
>>>>>             PCID 2 = kernel/guest, PCID 3 = user/guest
>>>>
>>>> Yes, that would fit the first variant I've described. I take it you
>>>> prefer not to avoid PCID 0 altogether when PCIDs are enabled -
>>>> is there a particular reason?
>>>
>>> Yes. As written in the comment in flush_area_local() I can't be sure
>>> whether the current address space is that of a domain with XPTI
>>> enabled (the idle domain could be "current"). So I need to always
>>> flush with PCID 0 and with the possible PCID values for a XPTI domain.
>>> When using PCID 0 for XPTI as well I'll need 4 INVPCIDs, while when
>>> avoiding it I'd need 5 (at least when current == idle).
>> 
>> I see. Which makes me wonder whether a suitable combination
>> of INVLPG (to get rid of global entries) and INVPCID couldn't be
>> used instead. For example, you may be able to replace the
>> INVPCID for the active PCID by INVLPG (without needing to
>> know who "current" is).
> 
> INVLPG has the disadvantage to clear all paging-structure cache
> entries associated with the current PCID.
> 
> And I thought we were finally on the same page not to use global
> pages with PCID enabled?

Yes, we are. If no global TLB entries can ever survive a CR4.PCIDE
0 -> 1 transition, all would be fine without INVLPG of course.

Jan


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