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 E3572C021A1 for ; Tue, 11 Feb 2025 16:57:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63B1B280003; Tue, 11 Feb 2025 11:57:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C4FD280002; Tue, 11 Feb 2025 11:57:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43E42280003; Tue, 11 Feb 2025 11:57:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 20E85280002 for ; Tue, 11 Feb 2025 11:57:36 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C4D56C0412 for ; Tue, 11 Feb 2025 16:57:35 +0000 (UTC) X-FDA: 83108270070.04.3D5392A Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf15.hostedemail.com (Postfix) with ESMTP id DAAFEA0011 for ; Tue, 11 Feb 2025 16:57:33 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=X2JTZmLg; spf=pass (imf15.hostedemail.com: domain of qperret@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=qperret@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739293054; 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=ITTWQB6rCRgMy4jz77x7qgpeW2xyYXF+QL7wz+KsG0Y=; b=3m4oUuY8k9nfpKaSD915tm+2C6dhokLbJN4tesqSBBhJW5ZR3FcHFPkZRB5o1PQqnL3Jfh U5+YcL8LUEmiyUoj7PRN2T+9b/dCGX32d29TQaFiU8fGU6CdqGtf3q7uOoxva3OLZM32vv F6NU1U5RTXlLI9rW+U8S0x1TT4G69Ss= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=X2JTZmLg; spf=pass (imf15.hostedemail.com: domain of qperret@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=qperret@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739293054; a=rsa-sha256; cv=none; b=Omb9DIZrJP4l9jphT45DCF2TgkT+0bGzekTh/1rKha0wA1vDFVGa/7Dujsj01tok96XF4E NCyLnueduWhPrrqbpURIEDOFiGyWUX6sXea5ZrVwdH3exGjZi1GPbPLYKRKKLWQxOp+zxS 2eyh36rVHpD9HfC1un8hUTIAv6ZcEfk= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-ab7b7250256so421311566b.0 for ; Tue, 11 Feb 2025 08:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739293052; x=1739897852; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ITTWQB6rCRgMy4jz77x7qgpeW2xyYXF+QL7wz+KsG0Y=; b=X2JTZmLgVz/c09aAsDh4WXav1dHZ32pnzNmTwx3BJGp7S8SmbFTBMWGB6t0b3g0Zxm OnwHV1SpRQYuS7CVEFp3BHQJhkqLpQxXy4RYbJ8LjSWsJglRghlR+W2ks65yFz9l3trq gZJhpGWqwEbMYbeWP6VbbQAm+h/0338enngIIgwDbf4cuqPWzUynGFbwEayfus+egUi2 c6jXy0LEptnNDAsPdMlErE0nbV/7XBBvDjpTrhHzqJhwOeKIyEO4PBiRy3aMFGJhMA0/ 6jyc4wFN2w3PbZBVuoFpaM8LHkyDLxrEV0mGbPuhs4RhRl7J08yUWS9fKu37nVUhgHiQ qrqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739293052; x=1739897852; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ITTWQB6rCRgMy4jz77x7qgpeW2xyYXF+QL7wz+KsG0Y=; b=p++f1MzHoZp8uCbNNddmoWam4wOK74mcDGUOG1XL/zLXs9UxHFE2gr+jE5qtG0fJ/U eZmOCrzg43x9/NDmLE8rbR7yX0DdUgShaup7IawwS0MDUDh6TUFQet/zk0toU9X9eH9Q FXsleW8wimWbRn9zaOBWZuyKCdLjzAwff1ZYhAikwk7aSmngVp+6QQ7ws88X2X2Z/xyu hQXGLrhPWE2VRrWeumuEislS8kfqj8kHY7toK5ggUsw3nc+Qxi9huR+v8FZxYeaXPy+P vevhUXeYkpUHhlz1Z2yWJjZxAXO+APJEogy+5J3BdrOnFQl1t7FcxDURW7WfNJG/FeyD J5uw== X-Forwarded-Encrypted: i=1; AJvYcCWRww+SSBp8xfcvoj5dDE45J7pQeawMNwq+eT41BCcu6hapIgAEp4A/P75TmrUb74FFOzYJXlXllQ==@kvack.org X-Gm-Message-State: AOJu0YyOGw9FRvfeuHrDRuFJ2/6CICbqlsKWWk0FqXZ392mYAD2yuWQP hEJXLIY/PuTtIHjW/UEn49yKzZzvzh+CBd8Ip4TBDB4GWAZOY4jcuSoS+LHH4w== X-Gm-Gg: ASbGncswfh2BX9LEQhrmi5suoZSllJ5MrWqAwMoFueYde6v8vheMXeDtXtVeia0BBc7 VKf+FBCK3AVzklK9F9xgUA2Djiehd5aeYmzJq/vR/KiE3+aKIQKGNuyjpbJQq3dmDpHECzuQL+p JXuzXjYR/DZGMvVEHBNp80XPHLg3F9KtkWQSYrN6PQwB58pKgKndC0HO3sqXfq63BziWSnh01PC N8MNHIP+mgVjgIU0a67Esi2R53dazJenLxgAY/BKwUCg440e9KSoT2WyfA2PgSE2LqyU/gM4lXP 7ejYwcvQZsyTGD/WSIsL5B/gi/SFCi8nib3ZjTqrUGJvRjxH3Mse X-Google-Smtp-Source: AGHT+IFUs3jK4RIVQ4CQAOv86F0kyLMNTuS8WIFx7I3ccayQfZmTMdyBqNyfcfDIo0b7kmJTS6fEGw== X-Received: by 2002:a17:907:2d24:b0:ab2:ea29:b6 with SMTP id a640c23a62f3a-ab7f01cc9bemr45031066b.35.1739293052108; Tue, 11 Feb 2025 08:57:32 -0800 (PST) Received: from google.com (229.112.91.34.bc.googleusercontent.com. [34.91.112.229]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab7be7ac8a9sm459262466b.39.2025.02.11.08.57.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2025 08:57:31 -0800 (PST) Date: Tue, 11 Feb 2025 16:57:27 +0000 From: Quentin Perret To: Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, 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, yu.c.zhang@linux.intel.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, 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 Subject: Re: [PATCH v3 08/11] KVM: arm64: Handle guest_memfd()-backed guest page faults Message-ID: References: <20250211121128.703390-1-tabba@google.com> <20250211121128.703390-9-tabba@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: i4h693icnedndiczubefnuhqe1mg9pod X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DAAFEA0011 X-HE-Tag: 1739293053-193630 X-HE-Meta: U2FsdGVkX1+mF8nxg1NI92/+HC9EQy0aX/RDSA8QTQfVbS0l09Zs0Vq42pqYbPbxBsNwX1EWfllSWccz/aQ0MWmmiXx+q58jUTHgGdWeQI22/2BDPLVYJaglsgigot8kvJBCJglceBWVgpb7m1HGXATuESkTTUox1oC0wYQ06b3uaLncJrBUzJypnJihCkis/p+aFtWOUR1nHFoB8Fze6p2Mw95oxX2VX69UxlFa4CJ3mfQLxXsFye00nUTt3Dv2HKTS4eSmvspscFbGkeD2AiWMBB2W+4KT1U4d9ZfeA7AnwtMJcgVnBOlNgHAc3iFNOOdIqKltHwF26hmP5wmHEiIVUiMaBTU8wBczvOoKdkFd38kiAJKDGaeC+xQ0ec7HTWe0a4pbq+wUdl1UrpQmfuaWwPm78YC1f5mLoGmTJvsyScutjhcunBHcAASBBwz2rxwKqqugw1deqm+EfMINWQSL94OhbSPBEdfxCDRJNhPOnLCkiyBVFclBo7cNAxlcBOM1jAsOVV7M2idNBwM7bhG4P7iBReOiI+ZdhEnJP1NT88K1VhtfCoT+ge/IdCJDk3UkDu0k1lDg2FOnZQKGYLqGsGFk1Bb1UnZvNjrGhA57ZSihK3rF6dEaTcOwlaYFLraTj30SGv9bm71uOg7NeCwcGQpRziS3sd6q5S6o3EC7/BFldctVCxvoIo5WQdhbb1XRIMMM4LV/7Ppm7vPBEFDuD/s8PVcMHMHuFp1DD6nmDQUf+7eTKQDM/krRW+9LJQYX4viOyCilGms9Fgfyv1HHwmEMR1mF1BJBYcqU4Oi/pDfSw7nKjeKn0CNDbvySP4T4zXEaHnmgyMTqilYLQRyUIo0PibcruorOJJitFhDA5nb3KAZi87CgZ7HD6+lE/HLwqfVCQRFohU4md0JVfxt0rDk4vqIOwJFRQlhdOQ71960qum42ncDqbRMz2Tte0/OvCoUTlZixtWAdRu4 THpjB9YP uJ9fNQcR/rfz4jtBU4bJUVmytwvJMKlXNVNBhM5XpjDeFfX9zoRgyvTnWyLPE0t/bbJaLfS0LH/RLDL1pow5qg8OtT1xTanIcdNux3hvAHWn6LGivVXeA8HrgABaNGcSAgLngFY0VV4AoCJ7g5mOhvu3Czp1gh11/MChT03fFKzxOKbK3zsmwlUUgrhv5ynL7Xvn/Tco8fJ/q303lP2XJBKBhahBOzKZ7HjqPSAYy6sWxMtdKDEfyISFAhMzIJRRlvkFpuQpspJO/wOJ2uMaKrA2np20Ju4R69X7D0sQOjuPwaEnfykkbEm71VM6WRgGa0TpGfYsQCjPfVwfTUpZ9JSDqSYcnggoy0PDfPZmL/+ZaBiVafuvrX5HaFjga6eXx4LOdhy34Eo8uE9qQXHxdmj/Aia3EUuXZYeduCKmAF/KJqkJhciV5Ie+ASAOhRKYzIWsFXWq21H9ltdHd/PTeaWUj/QPMrUqHC+C0ELEk4fYifiU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002431, 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 Tuesday 11 Feb 2025 at 16:34:02 (+0000), Fuad Tabba wrote: > > Sorry, yes, that wasn't clear. I meant that kvm_mem_is_private() calls > > kvm_get_memory_attributes() which indexes kvm->mem_attr_array. The > > comment in struct kvm indicates that this xarray is protected by RCU for > > readers, so I was just checking if we were relying on > > kvm_handle_guest_abort() to take srcu_read_lock(&kvm->srcu) for us, or > > if there was something else more subtle here. > > I was kind of afraid that people would be confused by this, and I > commented on it in the commit message of the earlier patch: > https://lore.kernel.org/all/20250211121128.703390-6-tabba@google.com/ > > > Note that the word "private" in the name of the function > > kvm_mem_is_private() doesn't necessarily indicate that the memory > > isn't shared, but is due to the history and evolution of > > guest_memfd and the various names it has received. In effect, > > this function is used to multiplex between the path of a normal > > page fault and the path of a guest_memfd backed page fault. > > kvm_mem_is_private() is property of the memslot itself. No xarrays > harmed in the process :) Ah, I see, but could someone enable CONFIG_GENERIC_PRIVATE_MEM and related and get confused? Should KVM_GENERIC_MEMORY_ATTRIBUTES=n depend on !ARM64? Or is it KVM_GMEM_SHARED_MEM that needs to depend on the generic implementation being off? Thanks, Quentin