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 B20E7C282EC for ; Tue, 18 Mar 2025 19:41:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C8A8280002; Tue, 18 Mar 2025 15:41:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54FC7280001; Tue, 18 Mar 2025 15:41:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CA5C280002; Tue, 18 Mar 2025 15:41:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1E150280001 for ; Tue, 18 Mar 2025 15:41:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7F3E8C0887 for ; Tue, 18 Mar 2025 19:41:06 +0000 (UTC) X-FDA: 83235690132.06.3AEC5A9 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf10.hostedemail.com (Postfix) with ESMTP id 6E60FC0003 for ; Tue, 18 Mar 2025 19:41:04 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=oep+1Plb; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742326864; a=rsa-sha256; cv=none; b=PFtRTn4Hrn6EhhECHe8Cu2sdyhUEC4avYIrI0uuudrNfN0KFcyZoE0ka/g3rpm8p6OKHvh tX+edNpK/pXB8aZ+4r0DuMBOGGUL3qd2a3o/7u5qatKrOG9j/ea2l/wGpv92K5ZgQI9+pq 1f8IM6F/KwvLsB2Si1+eCujEFgkw73k= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=oep+1Plb; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of oliver.upton@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742326864; 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=NR2Dj2DPN3F/JuAMDyd3/Po1SaaWRiipA/wuwjQg+vI=; b=zKFx634ZnCpmo2I1w13kz0vAiMoE9J70Gf8Wud6ufzNntNDo3sX0yL/Eq192ZTMltQ9DxT HZ8AGuSqyZ1uJNhsN+RikJc5NLc+yBcEAY8DZGOD4wzLFYx0Fr0zDU9R4rq8nLk8E7AVTx pYXE2ZvRW1lra3XWxOnEuLbhZXL8yIU= Date: Tue, 18 Mar 2025 12:40:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742326862; 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=NR2Dj2DPN3F/JuAMDyd3/Po1SaaWRiipA/wuwjQg+vI=; b=oep+1Plbv4PtXj/KFEU6POj20mcYFIxJC6aM2OoJMVG1c6i5Yyu1rzfpAFzF3pNTvSUTAu gpmVeRqi7AJI/nltKtsdsFJzz6qmTGXNp+pfXcSZ3RAyDfWCYk73LSTb3/GZcykFXtMj/9 EgjkBH4IyswSiu8r/u4oGO6AYN5ujXA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: David Hildenbrand Cc: Catalin Marinas , Jason Gunthorpe , Marc Zyngier , Ankit Agrawal , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "will@kernel.org" , "ryan.roberts@arm.com" , "shahuang@redhat.com" , "lpieralisi@kernel.org" , Aniket Agashe , Neo Jia , Kirti Wankhede , "Tarun Gupta (SW-GPU)" , Vikram Sethi , Andy Currid , Alistair Popple , John Hubbard , Dan Williams , Zhi Wang , Matt Ochs , Uday Dhoke , Dheeraj Nigam , Krishnakant Jaju , "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" , "ddutile@redhat.com" , "tabba@google.com" , "qperret@google.com" , "seanjc@google.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags Message-ID: References: <86r033olwv.wl-maz@kernel.org> <87tt7y7j6r.wl-maz@kernel.org> <8634fcnh0n.wl-maz@kernel.org> <86wmcmn0dp.wl-maz@kernel.org> <20250318125527.GP9311@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 6E60FC0003 X-Rspamd-Server: rspam05 X-Stat-Signature: 81bhwjkf48ri356fh4pq44z45yrmtwna X-HE-Tag: 1742326864-610677 X-HE-Meta: U2FsdGVkX1+IGp1Dqs4LBjwiX+ksS/x54rsW91wld4E5FESaQ/kdybZ2zqkuC6vXU5yjyale0awDEpBkVKDOkRHRhzWRwALfg72HhRTVCXjJqRF13hG7FgAVjLR3vIcBHbNKD8lhEV5fSYu/FtvnnVtNrFDWP0Mqklh4/g4Sx6OWFsddfq8KwPJ0RCptgfMmOkT+1ykvEKqUpqO+Wmry6/29/8/9pP6xkJ+oTCDbx5+JIUPnSYxGjrOztPmG2BvIGA/ZKe2EeqXLB/VQZP0K0ler0VPtgA05tLWNb1/BRSioHEjhQM70n8oK0RyHwpOjwvHpPe+IZECFkcUHM8beWAiGHG7W4+paY8uDTY8WeWuDxRrePD2MVcI4Zo4d6xIogp1KmsV0XHpxuevCKHb+/q/w1oskZB1CgzuMcAOt5JTvvyoZBc/PS3Ajjqdzb9aF/IggQNWkpzCGNOQi9GiPvBAdn3dUo/f64XIabZ7j+HL1aKj4FRDalzR2iJp0sokjF7yEhso+SoLRc62pMkB17wgzMaMFNu9kuPt2ZBiAKiih4mxNewCGRvOi40gdkayfO8tPx/wsqiEVEc4pXG8QtsZWLz5b8J0jeBYEO+vGtv30z5ssaasFaYrvnPU5W9UVjD41p3kMVnIhqHgW6f3iwRpAHTOxP48Hs3oGapB7PQhJ15Vg07TGWKlh/Fsxc4gJGST+a6a8YWSCvxZuHqBoloV/vgOo9aCk/QE8/N/OYrED34Zkx/kiibrmjZiHx58wdOz1eP9XGG4pLc4lZ0atMtsmj19GCAUUqmqsC7V9P0K7oAyAeWQpYgN2r4stpf6ViDkb4/li8lSG/IvRM5o5GwD3JFygUxw5mOIebKeeMIUdrDBX+/yU/2UcRMj1jpMXfHKVw8PIqaPLJgep2pEC/4rXLcLdDrYV6fUyc5TEo7qCgys7dv8aly1efA6ztqYJfoQ2vc42VRBy4Qs5jNC wf9yPVKm +tQeqmTIJODaa8VSYtLwCXvq3+3Or2os1I1SZ1Kn24U7d6rUbkQY0+nHNjsHQTWLA0zL7F4nwN8RGtYrgC4q3oyTNND5YZEgbIGV7V4/YXoyw8Dq9oh6RY82mkP6EW1Fe0cw4Jd5i7scW3BHENLlnFOI6nsgLeMbxcpy4SdkygYE4aXRmZuu/+taAvMmua5W30PCzDpST7Dyd8DnvXCrlelsFV+AfvIJhEU4J 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 Tue, Mar 18, 2025 at 08:35:38PM +0100, David Hildenbrand wrote: > On 18.03.25 20:27, Catalin Marinas wrote: > > On Tue, Mar 18, 2025 at 09:55:27AM -0300, Jason Gunthorpe wrote: > > > On Tue, Mar 18, 2025 at 09:39:30AM +0000, Marc Zyngier wrote: > > > > The memslot must also be created with a new flag ((2c) in the taxonomy > > > > above) that carries the "Please map VM_PFNMAP VMAs as cacheable". This > > > > flag is only allowed if (1) is valid. > > > > > > > > This results in the following behaviours: > > > > > > > > - If the VMM creates the memslot with the cacheable attribute without > > > > (1) being advertised, we fail. > > > > > > > > - If the VMM creates the memslot without the cacheable attribute, we > > > > map as NC, as it is today. > > > > > > Is that OK though? > > > > > > Now we have the MM page tables mapping this memory as cachable but KVM > > > and the guest is accessing it as non-cached. > > > > I don't think we should allow this. > > > > > I thought ARM tried hard to avoid creating such mismatches? This is > > > why the pgprot flags were used to drive this, not an opt-in flag. To > > > prevent userspace from forcing a mismatch. > > > > We have the vma->vm_page_prot when the memslot is added, so we could use > > this instead of additional KVM flags. > > I thought we try to avoid messing with the VMA when adding memslots; because > KVM_CAP_SYNC_MMU allows user space for changing the VMAs afterwards without > changing the memslot? Any checks on the VMA at memslot creation is done out of courtesy to userspace so it 'fails fast'. We repeat checks on the VMA at the time of fault to handle userspace twiddling VMAs behind our back. VM_MTE_ALLOWED is an example of this. Thanks, Oliver