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

[Juergen Gross <jgross@xxxxxxxx>]

On 26/03/18 14:19, Jan Beulich wrote:
>>>> 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.

Okay, I'll add an ASSERT() to make sure this is true:

ASSERT(!cr4.pge || !cr4.pcide)


Juergen


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