On 26/03/18 12:43, Jan Beulich wrote: >>>> On 26.03.18 at 12:29, <jgr...@suse.com> wrote: >> On 26/03/18 12:13, Jan Beulich wrote: >>>>>> On 26.03.18 at 10:55, <jgr...@suse.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
