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 1E2E7C7115A for ; Wed, 18 Jun 2025 16:34:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B265F6B008A; Wed, 18 Jun 2025 12:34:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD74B6B008C; Wed, 18 Jun 2025 12:34:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9ED0E6B0092; Wed, 18 Jun 2025 12:34:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9301E6B008A for ; Wed, 18 Jun 2025 12:34:28 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3713DBA3CF for ; Wed, 18 Jun 2025 16:34:28 +0000 (UTC) X-FDA: 83569069416.12.3856D45 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf16.hostedemail.com (Postfix) with ESMTP id AEC2A180007 for ; Wed, 18 Jun 2025 16:34:26 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750264466; 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; bh=K3J4jMs0jSaiBQ9/qhRHY6iQInhpdKw6MVP5XiWtVK8=; b=CPOD1OPjG+ELQEed7EI8odyLaCT6GK8LuuWw0He2rXgS82NMcn2vbjhzt3C1x/VVye7Hxn 3KN0nALgz3WFNhi6jmnE8mtjRqirHLm94Bt77UfLazfSqVZ6DHMzUaWFy9Ek/RNOVYyUgz AqBr17M9Dwl5jIYyfcjE6pwvVQKXANw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750264466; a=rsa-sha256; cv=none; b=MwDilk0HFr+I0SQ7eFi1jHG4XRUQgUtnuQxpFYNr2C80DmNiZFASqowcYdFgQ+v3vFk3a1 P+9/Mpkd8rx9SZgkumf2ZR2Al21877KZ5uRCAGw4YzBI7B/xb3jpfu54J0IWw8euOnmCeL CkW/MNgeAEEQGLreFIZmmZPS2PwG+3c= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 258AD6113B; Wed, 18 Jun 2025 16:34:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF032C4CEE7; Wed, 18 Jun 2025 16:34:18 +0000 (UTC) Date: Wed, 18 Jun 2025 17:34:16 +0100 From: Catalin Marinas To: ankita@nvidia.com Cc: jgg@nvidia.com, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, ryan.roberts@arm.com, shahuang@redhat.com, lpieralisi@kernel.org, david@redhat.com, ddutile@redhat.com, seanjc@google.com, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, kjaju@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, zhiw@nvidia.com, mochs@nvidia.com, udhoke@nvidia.com, dnigam@nvidia.com, 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 Subject: Re: [PATCH v7 4/5] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags Message-ID: References: <20250618065541.50049-1-ankita@nvidia.com> <20250618065541.50049-5-ankita@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250618065541.50049-5-ankita@nvidia.com> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AEC2A180007 X-Stat-Signature: cfzqzh5acqnp4unyycrkx4f4nkcheyj3 X-Rspam-User: X-HE-Tag: 1750264466-139555 X-HE-Meta: U2FsdGVkX1+SGas4j/6alIWivufUrZW7ZlZZyiBuvSFHSST2WDQ7RwpUwL+DBDanxu6QqNRU/yfCZvENPjFcjvldo+VjCIO8EShoP2jTQ/9BtZdWx30rcbU4KRxyWH/oMMqEL2FR1i6qyJwulTcDCn1ht9bHnHeXnErETSIrFmvON4jogzoXxQHd43TF+zKPaebH1xpibG1X54/kfndNcJa3gmana/bTntwKDFJTxHJ4vBwYEW3sEH9QjlHehvO49qA3/r/M93u8nPF9V+TU5hAuoZF80f9fMGJcf/CkZKl8WuiV+J2t9TwhmpYUURYowVHC75VNmRtIGXz2ZaZm+BGahOn+B8H4/ePyYvVmO7dlgghURwnA9GasULNJITFFit3KH6SItbBVdk1LHgo6fNG/WfMcBcz4FFXOY4j5AEWKY5VYgdvNfQo/5aCtoY7Xc1e/TOhyF1h9DuuaOzgnDpROBwXw83Eh6gOKvTxwRKvZAoXnTGled92nLamnVNljAtwEHX+sq9uUB5Y8qpcYHkprVeRel4H7wlG3dmqXcC1beikLqgzwgzaiZLoPoTPAfn/KtA8yAm2HCoGZDzo5rOJTLqmMfrPpWYHOeTSlhz24spuBW7xjvh8DDpz/8nkygRBez+nejA8SUJeCOOHdqHWDW0BSHevgelEFCSBxQjbYZpf1cz1Lnstn8RffTP2sJs4WG1nsuUlsJ5lzIH0HKnjo76FBcI7zzSDoXFg46X3MU9MZ2ftWPHqffBtrSvqJpD5shiJ2SvqYX2/AYaLl/6XMkSz2FHjqXDQs/cr0E5BRlpK+pmDmMyeGBfYEERul2HiuD3kgGdhkb2YuLXIiopskr54lKexNlqYzZimnyibz4BlTsxvNZIzttL0qKOnBgDutOpkoQznchPzLn+OzzVpIUuZXVCHHV9uQir93bzstudoDsKwrU5Oaor7Mwtzsfz8b7xPu3Q9OqMKqq5z C3qqk4kE uDhsYvC6tycIKgvWY3sSOSu6GzO87zDL1AdNIFR33nWn+/1buRCaKPnh7fUo/3l1snd4A5bkxrxJ3epOsMPR1YYle9Xn7yXQ6CV5GXsaMn3L8ZztzXAbZnXHayfGFV1zj7+QvXgHqaBXzkKAfqb4rPcuB5vSzmixXjvQX3FolUlzqOPKC4O3qfuYwGAt08PLiR7HBubMdZPD9afVA1i+TTHthp/1fafYbzIea/cMgyzb90f5r1oAIU2R5b8TLuj7ZqfWzQ6MQbSbfanzu2zjUDXTCMvKue604Y0cXiB9f94dSekuTaO2uLU0sX9zwZzWlpode+rKBYwLDkdfdVctyLeUZOf4sC//BbktQs+Q2bXGD+YHIKuktgIT7xBTfD/sAAl6zoOT8wmqHaqawabCfW92jIhwJGzWPvkvq 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 Wed, Jun 18, 2025 at 06:55:40AM +0000, ankita@nvidia.com wrote: > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index a71b77df7c96..6a3955e07b5e 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1660,6 +1660,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > > is_vma_cacheable = kvm_vma_is_cacheable(vma); > > + /* Reject COW VM_PFNMAP */ > + if ((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)) > + return -EINVAL; It may help to add a comment here why this needs to be rejected. I forgot the details but tracked it down to an email from David a few months ago: https://lore.kernel.org/all/a2d95399-62ad-46d3-9e48-6fa90fd2c2f3@redhat.com/ > + > /* Don't use the VMA after the unlock -- it may have vanished */ > vma = NULL; > > @@ -1684,9 +1688,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > return -EFAULT; > > if (!kvm_can_use_cmo_pfn(pfn)) { > - if (is_vma_cacheable) > - return -EINVAL; > - > /* > * If the page was identified as device early by looking at > * the VMA flags, vma_pagesize is already representing the > @@ -1696,8 +1697,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > * > * In both cases, we don't let transparent_hugepage_adjust() > * change things at the last minute. > + * > + * Do not set device as the device memory is cacheable. Note > + * that such mapping is safe as the KVM S2 will have the same > + * Normal memory type as the VMA has in the S1. > */ > - disable_cmo = true; > + if (!is_vma_cacheable) > + disable_cmo = true; I'm tempted to stick to the 'device' variable name. Or something like s2_noncacheable. As I commented, it's not just about disabling CMOs. > } else if (logging_active && !write_fault) { > /* > * Only actually map the page as writable if this was a write > @@ -1784,6 +1790,19 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > prot |= KVM_PGTABLE_PROT_X; > } > > + /* > + * When FWB is unsupported KVM needs to do cache flushes > + * (via dcache_clean_inval_poc()) of the underlying memory. This is > + * only possible if the memory is already mapped into the kernel map. > + * > + * Outright reject as the cacheable device memory is not present in > + * the kernel map and not suitable for cache management. > + */ > + if (is_vma_cacheable && !kvm_arch_supports_cacheable_pfnmap()) { > + ret = -EINVAL; > + goto out_unlock; > + } I'm missing the full context around this hunk but, judging by indentation, does it also reject any cacheable vma even if it is not PFNMAP on pre-FWB hardware? -- Catalin