From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 28B25CE8E73 for ; Thu, 24 Oct 2024 13:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JNDCnEMK94RxIjgd1jRoMTCZvgeWFfMq1mwlKhWgZUo=; b=OuuKLDkAlcMx/eUR1cK2u9Zgsu 7nUsmnZfPTtqGZ2txDhszbMp/vuEVxschBhuz0GFkehhryBEFxcWYM8n6LPxmbi9qGUdiV5qjJ3H8 otTCRCPjnYq+vxxg/8LNNY7jj++Dg4/XtCh2KPetg9gFV6OjIBYAyOnNRzgEWLibHwrxponUx+JUI 57kw6r2jodh15w6ggvnGe+dqcXuRzIWUpun4Iyg8ua2YuKfOjH6UJKhHfbRIte7N5MnAW/4AncX5E K0pWB5B3yWIvggaFMdMbi27U6JeK9SZEVcs55w/Lq8agIMm9Q3aGui0dbjhpYb6qhbj7lbk3vv0ny SBBlmprA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3xYt-00000000RKm-3cV2; Thu, 24 Oct 2024 13:07:35 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3xXL-00000000QwY-1tEW for linux-arm-kernel@lists.infradead.org; Thu, 24 Oct 2024 13:06:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 5C76DA4540C; Thu, 24 Oct 2024 13:05:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79411C4CEC7; Thu, 24 Oct 2024 13:05:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729775158; bh=QXk1V7bH3HsTPiuM9A5Py2vZdwbkg6MWH803SOVsaJ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vy1Wn4fLlykC16tJY9EfRKt3126lvfGKufGOM2l0XlojP1032MOTW502xrrPTywyV 7Y69l4ulKnMB3iVxDKBaWdiHt+3LGuqNttl8YRItkAI3MzFSIvjfDjADzGcwCu4QPo oVMqArtpEcrXEoIT+Noe46x2BFsVNjtLtp+5vmkOIr1A4jwvVZnTmW3Nqqo9rnI4mA N0P0leVPPbKzcS+U68XbM42bL1qeS0CFMha/ha1PQk+vXDdznGF5M0aEQmPY51S8iy EI5eUEGub5heUuD/638YAHa/pS8V/4jbNgLRfJBpGxVjOwrQweu0clK9gwGog1w3XI Wziem035r2IIA== Date: Thu, 24 Oct 2024 14:05:53 +0100 From: Will Deacon To: Jason Gunthorpe Cc: iommu@lists.linux.dev, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Robin Murphy , Boris Brezillon , dri-devel@lists.freedesktop.org, Liviu Dudau , patches@lists.linux.dev, Steven Price Subject: Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior Message-ID: <20241024130550.GE30704@willie-the-truck> References: <0-v1-8c5f369ec2e5+75-arm_no_split_jgg@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0-v1-8c5f369ec2e5+75-arm_no_split_jgg@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241024_060559_577564_80F6D372 X-CRM114-Status: GOOD ( 20.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jason, On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote: > Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART) > arm_lpae is unique in how it handles partial unmap of large IOPTEs. > > All other drivers will unmap the large IOPTE and return it's length. For > example if a 2M IOPTE is present and the first 4K is requested to be > unmapped then unmap will remove the whole 2M and report 2M as the result. > > arm_lpae instead replaces the IOPTE with a table of smaller IOPTEs, unmaps > the 4K and returns 4k. This is actually an illegal/non-hitless operation > on at least SMMUv3 because of the BBM level 0 rules. > > Long ago VFIO could trigger a path like this, today I know of no user of > this functionality. > > Given it doesn't work fully correctly on SMMUv3 and would create > portability problems if any user depends on it, remove the unique support > in arm_lpae and align with the expected iommu interface. > > Outside the iommu users, this will potentially effect io_pgtable users of > ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and > ARM_MALI_LPAE formats. > > Cc: Boris Brezillon > Cc: Steven Price > Cc: Liviu Dudau > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/io-pgtable-arm.c | 72 +++------------------------------- > 1 file changed, 6 insertions(+), 66 deletions(-) I'd love to drop this, but I'm sure it was needed when I added it :/ My recollection is hazy, but I seem to remember VFIO using the largest page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then using the smallest page size for unmap() requests, so you'd end up cracking block mappings when tearing down a VM with assigne devices. Is this what you're referring to when you say? > Long ago VFIO could trigger a path like this, today I know of no user of > this functionality. If so, please can you provide a reference to the patch that moved VFIO off that problematic behaviour? Thanks! Will