linux-kernel - Re: [PATCH 00/19] mm: Support huge pfnmaps

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: <CABgObfbaRwob74An5=s+HiaRiPa2_z-LFF1sPtEtAHO8_VuF0g@mail.gmail.com>
Date: Wed, 14 Aug 2024 16:42:28 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, Peter Xu <peterx@...hat.com>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, Oscar Salvador <osalvador@...e.de>, 
	Axel Rasmussen <axelrasmussen@...gle.com>, linux-arm-kernel@...ts.infradead.org, 
	x86@...nel.org, Will Deacon <will@...nel.org>, Gavin Shan <gshan@...hat.com>, 
	Zi Yan <ziy@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Catalin Marinas <catalin.marinas@....com>, Ingo Molnar <mingo@...hat.com>, 
	Alistair Popple <apopple@...dia.com>, Borislav Petkov <bp@...en8.de>, David Hildenbrand <david@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, kvm@...r.kernel.org, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Alex Williamson <alex.williamson@...hat.com>, 
	Yan Zhao <yan.y.zhao@...el.com>
Subject: Re: [PATCH 00/19] mm: Support huge pfnmaps

On Wed, Aug 14, 2024 at 4:35 PM Sean Christopherson <seanjc@...gle.com> wrote:
> > vfio/iommufd will reassemble the contiguous range from the 4k PFNs to
> > setup the IOMMU, but KVM is not able to do it so reliably.
>
> Heh, KVM should very reliably do the exact opposite, i.e. KVM should never create
> a huge page unless the mapping is huge in the primary MMU.  And that's very much
> by design, as KVM has no knowledge of what actually resides at a given PFN, and
> thus can't determine whether or not its safe to create a huge page if KVM happens
> to realize the VM has access to a contiguous range of memory.

Indeed: the EPT is managed as a secondary MMU. It replays the contents
of the primary MMU, apart from A/D bits (which are independent) and
permissions possibly being more restrictive, and that includes the
page size.

Which in turn explains why the VA has to be aligned for KVM to pick up
the hint: aligning the VA allows the primary MMU to use a hugepage,
which is a prerequisite for using it in EPT.

Paolo