lkml.org 
[lkml]   [2018]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [tip:x86/hyperv] x86/hyperv: Stop suppressing X86_FEATURE_PCID
On Wed, Jan 24, 2018 at 4:48 AM, tip-bot for Vitaly Kuznetsov
<tipbot@zytor.com> wrote:
> Commit-ID: 04651dd978a8749e59065df14b970a127f219ac2
> Gitweb: https://git.kernel.org/tip/04651dd978a8749e59065df14b970a127f219ac2
> Author: Vitaly Kuznetsov <vkuznets@redhat.com>
> AuthorDate: Wed, 24 Jan 2018 11:36:29 +0100
> Committer: Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Wed, 24 Jan 2018 13:44:57 +0100
>
> x86/hyperv: Stop suppressing X86_FEATURE_PCID
>
> When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
> was deliberately suppressed as a precaution: back then PCID was never
> exposed to Hyper-V guests and it wasn't clear what will happen if some day
> it becomes available. The day came and PCID/INVPCID features are already
> exposed on certain Hyper-V hosts.
>
> From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with
> PCID. In particular the usage of PCID is per-cpu based: the same mm gets
> different CR3 values on different CPUs. If the hypercall does exact
> matching this will fail. However, this is not the case. David Zhang
> explains:
>
> "In practice, the AddressSpace argument is ignored on any VM that supports
> PCIDs.
>
> Architecturally, the AddressSpace argument must match the CR3 with PCID
> bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
> long mode). The flush hypercalls flush all PCIDs for the specified
> AddressSpace."
>
> With this, PCID can be enabled.

So what, exactly, does the flush hypercall do?

--Andy

\
 
 \ /
  Last update: 2018-01-24 17:28    [W:0.072 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site