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

[Juergen Gross <jgross@xxxxxxxx>]

On 12/03/18 13:59, Jan Beulich wrote:
>>>> Juergen Gross <jgross@xxxxxxxx> 03/09/18 7:05 PM >>>
>> On 09/03/18 16:29, Jan Beulich wrote:
>>>>>> On 05.03.18 at 10:50, <wei.liu2@xxxxxxxxxx> wrote:
>>>> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, 
>>>> unsigned int flags)
>>>>          else
>>>>          {
>>>>              u32 t = pre_flush();
>>>> -            unsigned long cr4 = read_cr4();
>>>>  
>>>> -            write_cr4(cr4 & ~X86_CR4_PGE);
>>>> -            barrier();
>>>> -            write_cr4(cr4);
>>>> +            if ( !cpu_has_invpcid )
>>>> +            {
>>>> +                unsigned long cr4 = read_cr4();
>>>> +
>>>> +                write_cr4(cr4 & ~X86_CR4_PGE);
>>>> +                barrier();
>>>> +                write_cr4(cr4);
>>>> +            }
>>>> +            else
>>>> +            {
>>>> +                /*
>>>> +                 * Using invpcid to flush all mappings works
>>>> +                 * regardless of whether PCID is enabled or not.
>>>> +                 * It is faster than read-modify-write CR4.
>>>> +                 */
>>>> +                invpcid_flush_all();
>>>> +            }
>>>
>>> As just validly indicated by Jürgen, this is where my comment I
>>> gave to one of his patches actually belongs: This is correct for
>>> FLUSH_TLB_GLOBAL, but goes too far for FLUSH_TLB.
>>
>> And again it was so even before this patch.
> 
> Not exactly - "before this patch" should include the state things were in 
> before
> 32-bit code got removed. And that's where we had a proper separation between
> flushes including and excluding global entries. And now that we regain that
> ability, we should leverage it.

Already working on it in my XPTI speed-up series.

BTW: are you already working on rebasing your XPTI speed up series to
current staging? I'd like my series to use your series as a base unless
you are telling me you won't be able to resend your series soon.


Juergen

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