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 5C783C3ABD8 for ; Fri, 16 May 2025 06:09:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E6666B00B3; Fri, 16 May 2025 02:09:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 696096B00B4; Fri, 16 May 2025 02:09:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55F1A6B00B5; Fri, 16 May 2025 02:09:26 -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 347786B00B3 for ; Fri, 16 May 2025 02:09:26 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 53DC4C1620 for ; Fri, 16 May 2025 06:09:27 +0000 (UTC) X-FDA: 83447743974.23.4D30E3B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id CBBDD4000F for ; Fri, 16 May 2025 06:09:24 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JbdE3s+U; spf=pass (imf17.hostedemail.com: domain of gshan@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=gshan@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747375765; a=rsa-sha256; cv=none; b=Sw23XEUz6YF2vtvarsdJkT1VagfpF/a8Cnk7ma84UbRAmXxSBkBVD1Uro6/cS9gyyeW3/D uN4YB6HyYKO576EWFpk7ciGubHTt0Ei6XM8sUi3aGsv1Wrru0CVCV5ZiYLB0JgULMW3Lcl XYJQbMtTJfJoSep+NjRmdYRHlPZgM6c= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JbdE3s+U; spf=pass (imf17.hostedemail.com: domain of gshan@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=gshan@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747375765; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oPcG3FsFOiRXpv1XjAvU2NgERd/jyk19PD8+swcCIJ4=; b=Xvf4nQ+xB/ezEG4855GBWbOPBWAndDb7b4GF3DB95FbgQLgsjt4GrUFikfBrS3bRmUN3cz AGDKyjRoexor1BSFwzHY6ceXoTj5B3BVF+T5LUq+TIykSof4Lc2SHeWqI8SUu0+AgtRzUr lAPdR6d3iD42a77qZTVIDkaPUvZVFjA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747375764; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oPcG3FsFOiRXpv1XjAvU2NgERd/jyk19PD8+swcCIJ4=; b=JbdE3s+UTokjoqMXw02pgY8Cs0Ejaa3FWJgsEZk0GdEdfDFZEmxzExM49R8KciNd0NaAtf ixbBKcXVYFvXgShTxFr93fqsl5CD/jeX2ZcrZ73ErFLcTLvDd89OzcBMROP9tqOD4I/Rad KzDl/LnqlPEWMWoR9N/4C+cLtXleeWE= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-581-a4VQbmQDP2S6otEjSFURfA-1; Fri, 16 May 2025 02:09:22 -0400 X-MC-Unique: a4VQbmQDP2S6otEjSFURfA-1 X-Mimecast-MFC-AGG-ID: a4VQbmQDP2S6otEjSFURfA_1747375762 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-30ab4d56096so2141206a91.0 for ; Thu, 15 May 2025 23:09:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747375762; x=1747980562; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oPcG3FsFOiRXpv1XjAvU2NgERd/jyk19PD8+swcCIJ4=; b=Ull2m60CTsnK9XW8ayUoVzT7x2+uJn0RbigElKrUo6oUBtgdhINNQR7WmpnhrfAnzK 54D0SI+44AaVUEjXnhqF0VrhsGR7W5/WI9UBIsYPM3YDS4xCndG4VJFDE9X2JSO/F5l1 CxDKCf6uBMMFBoPq79tn1YZS+oXKN6DWy8XydEiBxOudqdw/8P6shwArYUAgwfiWqovR CGKD29/Hpj4MtBG1o2Z69s2ctkJsGMN1FgoX0CJkD89MDqHEdlK0j3quL+u2QVtevaH8 bxa5rf7bNUYQqgV34wFgfjlE2ey8w5E2zj8qHsgKSM0NTZgPupEeMQSH5YA9HDvdywgn mqzg== X-Forwarded-Encrypted: i=1; AJvYcCVUgYL7JYqshfpuRewP3HMmCg4yOvU/ZBBRdARujbpRpSmspH1Nmhg6fk5JDgs+qyO7VymvVPqL1Q==@kvack.org X-Gm-Message-State: AOJu0YzqycXg/9JknpVCdANRJs2Es1+Qdse5zAqc6hGRpLgBinMiKdRf VmJvjwxfj5xyXKmKMJ6VRPYD0y5x9h0Uao+ezz9MfCggXJOq6oXHDVwQKaYo0DSQyg6jhzRdWmn +AzVE5JwZiO3ZTpILCtBMUAn4ez90k3gc7GoqK3aLh+x+qSOSbi/x X-Gm-Gg: ASbGnctlXoHfr5san8T0gj2yQJ/knITfcZpEfHrwcswgbQCjgjnohc1TCDEohtPuGtf vUeTG4Wj+JR4arCJYzQcrzyp7OXrTZQDEbP7QmuE5D9fG2BJBwbRb1UM3bKoToH2utroVMMgfG1 HTkxAh5Ftioeh55D8lOPE+RPAid3eoXnpmujLqAl+v0y+GlIbRltgjDu9X759OXjHAixKAqdbLo VW3LEZTXoxfoGrJpX5tdhzYUCVxVeFTPlv/euXMoQB4ZwIKflW46FPFolT2phmt+TMNyoIdEU6c f9HHeHENcVZg X-Received: by 2002:a17:90b:33c2:b0:2fe:afa7:eaf8 with SMTP id 98e67ed59e1d1-30e7d50b040mr2667249a91.13.1747375761694; Thu, 15 May 2025 23:09:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEH5a8qqAjTmy08j8thqP+B00LVXrWtv611P5leiCrTuccrUC6wK6bUstDZ0smUsTwppAcRCA== X-Received: by 2002:a17:90b:33c2:b0:2fe:afa7:eaf8 with SMTP id 98e67ed59e1d1-30e7d50b040mr2667176a91.13.1747375761099; Thu, 15 May 2025 23:09:21 -0700 (PDT) Received: from [192.168.68.51] ([180.233.125.65]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30e7d4892c3sm825602a91.12.2025.05.15.23.09.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 May 2025 23:09:20 -0700 (PDT) Message-ID: Date: Fri, 16 May 2025 16:08:59 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 07/17] KVM: guest_memfd: Allow host to map guest_memfd() pages To: Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org Cc: pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com References: <20250513163438.3942405-1-tabba@google.com> <20250513163438.3942405-8-tabba@google.com> From: Gavin Shan In-Reply-To: <20250513163438.3942405-8-tabba@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: oC-KDpzVhKA0SoWnqGqNEASEhPQtZQIkuHqbUJCUMQo_1747375762 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: CBBDD4000F X-Stat-Signature: qgufwapk1j5o58qzu9fhbqpaiu17d9ce X-HE-Tag: 1747375764-376415 X-HE-Meta: U2FsdGVkX19296NT3P1bIvkwlK/XjyK+dZw3/Buo6NDMN8tcgd5wRUMVsm7mNfQAI1ipStnWAL0SX0uh9zIl8xh/cfc0Wc1L24nmvfxeQmuirmkN0mcz+D+NFnk7K39OYwoDIjwPmYu20NxFFIOeMWQWxrMoMLf1FEOgFq01r1l0xnOtihOHyGpfEVPierbPiXfxDpIwYHkcEmNwMeChOUE/O/A/xpCc+DIiyhHlMomQGCOtwHEyknS+WxLoc8IMCSlz6LBsH6aWzA50uNEOuq69cZEdvkAXlja120gSchptA9PFnaPPOu3/dIF9kZCpMhMU3pqs/xPenH1cjg0ScyV4Y95U7SlhAmEVU1KMEjBCyRQoj8B+jFB739iG2ffmVIBMxZPt0zF31b+5szTDgixtn+OT6d7RK80/Gf98o7bG+cPyuOKoIPAgXcPdkZG2Gn5tF83u7EazIkBM5YyhLQqXs7dynt+u779g2z8BNk3eeMqVP+KKRiRYylswC0fqvZHogG+zBKTWz2nTJsslctTPChPIQA4XZMFI/E0xVQ7iBhRCXi1DYi1Y+i/JOuQ04b3DdwMDsqflK6RmtZGt8aLleQfvqTeQ5jUEyKwDjAZlGWDmy+id4C/eyOayVWw/dGTzkmTQNdXiLNtOcMeqSXBLAaY7SRWOEgV+ybHL9i3/PB2w3qR4HNESU7m6YjvRFBk8K87yDbWBluwabHpFgqdh5IjayYXNJipwkpSQXkhNHxZORxXdJvDfXMqLvtjuk/qESe67JfRwL1aBwROjfft2Px2pljKMo0xO98ARKCequ38ARIklb250ji4gGOBF+ibnoduGjPcW8uUeJYzfdtQeUGLr9M07V7ZF2I8x1gfC0UH9DtPSP5f+HR1gqa3t49B3NOAFiLRJl7pGvL5cMCHe8geKhTxRx0jygV7aBConvRW29QC1jKy6I8aj4b9F+qpQf8Ulu8TtMsp3GY3 Lj0zs3gr dK2zwBjFmtVt9BYbJi01Fm1pXxwm/9vUYBJAfW3uWBCsAXlGz9ig+NsDkC4CVQ/qSbEJtDSXwMKRT/X/YAZrJRRUm51aHlgmhUT7QABULIwc7fbyhbKqdjbBWYIS1kRLZv5dxJK82SHVUSNMLv5wXqujqBS+saZ0FfuSj4w54ZZGkTpZBeg1hz1g9bE4xc3Ip7YV93T/2XCCuoBI+o6QWJ4DoVeb60oNTrZIbN1tc4nhRmmx0eTTkPfS+i5z1+X7YlTdDKFagpgb3jX//whUWN+gYr3l+Kn649QuseT++gyaUYVhl8DGYYx5gqN9LCbY/M0iy+A7Z5NwnkC+TFmJybHJ9v8hwuKBYA4si5xf01zAFUJHAqryCzlKhIc4M/BbCBBU3wE/vPhWULhpLdAMd+fl64UTde8iXqqPsvBnohE4nhK0qBeMV7mWNeVKNBhjZVf8Je/NZQckihdJ7ZIX71Apqn0blWeHkPawOfvEG0yKv0dOWIA+BvY6xrKIf9LDwMPn3afqGdT9UDmnSckockLTx5oY4DsiwkhyN8TyDKvc3FIFfFOi22Yx+tg== 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: Hi Fuad, On 5/14/25 2:34 AM, Fuad Tabba wrote: > This patch enables support for shared memory in guest_memfd, including > mapping that memory at the host userspace. This support is gated by the > configuration option KVM_GMEM_SHARED_MEM, and toggled by the guest_memfd > flag GUEST_MEMFD_FLAG_SUPPORT_SHARED, which can be set when creating a > guest_memfd instance. > > Co-developed-by: Ackerley Tng > Signed-off-by: Ackerley Tng > Signed-off-by: Fuad Tabba > --- > arch/x86/include/asm/kvm_host.h | 10 ++++ > include/linux/kvm_host.h | 13 +++++ > include/uapi/linux/kvm.h | 1 + > virt/kvm/Kconfig | 5 ++ > virt/kvm/guest_memfd.c | 88 +++++++++++++++++++++++++++++++++ > 5 files changed, 117 insertions(+) > [...] > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > index 6db515833f61..8e6d1866b55e 100644 > --- a/virt/kvm/guest_memfd.c > +++ b/virt/kvm/guest_memfd.c > @@ -312,7 +312,88 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn) > return gfn - slot->base_gfn + slot->gmem.pgoff; > } > > +#ifdef CONFIG_KVM_GMEM_SHARED_MEM > + > +static bool kvm_gmem_supports_shared(struct inode *inode) > +{ > + uint64_t flags = (uint64_t)inode->i_private; > + > + return flags & GUEST_MEMFD_FLAG_SUPPORT_SHARED; > +} > + > +static vm_fault_t kvm_gmem_fault_shared(struct vm_fault *vmf) > +{ > + struct inode *inode = file_inode(vmf->vma->vm_file); > + struct folio *folio; > + vm_fault_t ret = VM_FAULT_LOCKED; > + > + filemap_invalidate_lock_shared(inode->i_mapping); > + > + folio = kvm_gmem_get_folio(inode, vmf->pgoff); > + if (IS_ERR(folio)) { > + int err = PTR_ERR(folio); > + > + if (err == -EAGAIN) > + ret = VM_FAULT_RETRY; > + else > + ret = vmf_error(err); > + > + goto out_filemap; > + } > + > + if (folio_test_hwpoison(folio)) { > + ret = VM_FAULT_HWPOISON; > + goto out_folio; > + } > + > + if (WARN_ON_ONCE(folio_test_large(folio))) { > + ret = VM_FAULT_SIGBUS; > + goto out_folio; > + } > + I don't think there is a large folio involved since the max/min folio order (stored in struct address_space::flags) should have been set to 0, meaning only order-0 is possible when the folio (page) is allocated and added to the page-cache. More details can be referred to AS_FOLIO_ORDER_MASK. It's unnecessary check but not harmful. Maybe a comment is needed to mention large folio isn't around yet, but double confirm. > + if (!folio_test_uptodate(folio)) { > + clear_highpage(folio_page(folio, 0)); > + kvm_gmem_mark_prepared(folio); > + } > + I must be missing some thing here. This chunk of code is out of sync to kvm_gmem_get_pfn(), where kvm_gmem_prepare_folio() and kvm_arch_gmem_prepare() are executed, and then PG_uptodate is set after that. In the latest ARM CCA series, kvm_arch_gmem_prepare() isn't used, but it would delegate the folio (page) with the prerequisite that the folio belongs to the private address space. I guess that kvm_arch_gmem_prepare() is skipped here because we have the assumption that the folio belongs to the shared address space? However, this assumption isn't always true. We probably need to ensure the folio range is really belonging to the shared address space by poking kvm->mem_attr_array, which can be modified by VMM through ioctl KVM_SET_MEMORY_ATTRIBUTES. > + vmf->page = folio_file_page(folio, vmf->pgoff); > + > +out_folio: > + if (ret != VM_FAULT_LOCKED) { > + folio_unlock(folio); > + folio_put(folio); > + } > + > +out_filemap: > + filemap_invalidate_unlock_shared(inode->i_mapping); > + > + return ret; > +} > + Thanks, Gavin