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.133.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 DE6033C09FA for ; Wed, 17 Jun 2026 14:21:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781706118; cv=none; b=Ily9qxA9Jh5J3TZxMr0mXJyuwaKhWibrPv0En00bQDKUXFwlNvfWq6uLfQTcyF5G1LIG1StjFTdmNIYtUJWay+O50hXfXhCbrdIB3JGhjiTAsU8Lj3QV9V3IUFu0ffxNfx4Ge1g5H3+1/bJ70qR9xGYbkXUvl9fYDBNccCqlk0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781706118; c=relaxed/simple; bh=tITp3vI8QCODQTdN3D7k1C5vtWMYgUCUyDY+YluPXsM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ixOi8xqr7eqpMPNJ8aunIlCKtVwyyFfZf2x7NWAPSggEYoCHGe+TO0oYgHj5XJ3wLsguZJUMs9g0KAHJR46FxQf/+B3GTQIPZuhK2eMbNf4UqHthu5Hy/GlMSIksBnRTaW82Ep5tks3PIHUr27Qg5byhHZdwj9LSdhiHq1hc2+M= 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=Tf2Leq6n; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=EmrUOBOd; arc=none smtp.client-ip=170.10.133.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="Tf2Leq6n"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="EmrUOBOd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781706115; 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: in-reply-to:in-reply-to:references:references; bh=ELObF5Iq/B3jkGpc0knxM9Qj8R7NO2xwYgcKK7rlrAQ=; b=Tf2Leq6nrn4ufjW6RwxWoamR//uWPa9drlypCGhZQIpZpe0VwnKo9Ms0o1SFx9omHQXCPQ 8Md/S5Tcy19nR79qZOfYVMeJWvSe0I6ae1kbMNaRZzzWaEGtolgPNoNeLQfL5ysCEiCuU6 TTgueje4MozMmEk/GX1aLU2VwrNDKGg= 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-508-RkYJFyXXP_iF8jQnvRPtLw-1; Wed, 17 Jun 2026 10:21:54 -0400 X-MC-Unique: RkYJFyXXP_iF8jQnvRPtLw-1 X-Mimecast-MFC-AGG-ID: RkYJFyXXP_iF8jQnvRPtLw_1781706114 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-91579011fd1so862190785a.1 for ; Wed, 17 Jun 2026 07:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1781706114; x=1782310914; 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=ELObF5Iq/B3jkGpc0knxM9Qj8R7NO2xwYgcKK7rlrAQ=; b=EmrUOBOdJNUkveNN8EZH7XwTz+W694tGph2Ev0FA0QMPvZlgggV+uyWhWHgV64pUsQ fdsU50lfVCE+itx+J05vOagCZ7r4XLRC4iWo3Dfeb4z9AUTT/Evb+fuJrFTGdIJHJC0s 8L++gdkWTZjiS8V01OEGGlF2KTWABvsVh/ISIMFJ8MeKlyY2NcCU/n++ujOV2d/cb1ha R5Kz0cpNSM91DqS3CDK4UN2bSAZcoUoGwza/kM9jth6uHOIZV9iH+kMYYb05En1tArvH VCXCzIKSOOsmQxY0b0Ix3fQb0vXChJvmjFa9qx0s9TkcbGCqYin7aqH+ebYkNunPxH0v E3Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781706114; x=1782310914; 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=ELObF5Iq/B3jkGpc0knxM9Qj8R7NO2xwYgcKK7rlrAQ=; b=h1vf8uJ70RqsTWUSD9C/1FOw15Gq285H+ZXeTnvOycV9iPXKzVpug2HhJQYo6eCXAx LwrrV04W6NKHq6bJ9Fn5y6Tle8E+Ylys03RR2mxXQ7PPVxUInlaLnuSUFgRFIxubJHxY 46zyj76uQjMfSU9Q0uMFcB/UdsFNiXLMTWxUlMtlrsH3AOyUPt5cpwJf6wRR+lq8yO6X cftjsHAefz46vdbXy8JHfD/wnu+L+bXWOFrwqI77NB92tqLyaFtjoRw2lHPqI7WhkMb4 v+LxjrtXZa+Adyzs+gG7j6u1IkStCan6Zhd5Y3TxQPjr/UyVSZAfyRGepn1+Qdejwc8R vVkA== X-Forwarded-Encrypted: i=1; AFNElJ9uRIrLTqEuwJzOe3o/yv7NPKBsNxGGEX8WZJiWT4YQvIp08Vn9N4CGFb2FphkHXjwd0zghNB4zKswsg+k=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4OuKHhQh/UmYPboMqoilG6Uem0w7i7neZ/aWPowrpOkwH9w86 /Um1EaveMjo2ghjPFPI4/ik6a8BIskVqD1/w8+UdzjtBnbELh+785L+PC3FWEBmDejRL6reGNUA +5ud6kFMt+w4fd9j4oVvU+sOTt3GTeFeDZ5mFsXKOewwJ4Bc4Sc6ZaK137YUcDDExFQ== X-Gm-Gg: Acq92OEoeuHjcc7Q9xk5m7E84RMRTYMEsgC2B2Misjy8UIZwcLQKpwI+ezzeIgjR1jP pjzU1GOqRLRrLjM4D2aiiWkroYbtBneZWMb5JBMyuD2VngKHZTe+a5n7zcGC1SUm449a/lbAZpo ua05C3WV9nhKnJ6iPhuJxcGvGBrfRTq3fMPQPmlngewgn2Y9ny7YNKhnu9fGni5t6lAZlOXm9G8 LimUeZjG+70i46H6Gk6efpzQGqmn+6XihF5TQCY2DwL1GTkP9bwBljmvxNWe8QX94PzavnhwUWX GZewmwoJ0HP3/S9pXJW+PSbKJUoL/eOhnBT9oIutTbr46tqPnVl1ijUCR7sjd3dqm1Nq8I/azX7 0qfA= X-Received: by 2002:a05:620a:29ce:b0:915:c365:ffb1 with SMTP id af79cd13be357-91d8bfb0904mr635622085a.57.1781706113708; Wed, 17 Jun 2026 07:21:53 -0700 (PDT) X-Received: by 2002:a05:620a:29ce:b0:915:c365:ffb1 with SMTP id af79cd13be357-91d8bfb0904mr635618885a.57.1781706113132; Wed, 17 Jun 2026 07:21:53 -0700 (PDT) Received: from x1.local ([174.91.116.48]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9161a006441sm1869207585a.27.2026.06.17.07.21.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 07:21:52 -0700 (PDT) Date: Wed, 17 Jun 2026 10:21:40 -0400 From: Peter Xu To: Alex Williamson Cc: Anthony Pighin , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Kefeng Wang , Vlastimil Babka , Andrew Morton , kvm@vger.kernel.org, Matthew Wilcox , Jason Gunthorpe Subject: Re: [PATCH] vfio: Request THP-aligned mmap for device fds Message-ID: References: <20260616180129.160016-1-anthony.pighin@nokia.com> <20260616163054.77fdb61a@shazbot.org> 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=utf-8 Content-Disposition: inline In-Reply-To: <20260616163054.77fdb61a@shazbot.org> On Tue, Jun 16, 2026 at 04:30:54PM -0600, Alex Williamson wrote: > On Tue, 16 Jun 2026 14:01:29 -0400 > Anthony Pighin wrote: > > > VFIO PCI devices support PMD-sized page table entries for BAR mappings > > via their huge_fault handler (vfio_pci_mmap_huge_fault). However, the > > VFIO device file_operations never provided a get_unmapped_area callback > > to request PMD-aligned virtual address placement from the mmap address > > allocator. > > > > Before commit 34d7cf637c43 ("mm: don't try THP alignment for FS without > > get_unmapped_area"), this was masked by a bug introduced in commit > > ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") which > > inadvertently applied THP alignment to all file-backed mappings, > > regardless of whether they provided a get_unmapped_area callback. > > > > When commit 34d7cf637c43 ("mm: don't try THP alignment for FS without > > get_unmapped_area") correctly restricted THP alignment to anonymous > > mappings and files that explicitly opt in via get_unmapped_area, VFIO BAR > > mappings lost their PMD-aligned placement. Since the huge_fault handler > > requires both the VMA start address and the physical PFN to be > > PMD-aligned, unaligned VMAs force a fallback to 4KB page faults. > > > > For example, a 2GiB BAR results in 524,288 individual page faults > > instead of 1,024 PMD-sized faults, increasing the VFIO_IOMMU_MAP_DMA > > pinning time by orders of magnitude -- a regression directly visible to > > KVM guests during PCI device initialization. > > > > Fix this by providing a get_unmapped_area callback in vfio_device_fops, > > following the same pattern used by ext4, xfs, btrfs, fuse, and other > > subsystems that benefit from THP-aligned placement. > > The trouble is that PMD alignment isn't right either, your 1024 PMD > faults on a 2GiB BAR would be 2 faults on x86_64 with PUD mappings. > QEMU has forced the alignment to make it optimal for some time[1], so > there are userspace VMM options. Seems like you were previously > getting lucky. > > Peter Xu was working on a more comprehensive solution[2] late last > year, but it seems there was an objection to the > file_operations.get_mapping_order() proposal before Plumbers and the > thread hasn't rekindled. > > Gentle bump to Peter and Willy that maybe we could resurrect that > effort. Thanks, Yes, since QEMU doesn't need it, it was low priority on my list (also due to much more downstream works recently, and a lot of things happened). I can definitely try again. I'll wait for another 1-2 weeks in case Matthew would like to provide a better suggestion, otherwise I can send a new version based on what we have, and we can start from there. Thanks, -- Peter Xu