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 96E8EC0219E for ; Tue, 11 Feb 2025 17:19:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 280016B007B; Tue, 11 Feb 2025 12:19:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22F4B6B0088; Tue, 11 Feb 2025 12:19:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D0876B0082; Tue, 11 Feb 2025 12:19:33 -0500 (EST) 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 E4AA5280001 for ; Tue, 11 Feb 2025 12:19:32 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DD4821207DA for ; Tue, 11 Feb 2025 17:19:12 +0000 (UTC) X-FDA: 83108324586.25.275CF0A Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf13.hostedemail.com (Postfix) with ESMTP id E8C722000B for ; Tue, 11 Feb 2025 17:19:10 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3HWLD8tu; spf=pass (imf13.hostedemail.com: domain of qperret@google.com designates 209.85.208.41 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=1739294351; 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=TbDB2T78gRRSnhZlNQEvX26YaZx1qd9LDVzTCLA7eDo=; b=mMbHi76mTpB682DrsdIDW3T1i8Rsv06ILds4kaWfXZw7YtPVfUhXMIRAJoqrntduiOLW8A P8TmGSdW3AfOqYy33vQfDebudGBTZQ68/ayxesFznafD8z5nAAAx11n/F7R7m4G+9y7b9A dk8W4C7kIQjCrVJz2qvUYqI62dqq//Q= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3HWLD8tu; spf=pass (imf13.hostedemail.com: domain of qperret@google.com designates 209.85.208.41 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=1739294351; a=rsa-sha256; cv=none; b=X3w9KkRyV2w+l99nGQ+I1yNCtjcLQndmmeeExOfboU760oGcerbWJFBWiyUer7wBovLo5J dCkRg39KKpWDNsWDhGdsAlrGBuD752AoPUxDfrKi4J2EDL3bRLu1Xkd2UiPqtJuYQHClVe AMJ8uibV45vozh2ckmDlQx5dSKpKSAw= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5de6ff9643fso5150068a12.3 for ; Tue, 11 Feb 2025 09:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739294349; x=1739899149; 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=TbDB2T78gRRSnhZlNQEvX26YaZx1qd9LDVzTCLA7eDo=; b=3HWLD8tuZZXXjIfehIVrN1ORO0VuRWD+nwZT0sEzH9VDeGDdsctZ6HRLHfR2THAw+j 9pJp4GxtN/jh9sqpVs28Jp0kaR0oh9lQfLayr9EpdXF4DeASNPpiQshXduJnq+N5h3yL GWtvxfTe7wCbGa7Sib7HS8+wlxk9dBLS7nRk7EwaciQK9X5MW5B2iHSuws+QHLkt61qU YRdC6SzO12wR/IfjAYAs8WQDU/af6QILmJ8Cn6eTBr3dFLr16R6j7I4lnZexQSYTJ/mM femCTPLJHL1HriqV97FUdPaylY7uRjoWOd4K/rjFlQaY/aJpM6SQP6SOqgqvuszGFHWD oiSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739294349; x=1739899149; 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=TbDB2T78gRRSnhZlNQEvX26YaZx1qd9LDVzTCLA7eDo=; b=MHse3SyiAD0+YzDsls2h97JDhYHPswKQ3JL37MTRl6V0J4k7AvyYELrO61OZnGF+9s l17ipuhNac889ovIbWdXBIqAZ5mKr2bCzPrv6+/MdSBZF+d6BH2ZwL/vt2bo4Q8g9kta He/PbaZR70/qMKHw8QUROW845Qcae+w7uAl3zC1aiCD+PflDdBvHXrrBa7DjR+/NQGMI dbwjT0Y63WUVDeT4rLoXKlQnzi3ujWrkGT4eoCnaA/8edHzWMeCODbAXxCjtkobQ4y3R MJrasjab2csl4DT0wu7x19VMoPsrMjEO0+hZgp7qHdQSnQsSGWKUixKiubmeGr4b9ZWj 0YBw== X-Forwarded-Encrypted: i=1; AJvYcCUP7tLiYuxEG3Cqr0Fxsm0wxnXzrxY/A+7xi3gYrEDmipcOhY9nSlsHpqKW7Qbsw/t8Dxde/R/z7w==@kvack.org X-Gm-Message-State: AOJu0Yxv1F8gqpUf27aSq3dladHwr+57ZnSqL1tpKapLYrd1OnvG8puO 8mWulXir+rdAtMi2i7/HaadjoM+Wec7dcyubR8PfoxlNxqe0+BeirGkd+2Y36Q== X-Gm-Gg: ASbGncuxS7Qlwd6HiXLMxuDtUCbaC28sBXWImvJgKLKINjOwdCfEfS2G7kQoDrUGVbx XriM8ne7WozpWiC5Ioztm49UaEG0Uh5fCWPkRF7rwEUfu+m8BF6M+fzMHtWo38hJu5BAWmnKFRj jmrZFtrmYyQMdbs5c8SCZk5T/7hSxmj4PKA1NL/n7tOgmCkWxbhOyNcOZe1fbznpV41Q60zxL1N d8G/KluH3/S+Mxoi3Cxf3zwnJFwgTIN7d4GBA/U5oQt6mJ80Ru1E7zuJ/SrcIPQ5NZ0lmMpg9UB mf1I2AofZdbCW9g4rEJi8k44IOJ3UepIn9TZz+2DEvNY0kuYuNlz X-Google-Smtp-Source: AGHT+IETwHheJ1VO/jmGJCeiPpzkB30iOpJM0PGYNAYejh8MHif7Zl42B4EJpywng8Lk3dfH/tNK3g== X-Received: by 2002:a05:6402:40d1:b0:5dc:7fbe:72ff with SMTP id 4fb4d7f45d1cf-5deadd7b87fmr10452a12.2.1739294348970; Tue, 11 Feb 2025 09:19:08 -0800 (PST) Received: from google.com (229.112.91.34.bc.googleusercontent.com. [34.91.112.229]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5de525f35b7sm7671829a12.53.2025.02.11.09.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2025 09:19:08 -0800 (PST) Date: Tue, 11 Feb 2025 17:19:05 +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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E8C722000B X-Stat-Signature: fzoy3sodin4ao16i9z7phumxr5nxdd7w X-HE-Tag: 1739294350-609952 X-HE-Meta: U2FsdGVkX18ScD9u2k1X9sBXc/eXWVFwR8jA5VfI6HCynXSb2P+E1g+tH6aotbhVBWMFKmBJeBIc4TWIc6C9IIgXYno+3D2SuSwG6/XfL5KW3xd52tVaGnrLO/JFsmlGUMyIHV5VeNsBfdjIQEsKSi4oVUzEJGbEFp8AfazWGj+y7JPsdhA49mQYWmjbo2U92kboUqczCt49RqbJxtAFA+8K9dtVj7SJhQHgdVtvtysWjEXoK/2clBaBcxkU/ZRmd3DsEr449q6x4Bw8hqUiH7FOj85knrO+0tBwZcCn7q5Xye5HAgJ8v4yKnkdZNBSgbCIQ1ER2ct5n24d2cUSMBfEd3n1+y2TCg6yRr9Kp3ce/1AAV2xgRZh4gZt2CST8FiCC7456OiII8Iao+G1u5XdnNktyIBp03oag0oz5Lk2gsInRITOia7f0wxJZmrTq6yym7ysUQEt5ljBkCAHinswqSjoO+SkLVlBXals0IG+H0dXiDRwqFnhgb8iTRYLzLLIG5FbMS0JtmKHIIxwv/3xK/ayuD0CMStSReyRzKnp/k9a1UZJhqcJWi8WHjj+DZKsU6bbjb8A1fZWjmGL36K2PaapyfdACc2vw2tuF3JE9oVTcpIGF7Ln5bsAJJZA2pobmuEGSt9gCO54NJOfnzKSvgrXrVZZX/15G6JFyQ7GKMbGOCAmyoxRStkab3XOrSGc8k8TWMf0sJ7UKyD9pdtrGRtqEq2vAhAxNjrTz+xG7DQky4F/MW2owHSLgKVwtgGTCf/A5Z0ARekYGjpi2v1N8JsWnjFoabtG0G5d+zIg90l/BM++tH73r8CYL2okcvNCfa8mO4XP3tAa3QyD+7rYkBuNUkvYltkKkInRd8A9SWS0g9OXUOoj6NVnTQW47IQ3PbsQuAHi5ADh618tTRdqama+XH3gTUz1BNNSm1a8pTVpuH6CxW/tFSmk+ObgQYjvc4cCXZ+zXaQprbMCZ YtEO2Ust SoqgpyPF5ghwP/NWHuZhInCkshPwgHQBovRv7Owi3TyAtOys9JJN5LoFuF64d8ApinAGOM8/a/2hl2jLh60cJJuIIDPOIqQdx0I/zvSKa7AIxrZy8vNb9yp3+P67YiIR2Q2pjT32OPKuRgqqYwB/+NaV0XRT9RQjs8GY8m/5Rk5MG1hKopXYg7nBOO0XkOmQ3ootw9/Jbp19ma2tLoRfbrSgz1cfO/m85o0dg2GaiVHRpQIEwKA5T6++op7EIHbCpgrRnz1/j2n/Y9rEj1WH6/2+PkwmoC5GV0t6tIiYOFwrOs+HQA2VxYf42prfEPoecjlZmEBRppKFqEHALApsSb/DhNqu+tDh5CgC37XxdmMNP+hXU8c0uXW41z1YQUcycKCerfIq7c0Ey4eGz32wbkcgpvuCXHg0PxowdMe1qbW2akdFatc1oapk5STnMFqmicpMpY3phTbEzYrZYtF6tJmodry1GeCFAUzvxDJaFZPJl4Ds= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 17:04:05 (+0000), Fuad Tabba wrote: > Hi Quentin, > > On Tue, 11 Feb 2025 at 16:57, Quentin Perret wrote: > > > > 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? > > VMs that have sharing in place don't need > KVM_GENERIC_MEMORY_ATTRIBUTES, since that presents the userspace > view/desire of the state of the folio. It's not necessarily an arm64 > thing, for example, CCA would need it, since it behaves like TDX. > > I guess that KVM_GMEM_SHARED_MEM and KVM_GENERIC_MEMORY_ATTRIBUTES are > mutually exclusive. I cannot think how the two could be used or useful > together. We could have a check to ensure that both are not enabled at > the same time. Right, that should be a matter of adding depend on !KVM_GENERIC_MEMORY_ATTRIBUTES to the KVM_GMEM_SHARED_MEM Kconfig I think then. > The behavior in this patch series is that > KVM_GMEM_SHARED_MEM selects GENERIC_PRIVATE_MEM. You meant s/GENERIC_PRIVATE_MEM/KVM_PRIVATE_MEM right? > Also, to help reduce the confusion above, I could rename the variable > is_private in user_mem_abort() to is_guestmem. WDYT? I actually don't mind the variable name in that it is consistent with the rest of the code, but I do positively hate how the definition of 'private' in this code doesn't match my intuition :-)