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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 796FFC83F03 for ; Fri, 4 Jul 2025 16:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6AAB6B805C; Fri, 4 Jul 2025 12:04:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D19BC6B8059; Fri, 4 Jul 2025 12:04:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C09EF6B805C; Fri, 4 Jul 2025 12:04:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ACD666B8059 for ; Fri, 4 Jul 2025 12:04:30 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 66C9D1A0169 for ; Fri, 4 Jul 2025 16:04:30 +0000 (UTC) X-FDA: 83627054700.18.341D35D Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id B73C9C001C for ; Fri, 4 Jul 2025 16:04:28 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tU7+z4FY; spf=pass (imf22.hostedemail.com: domain of will@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751645068; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Zr1cPFt1ocI87tcXWWTIGTy3VVDZtRQqFIo86Zh/iAA=; b=tjs4/xxONaOUQFWn/8oSqa7GoEsKtPpHG3FenADPXrIg0J6MYTGTrnk8qhHselBsBXI0Q9 vKiotzRCpWeC15FxFBjL0yirK0db8PpctlWUAf3n5ltxWRdrGsV8acuegoXPp5DbSB53TM MWw8+GxmtZyZR8tGRb6kYxUj51+DXiA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tU7+z4FY; spf=pass (imf22.hostedemail.com: domain of will@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751645068; a=rsa-sha256; cv=none; b=bhMvyMpV6MYW7gthMF1vyb7mycYHeeW+oppwlIq/kAhDHCZs6U64Oz3HC6IN+GmZJDG6AU s0b5P4VvMTy8Khnwh94XejO52el9KU4HQ3wQQMveSQ31HJWkkqsXk4K4HnPnucjXaLc8K1 tUeaw6c1qu9Nu0LGPkZB7kAl976QkxY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C185360054; Fri, 4 Jul 2025 16:04:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DEA0C4CEE3; Fri, 4 Jul 2025 16:04:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751645067; bh=M9n2Q9cXb3bGzai3G9o0+Afu6gYoxXbovRVunTPC6tQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tU7+z4FYuh0BVlLIvRisojhalfOl91C0FNBPhC7Xq/ur/19ujU8uZOP8Vfh8ft/IP xpkCMrVGdW0UecnEOmcxvvOVaIaJcbjHzaXOk4kKRES5AWDiQlWSpwh+bzY8ekCaU1 SvjjRnmpl6Lg9d3THr39a6aVD1vWHi80o/RncyG8r4Sp8QDOpxwkTejBQZkgO14bRu QeI+oVIOyPMxQgXaAnVDt5Imhl+RXCVBz2xEbZqVJ305jUvyoPMCdSjlFB0oSZf+Pd nQ8HOlRj9225heyBvWv2GBkEhbb/lHmFZaFEDIctjblBDGohhg4Fk+3zdwuHCQstFe 0BmXU07FbmmFQ== Date: Fri, 4 Jul 2025 17:04:17 +0100 From: Will Deacon To: David Hildenbrand Cc: Jason Gunthorpe , Ankit Agrawal , "maz@kernel.org" , "oliver.upton@linux.dev" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , "ryan.roberts@arm.com" , "shahuang@redhat.com" , "lpieralisi@kernel.org" , "ddutile@redhat.com" , "seanjc@google.com" , Aniket Agashe , Neo Jia , Kirti Wankhede , Krishnakant Jaju , "Tarun Gupta (SW-GPU)" , Vikram Sethi , Andy Currid , Alistair Popple , John Hubbard , Dan Williams , Zhi Wang , Matt Ochs , Uday Dhoke , Dheeraj Nigam , "alex.williamson@redhat.com" , "sebastianene@google.com" , "coltonlewis@google.com" , "kevin.tian@intel.com" , "yi.l.liu@intel.com" , "ardb@kernel.org" , "akpm@linux-foundation.org" , "gshan@redhat.com" , "linux-mm@kvack.org" , "tabba@google.com" , "qperret@google.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "maobibo@loongson.cn" , "pbonzini@redhat.com" Subject: Re: [PATCH v9 3/6] KVM: arm64: Block cacheable PFNMAP mapping Message-ID: References: <20250621042111.3992-1-ankita@nvidia.com> <20250621042111.3992-4-ankita@nvidia.com> <20250630122501.GQ167785@nvidia.com> <4b06b163-e1ce-4c20-b878-4593bc86bf53@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b06b163-e1ce-4c20-b878-4593bc86bf53@redhat.com> X-Stat-Signature: i56gnywbh1ufyxyxwtcaiwbew8n7gtpq X-Rspamd-Queue-Id: B73C9C001C X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751645068-886432 X-HE-Meta: U2FsdGVkX19AF6REKEnVdW4OFlMkiy4HjRwHqUuFFO2X+vq0yGTp37s+ZDaPQbvFW2PazrVTTVh4IcpuO/gbNJVJkWcaikIqoXtF40hoTQ5Cvkmxe9BXWt4GMg/E3exgmtMRrkKQixAw5x8/Hxi49QuszOXHPobQ89XNo5T4woQyCNoLbUDByd4W5WrNs5slLMjy+nsELiyGtuPIl/tmbzcwoE9tCNXz0yvtIyAisnOOxuOT5PmF4fSIeqXEOcTZImwomOfFf7GY95Xzm7F6jAncIv2ewHF/ngC7VTmuUKG0sxuXhPKx4dJXHvOmf9JF2ECuObpRGoyHwCAqmazP3Sg7c+gkJziiBZnEq1yaBaC7UaBWD0Ev8SnkgKmLOhFH2okz323VfdZnhRHiWcNf+QptCkFXVP06CF6E8E0zadVB1LLJqk5zUcblWpa4nnxpat2uvLn0dxitiZnYe55ru+zZ095RMEQmHiI9I9x4JaCK7sqtPjtoePJ2zx3Ey1wvfsos5qCEp4RduRYdwOaQ5CReMscDZxQ5zKeO3tZ7pHJkgdfXSrgxvYOtpEAzEYGRovi83JzJwfaNMsB1GlYcM6CkUTgoJkq2eWVcdkQJvlctl6o292KeLSONViIHO49MZcvixAuS7TOaZwXPruKxU8uApB/mRbWxW4RTgmEO2B8iKrCBN5qWBQVm+0ffoORXQ1s8G2wqm/DJ6QJFDcYzXf5QcT+aaC1c+oOdEDi/rTpr8NTOpkmV6Wh6HAlrvObn8St5hWAU6ezVXvJJgcl5ml0IsW+aFIvwOLUyGkfNJEiHCFXRV6IW+MqJeKP9JkC80EMFk+vspvqQs4JlOAQ/7WEG64u+BA7z55trEyxZ0RH8TZLmMr6fy4yimEeOXL4q+Z9AFmfnzUgl5EE6Jv3lyTi2lyVZ7c3fb+QT7fkdRonXYq2CayXhvTjKauuHanU9RDVGWwjtuVB9jZff+2e JmNc9T9h ASm9TfZSaC7shtng4Wj5hpUjMRGRSj5ECwdGoBXmJVasGSte9yIuVXxhnr0lzo6XbqUcuKPzMhWXaz9dtmJOLlXATPtN5fhqvSGmCV/DqbE+t9oLpQ6p23d9azYgHC5Y/vWEt+oslK/+AXScFObwDAVIsZi1IVzLJ/DVAr0NHSbH8Uf3iCxRWv9wZkiLp2DZnraLCpRwJpSzEt/mKGQ2fvMJayAiIyNKTjQ9GpBWsfD+muKyGZZA/Dyv/RrFqbNubEe6WtRHTW1pu3cuwZwyG6H2OnaAZXcufEfI0WPZKEZQ+pkGgd8tCGoZg3OwdVhYljNyR4odfLLnqBOEDDzpABH7Rqg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jul 04, 2025 at 02:21:32PM +0200, David Hildenbrand wrote: > On 30.06.25 14:25, Jason Gunthorpe wrote: > > On Mon, Jun 30, 2025 at 01:56:43AM +0000, Ankit Agrawal wrote: > > > > Sorry for the drive-by comment, but I was looking at this old series from > > > > Paolo (look at the cover letter and patch 5): > > > > > > > > https://lore.kernel.org/r/20250109133817.314401-1-pbonzini@redhat.com > > > > > > > > in which he points out that the arm64 get_vma_page_shift() function > > > > incorrectly assumes that a VM_PFNMAP VMA is physically contiguous, which > > > > may not be the case if a driver calls remap_pfn_range() to mess around > > > > with mappings within the VMA. I think that implies that the optimisation > > > > in 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device > > > > MMIO") is unsound. > > > > > > Hm yeah, that does seem problematic. Perhaps we need a new > > > vma flag that could help the driver communicate to the KVM that the > > > mapping is contiguous and it can go ahead with the optimization? > > > E.g. something similar to VM_ALLOW_ANY_UNCACHED. > > > > I think Paolo has the right direction - remove any attempts by KVM to > > expand contiguity, it should only copy the primary's PTEs and rely on > > the primary to discover contiguity. No new flags. > > 100% The part I don't understand, however, is that I can't see an MMU notifier anywhere on the successful remap_pfn_range() path. So if a driver is using that interface to change the mapping properties of a VM_PFNMAP VMA, how do we ensure that the guest doesn't use whatever stale mappings it's faulted in previously? Did I just miss something? Will