linux-kernel - Re: [PATCH v5 8/9] mm: multi-gen LRU: Have secondary MMUs participate in aging

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: <ZmqWhw3eKzwwWUHN@linux.dev>
Date: Wed, 12 Jun 2024 23:49:43 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Yu Zhao <yuzhao@...gle.com>, James Houghton <jthoughton@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Ankit Agrawal <ankita@...dia.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	David Matlack <dmatlack@...gle.com>,
	David Rientjes <rientjes@...gle.com>,
	James Morse <james.morse@....com>, Jonathan Corbet <corbet@....net>,
	Marc Zyngier <maz@...nel.org>,
	Raghavendra Rao Ananta <rananta@...gle.com>,
	Ryan Roberts <ryan.roberts@....com>,
	Shaoqin Huang <shahuang@...hat.com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Wei Xu <weixugc@...gle.com>, Will Deacon <will@...nel.org>,
	Zenghui Yu <yuzenghui@...wei.com>, kvmarm@...ts.linux.dev,
	kvm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v5 8/9] mm: multi-gen LRU: Have secondary MMUs
 participate in aging

On Wed, Jun 12, 2024 at 10:23:38AM -0700, Sean Christopherson wrote:
> On Wed, Jun 12, 2024, Yu Zhao wrote:
> > I do think there can be false negatives but we have not been able to
> > measure their practical impacts since we disabled the flush on some
> > host MMUs long ago (NOT by MGLRU), e.g., on x86 and ppc,
> > ptep_clear_flush_young() is just ptep_test_andclear_young().
> 
> Aha!  That's what I was missing, I somehow didn't see x86's ptep_clear_flush_young().

Heh, well the helper name isn't exactly giving any hints...

> That begs the question, why does KVM flush TLBs on architectures that don't need
> to?  And since kvm_mmu_notifier_clear_young() explicitly doesn't flush, are there
> even any KVM-supported architectures for which the flush is mandatory?
> 
> Skipping the flush on KVM x86 seems like a complete no-brainer.
> 
> Will, Marc and/or Oliver, what are arm64's requirements in this area?  E.g. I see
> that arm64's version of __ptep_clear_flush_young() does TLBI but not DSB.  Should
> KVM be doing something similar?  Can KVM safely skip even the TBLI?

Short answer, yes, KVM can elide TLBIs when clearing AF.

Long answer: Software needs to be extremely careful to ensure that TLBI
elision doesn't lead to a failure to uphold break-before-make requirements,
if we're only concerned with architecture-specific requirements. IOW, the AF
cannot be used as a hint for the presence of TLB entries for a given PTE.

There's the obvious failure of skipping TLBIs for old pages when
unmapping, but that isn't an architecture-specific issue.

So, since KVM/arm64 doesn't play any games with the AF at stage-2, leaving
out a TLBI when aging ought to be fine.

-- 
Thanks,
Oliver