linux-kernel - Re: [RFC PATCH v2 00/11] AMD broadcast TLB invalidation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <00294e7e-dcd8-f940-372e-070b8d174582@amd.com>
Date: Fri, 10 Jan 2025 13:29:13 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Rik van Riel <riel@...riel.com>, Michael Kelley <mhklinux@...look.com>,
 "x86@...nel.org" <x86@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "kernel-team@...a.com" <kernel-team@...a.com>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "luto@...nel.org" <luto@...nel.org>,
 "peterz@...radead.org" <peterz@...radead.org>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
 "hpa@...or.com" <hpa@...or.com>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC PATCH v2 00/11] AMD broadcast TLB invalidation

On 12/25/24 08:48, Rik van Riel wrote:
> On Tue, 2024-12-24 at 18:08 +0000, Michael Kelley wrote:
>> From: riel@...riel.com <riel@...riel.com> Sent: Sunday, December 22,
>> 2024 6:55 PM
>>
>>>
>>> Add support for broadcast TLB invalidation using AMD's INVLPGB
>>> instruction.
>>
>>> This allows the kernel to invalidate TLB entries on remote CPUs
>>> without
>>> needing to send IPIs, without having to wait for remote CPUs to
>>> handle
>>> those interrupts, and with less interruption to what was running on
>>> those CPUs.
>>>
>>> Because x86 PCID space is limited, and there are some very large
>>> systems out there, broadcast TLB invalidation is only used for
>>> processes that are active on 3 or more CPUs, with the threshold
>>> being gradually increased the more the PCID space gets exhausted.
>>
>> Rik --
>>
>> What is this patch set's expectation about INVLPGB and TLBSYNC
>> availability and usage in a VM? I see that INVLPGB and TLBYSNC
>> behavior in a VM is spec'ed in the AMD Programmer's Manual, but
>> I wonder about their impact in a multi-tenant host like in a public
>> cloud environment. And given what this patch set does in assigning
>> global ASIDs, should X86_FEATURE_INVLPGB be disabled if
>> running in a VM where the hypervisor for whatever reason has
>> enabled INVLPGB/TLBSYNC in its VMs?
>>
> This patch series enables bare metal INVLPGB functionality.
> 
> Virtual machines should probably not expose the INVPLGB
> CPUID feature bit to guests, since virtual machine
> invalidation seems to work differently than bare metal
> invalidation.
> 
> For one, the ASID seems to actually mean something in
> SVM context, while trying to use the ASID in bare metal
> blows up :)

Note that global ASIDs (relative to VMs) are different from the broadcast
ASIDs being used here. IIUC, the broadcast ASIDs here get translated to a
PCID value (kern_pcid(asid) or user_pcid(asid) in patch #9).

Thanks,
Tom

> 
>