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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d09a9b6a06d3017a27ace549876b739fa39e3aed.camel@surriel.com>
Date: Wed, 25 Dec 2024 09:48:32 -0500
From: Rik van Riel <riel@...riel.com>
To: 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 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 :)


-- 
All Rights Reversed.