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

[Juergen Gross <jgross@xxxxxxxx>]

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?


Juergen

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