From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF832191F92 for ; Thu, 4 Dec 2025 15:10:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764861011; cv=none; b=GJ2xx0ZmLZssYIRVCYxRCpU53rc+fLzK6mRVuFg9ALZaLBXsr/sf/YYPHNYXlJZc8+0YzVyehO5CS+GwbYCTGUk3s1FtBuwsazJAnhCJxB/lap8Z32ALg7lahWlBi2OUn8MLfNjoHyjZnm0ZHrwP+XYmTQBk/qkHVHrHvMnsNF8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764861011; c=relaxed/simple; bh=hRw909hsYtm2e5B93fgKIIvka/HUziL1SH4ns6RYGS0=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=GFyMqwFZ8afRM4HRGxmdWh+C81lo6UCHAHigIrVfN61HJosbYorCj81AyWajYthFWR4ciKSXGg4+L4jTgRG9mXHd9JnI/YrF/K+VISEszImHXNKEQqUharqfI4e2zgXjGVtLl6jh9Zm3xhM5KgZUI4+dqIYWvYY6zWlvtPFnnzM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LFf2a1gD; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=HdjHzAw1; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LFf2a1gD"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="HdjHzAw1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1764861008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=bmZIhVkJ08vTPyzjfalPJI5Nem6arF0hRCp6AB1TBpU=; b=LFf2a1gD+PgriPbOhaFH2JWhcdhOakOed9mwxUGUVeWIsE2n9ES46kS4/gfYCsIF4tzLZq 6b6dash2giL/TUg5dNZ4sG25xXiRZFZ8sIvqCSHWfiW7doEjzpCSqY3FhdBKJ/b9qEE/Ue f8prR4aR7UUwjeM1RrwyOLpbMk1/tQM= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-395-6ehRGNb4PEGco_TwnjffDg-1; Thu, 04 Dec 2025 10:10:07 -0500 X-MC-Unique: 6ehRGNb4PEGco_TwnjffDg-1 X-Mimecast-MFC-AGG-ID: 6ehRGNb4PEGco_TwnjffDg_1764861007 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8b2194e266aso200978285a.3 for ; Thu, 04 Dec 2025 07:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1764861007; x=1765465807; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=bmZIhVkJ08vTPyzjfalPJI5Nem6arF0hRCp6AB1TBpU=; b=HdjHzAw1zYxxvYVvXi5djhi4oBQQAqbKGxQTD1ZXaY/OTXdka9BjWUqikLn6WnRHfp Sxffbdl8GzPZbjp2ai984xm+MemIQQQ0XJJX9zavUKSmqj4qRWF8Q7KskAMri3HHX54h h1mLfvHN+Y+QGRrqjWebfPGBgwebKPs5X7hzvzQ2vfEp9gOVj5moNKoY4yV0c/6jD/7U S1Rw48Q9KNEJu4mx/2BdbSF6vicTHKaVQq4V2ZMg/OGWtXX/3+HNHCH+AAG58q+jaVHa HfLtUznte9TpKnzhseP008AR3yGJCL3ubQnesoNIqQQxZr1VCJLB2sJD3LqxbCl+XjqO 8byQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764861007; x=1765465807; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bmZIhVkJ08vTPyzjfalPJI5Nem6arF0hRCp6AB1TBpU=; b=XaB1LbdzT8QwaTybd1lR9hOt9stKIEGrY/gfMIZQtJZTU4gKhTAkCvKZUORiZ/ybuu JtT/++sKnSSV0UyeSRKdiWOJgR1rixytAeup4zFcZBr4FDRzNDf/NbWIbP7pqFGb+u3z mB0jUAS1Po5VQNsvgUJ4hIBvWcsrv5kua1gESu0BdmFpEom0TQ41CsLbf/hpp3pddmsI VpZRTErrG2xJUMcjqx3k891H5CIMT0+yUobSdJ96yG0YDNh4yVtxySBivnb187N09ZQh 6IfKQcscFVAlbZH2igYgpd5gFrAmxiNaZG2DNaFoEhduZ0QoicdbPBB9F9oFNF7t/IRz e5mQ== X-Forwarded-Encrypted: i=1; AJvYcCUQeaZyivVAOgp+ywpTIPJaBBihOQcyyOcFugnaXqQgIoP24KZiSLusUJeCDQgYCCmEKp8n14jwxROgcvQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwS8oXC0Jjay/bVF+OvawE9nnT/nhLYrb4ubV5vCyGEGvB9eVBC CGgHtC9MAQ9Xssu4LJRAG089dH4TWNq+hQdi1ioTC8MzuYGxWlC4HQg8rN1e/1SCae6uqjxh27K HYnh9ivWVH2NikrNphPxMescj7ZCglY6bu2i3JOt7Y1WtLnFLMP4c2KjIZAbRb7Zr7w== X-Gm-Gg: ASbGncvgZMQAY2E38MNjkIUKljFrakXVZYoY9C8eFjwciRZJRGFWbJniX/bbWuPGR84 la3CmKb9O2AGa6X+1DZSj8xFNz3MHkNlFBUs6FBiZmNXrAj5wQFwuyF7e1SwvntFHem9kq7yWGk QKoYXPMIX+GZyo6JC6Xp15duDpU7milCGZ1WxqhqkQ3+7F0NkOYKZ4UlT3QHeEiW/HwgNRt5Vwd Ko3n/o2220GrOfDBFj8snu4h4EzfcmOcmbYl0McEDqtScttcWqzOFNvL/kPKH0airx+C7o9/NmA B51MIO874MS7/0bQHPL1KDeGRrtzqiD29IuVVk5KgRi0OnAkkWORSGNwZzsiRjzFmoYIKv4sWLL l X-Received: by 2002:a05:620a:280d:b0:8b2:f29e:3b00 with SMTP id af79cd13be357-8b5e6a905e1mr808458485a.51.1764861006782; Thu, 04 Dec 2025 07:10:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IEyH0V7BtmZhH2ckfMcjK9avGlDSwL+lIn0HZdyHGEVc1fLrFDrwIW691WvbiU7DsS62jiCgw== X-Received: by 2002:a05:620a:280d:b0:8b2:f29e:3b00 with SMTP id af79cd13be357-8b5e6a905e1mr808450985a.51.1764861006226; Thu, 04 Dec 2025 07:10:06 -0800 (PST) Received: from x1.com ([142.188.210.156]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b627a9fd23sm154263285a.46.2025.12.04.07.10.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Dec 2025 07:10:05 -0800 (PST) From: Peter Xu To: kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Jason Gunthorpe , Nico Pache , Zi Yan , Alex Mastro , David Hildenbrand , Alex Williamson , Zhi Wang , David Laight , Yi Liu , Ankit Agrawal , peterx@redhat.com, Kevin Tian , Andrew Morton Subject: [PATCH v2 0/4] mm/vfio: huge pfnmaps with !MAP_FIXED mappings Date: Thu, 4 Dec 2025 10:09:59 -0500 Message-ID: <20251204151003.171039-1-peterx@redhat.com> X-Mailer: git-send-email 2.50.1 Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series is based on v6.18. It allows mmap(!MAP_FIXED) to work with huge pfnmaps with best effort. Meanwhile, it enables it for vfio-pci as the first user. v1: https://lore.kernel.org/r/20250613134111.469884-1-peterx@redhat.com A changelog may not apply because all the patches were rewrote based on a new interface this v2 introduced. Hence omitted. In this version, a new file operation, get_mapping_order(), is introduced (based on discussion with Jason on v1) to minimize the code needed for drivers to implement this. It also helps avoid exporting any mm functions. One can refer to the discussion in v1 for more information. Currently, get_mapping_order() API is define as: int (*get_mapping_order)(struct file *file, unsigned long pgoff, size_t len); The first argument is the file pointer, the 2nd+3rd are the pgoff+len specified from a mmap() request. The driver can use this interface to opt-in providing mapping order hints to core mm on VA allocations for the range of the file specified. I kept the interface as simple for now, so that core mm will always do the alignment with pgoff assuming that would always work. The driver can only report the order from pgoff+len, which will be used to do the alignment. Before this series, an userapp in most cases need to be modified to benefit from huge mappings to provide huge size aligned VA using MAP_FIXED. After this series, the userapp can benefit from huge pfnmap automatically after the kernel upgrades, with no userspace modifications. It's still best-effort, because the auto-alignment will require a larger VA range to be allocated via the per-arch allocator, hence if the huge-mapping aligned VA cannot be allocated then it'll still fallback to small mappings like before. However that's from theory POV: in reality I don't yet know when it'll fail especially when on a 64bits system. So far, only vfio-pci is supported. But the logic should be applicable to all the drivers that support or will support huge pfnmaps. I've copied some more people in this version too from hardware perspective. For testings: - checkpatch.pl - cross build harness - unit test that I got from Alex [1], checking mmap() alignments on a QEMU instance with an 128MB bar. Checking the alignments look all sane with mmap(!MAP_FIXED), and huge mappings properly installed. I didn't observe anything wrong. I currently lack larger bars to test PUD sizes. Please kindly report if one can run this with 1G+ bars and hit issues. Alex Mastro: thanks for the testing offered in v1, but since this series was rewritten, a re-test will be needed. I hence didn't collect the T-b. Comments welcomed, thanks. [1] https://github.com/awilliam/tests/blob/vfio-pci-device-map-alignment/vfio-pci-device-map-alignment.c Peter Xu (4): mm/thp: Allow thp_get_unmapped_area_vmflags() to take alignment mm: Add file_operations.get_mapping_order() vfio: Introduce vfio_device_ops.get_mapping_order hook vfio-pci: Best-effort huge pfnmaps with !MAP_FIXED mappings Documentation/filesystems/vfs.rst | 4 +++ drivers/vfio/pci/vfio_pci.c | 1 + drivers/vfio/pci/vfio_pci_core.c | 49 ++++++++++++++++++++++++++ drivers/vfio/vfio_main.c | 14 ++++++++ include/linux/fs.h | 1 + include/linux/huge_mm.h | 5 +-- include/linux/vfio.h | 5 +++ include/linux/vfio_pci_core.h | 2 ++ mm/huge_memory.c | 7 ++-- mm/mmap.c | 58 +++++++++++++++++++++++++++---- 10 files changed, 135 insertions(+), 11 deletions(-) -- 2.50.1