[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing



>>> On 05.03.18 at 14:31, <wei.liu2@xxxxxxxxxx> wrote:
> On Mon, Mar 05, 2018 at 06:24:37AM -0700, Jan Beulich wrote:
>> >>> On 05.03.18 at 14:11, <jgross@xxxxxxxx> wrote:
>> > On 05/03/18 13:57, Andrew Cooper wrote:
>> >> When we start using PCID for user mappings, then we don't need them to
>> >> be global, at which point we can require/expect that the only global
>> >> mappings are hypervisor ones which we expect to remain correct across a
>> >> write to cr3.  However, if we do this, then we need to use a bit other
>> >> than PAGE_GLOBAL to signify guest user mappings.
>> >> 
>> >> I think this is doable, but I don't think it is going to be trivial to
>> >> get correct.
>> > 
>> > Why would we want to keep any global mappings at all? What are they good
>> > for? Today the only case I could find where they make sense at all is
>> > for 64-bit pv-guests to keep hypervisor mappings in the TLB when the
>> > guest is switching between user and kernel mode.
>> 
>> Hypervisor and guest user mappings, that is.
>> 
> 
> I'm not sure I understand the rationale behind global guest mappings. Is
> it to keep guest user mappings when switching to guest kernel mode?

Yes, exactly (and especially when - like for some syscalls - there's
a fast user->kernel->user round trip). The goal is to avoid at least
some of the TLB reloads, when we already can't have global guest
kernel mappings.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.