linux-kernel - Re: [PATCH v2 4/4] vfio-pci: Best-effort huge pfnmaps with !MAP

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: <20251216190131.GI6079@nvidia.com>
Date: Tue, 16 Dec 2025 15:01:31 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Peter Xu <peterx@...hat.com>
Cc: kvm@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Nico Pache <npache@...hat.com>, Zi Yan <ziy@...dia.com>,
	Alex Mastro <amastro@...com>, David Hildenbrand <david@...hat.com>,
	Alex Williamson <alex@...zbot.org>, Zhi Wang <zhiw@...dia.com>,
	David Laight <david.laight.linux@...il.com>,
	Yi Liu <yi.l.liu@...el.com>, Ankit Agrawal <ankita@...dia.com>,
	Kevin Tian <kevin.tian@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 4/4] vfio-pci: Best-effort huge pfnmaps with
 !MAP_FIXED mappings

On Tue, Dec 16, 2025 at 11:01:00AM -0500, Peter Xu wrote:
> Do we have any function that we can fetch the best mapping lower than a
> specific order?

I'm not aware of anything

> > None of this logic should be in drivers.
> 
> I still think it's the driver's decision to have its own macro controlling
> the huge pfnmap behavior.  I agree with you core mm can have it, I don't
> see it blocks the driver not returning huge order if huge pfnmap is turned
> off.  VFIO-PCI currently indeed only depends directly on global THP
> configs, but I don't see why it's strictly needed.  So I think it's fine if
> a driver (even if global THP enabled for pmd/pud) deselect huge pfnmap for
> other reasons, then here the order returned can still always be PSIZE for
> the driver.  It's really not a huge deal to me.

All these APIs should be around the idea that the driver just returns
what it has and the core mm places it into ptes. There is not a good
reason drivers should be overriding this logic or doing their own
thing.

> > Drivers shouldn't implement this alignment function without also
> > implementing huge fault, it is pointless. Don't see a reason to add
> > extra complexity.
> 
> It's not implementing the order hint without huge fault.  It's when both
> are turned off in a kernel config.. then the order hint (even from driver
> POV) shouldn't need to be reported.

No, it should still all be the same the core code just won't call the
function.

> I don't know why you have so strong feeling on having a config check in
> vfio-pci drivers is bad.

It is leaking MM details into drivers that should not be in drivers.

> I still think it's good to have it pairing with the same macro in
> huge_fault(),

It should not be there either.

Jason