From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 785EE3AA50B for ; Fri, 19 Jun 2026 17:07:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781888829; cv=none; b=eUfrKx+GeJeRM4zFq4357i3/4Ww8+ynL46y4JLUHfmn8RTv1Zlxal8rT2w9//VNWuLNy5igjUpnRn+EMEbhcn80/VszINNpWDjc7wpkoOJlDHRDuooYOxK4xXn+EXamdRPNmJgMQeGBk383L7Q7YFjqjuONMMoHwZegnDGet6NA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781888829; c=relaxed/simple; bh=GnPMB01G/wk66ArMYMaNyDwaZrGCRQhV7Zi3LSB05m4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NQLGKZ23yq8cvYYWyabCIJld3pyVRyXev+8L8dHAzAwP+FC0W5bZFLkZJQNyXMr8ta6iJjrs0/gFYpYMfr+Q3j3BlmWostH2Auf0T4u/zaxbQDvguo1BUt23+uV15oxjqlu+WDOLJRVd2j0Qp9XaYuaHFaZ7H5KDAiZpX2jP8/4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=HWBh7PKQ; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="HWBh7PKQ" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8de0fff76d5so13066156d6.3 for ; Fri, 19 Jun 2026 10:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781888827; x=1782493627; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0p8Xg9lCiPpDoy4o3VOnxua9XkNhU5aTjFKL7L/TUUY=; b=HWBh7PKQkmqMzuzZ8wQNjJb0iJcjx51O8U90Utn8YYd/pXjKcqHxNqSXWzVDst7sYi S47gUav1FUIm2M+kCaDhLp43oW1kCp0VbuzV7I5emGg7Q3KzpbdTf6jEx43pfSGx/s8O Xa4T5yIreB29qHWeKdPmFfkVhtMPshXcWOGt5ihj4E9I/Skr5v7me2o4ICiud9bxHnuR XaP1k5HUKVp5UTHyQenhddGv2IfBy5HQI0+8LXveU/aNKwMCDPjeyKKwWLUrAvvR7SJ8 b7UcXVkLZTl0JdHcv20uwP84ZGfe/AyY1orzVqVuRUk9QDiA8ejn+zAg/rChQduyckjS P3Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781888827; x=1782493627; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0p8Xg9lCiPpDoy4o3VOnxua9XkNhU5aTjFKL7L/TUUY=; b=d7SS4RBTPHmg0F+a6gzpHtY6i0fQKgfw6C+xbQxrxR0+qDM5E5cfMmBaKvtt3w2kc+ cxkjAEevukq32SlvgJCsYT7Vu1fcAEYcRndOf/nkGP0y2ZDjW4MGMNTEy0wxDYviMlaI cMbasKQ8nnzx01KsbBW+Wo92Jbgqvijy3/ZE7s5vMCZywPujpf0ddg1nSGdCe6S91Ksp 4ZAj/NfMna5ib9Qzg8cFsSk8XNf6EmJUNYaVypbjLWu5FOSbeHPIZwCGPGcZRyz91Gs3 WRNWABPVDWDOtMs/WisRWojC9FPcHsX7FA/kjcg0yB3uE5BQfvpvxh6mREw5w5KgOFQA sTvw== X-Forwarded-Encrypted: i=1; AFNElJ+j9GPF1nYoBbizdLthheWQx9u9Sbi87UhP4oeVe5r+Y/r4/84qdSzEN2CzU1QP94D5CwDNJTSxYGkzyQ4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/Bl3ocdrRHe+RjpiynM9NycmMKnrzgjE1pZoIZMRbDJrej7Na RGNJJhU3d6nykQyhOIIbyh8KR22EaaULgE2sHYSsP7Ek8EXER9RVj79ADWYXhXgw5qU= X-Gm-Gg: AfdE7clcN7WIjfE8lCBArSkSt3PQ58KXkMw1EGp8Qu7BhAH5XtJ/FzHW/BOImLZSEId v0rHMzH1hVYIYtwshvsaLc0hh+Ug4aYSZDrBIgoUYCIOwCM0+q0B1fT5S7f88wwosKKUygvX3+9 fI93v68rcrHNbSwuPwlWJ698quq7Ra3CGKFhB2ZX5HYhiWQLd0DFa3ZyhYnNGX1yFcivOSdgvF7 UwmGSQPP7zqcuvwOAGJGoWZacv80CSMxIoZvcq48jRw+IdcCmIsB7eCHvthr70BgSKXDUN3QZ7L y4J+eWOxhJoVuoliqYSrxURNl7lwhb82qS3evq5T0xJszoolseReBbGw7WlPEiUm4AtrafsSmO1 UVRAg06k/Ox6Y2utKjNv08Ot52lzln3+kdk+KiaywYXj3ty3BrVTylBnkX+ChlTbzpzJmL3OU2Q m+bSVR39UqWx+NOOHKVjNxM0UvIBsFDfbPOljD/9tv+3tTjUBs9H7OI2VD13P7SeE0mkTXZ53lB 3hUug== X-Received: by 2002:a05:6214:600e:b0:8ce:abea:4735 with SMTP id 6a1803df08f44-8de42557067mr63574476d6.39.1781888827132; Fri, 19 Jun 2026 10:07:07 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8df81cdf302sm5331856d6.30.2026.06.19.10.07.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 10:07:06 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wacgL-00000004qqF-3F1f; Fri, 19 Jun 2026 14:07:05 -0300 Date: Fri, 19 Jun 2026 14:07:05 -0300 From: Jason Gunthorpe To: Matthew Wilcox Cc: Lorenzo Stoakes , Peter Xu , Alex Williamson , Anthony Pighin , linux-kernel@vger.kernel.org, Kefeng Wang , kvm@vger.kernel.org, linux-mm@kvack.org, "Liam R. Howlett" , Ryan Roberts Subject: Re: [PATCH] vfio: Request THP-aligned mmap for device fds Message-ID: <20260619170705.GC1068655@ziepe.ca> References: <20260616180129.160016-1-anthony.pighin@nokia.com> <20260616163054.77fdb61a@shazbot.org> <20260617192928.GB231643@ziepe.ca> <20260618152805.GF231643@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 19, 2026 at 05:11:50PM +0100, Matthew Wilcox wrote: > On Thu, Jun 18, 2026 at 12:28:05PM -0300, Jason Gunthorpe wrote: > > On Thu, Jun 18, 2026 at 03:55:58PM +0100, Lorenzo Stoakes wrote: > > > Can't we figure this out from what the driver tells us when it invokes an > > > mmap_prepare action? > > > > VFIO installs the pages via fault handler so there is not a naturally > > existing way to pass in the pfn? > > Is there an advantage to doing it this way? I understand why we (eg) > demand-page pagecache, that's obvious. But I've never really understood > the advantage to taking page faults for PFNMAP areas where we don't > really do anything, just figure out which PFN needs to be installed. > It defers page table allocation, I suppose. VFIO has a model where the mapping can come and go, so it makes the entire VMA SIGBUS from time to time. The only way to do this currently is with faulting. The mm also had races around populating the mmap in the mmap callback and using zap on the inode, faulting avoids those too. Lorenzo may have fixed that with the new interface though Jason