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 11345C4332F for ; Thu, 2 Nov 2023 02:20:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A72838D0073; Wed, 1 Nov 2023 22:20:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A21E98D0026; Wed, 1 Nov 2023 22:20:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89C0F8D0073; Wed, 1 Nov 2023 22:20:08 -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 789FB8D0026 for ; Wed, 1 Nov 2023 22:20:08 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 52D21A0339 for ; Thu, 2 Nov 2023 02:20:08 +0000 (UTC) X-FDA: 81411409296.18.92C2CD6 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf09.hostedemail.com (Postfix) with ESMTP id 97937140013 for ; Thu, 2 Nov 2023 02:20:05 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Nqo2aSH0; spf=pass (imf09.hostedemail.com: domain of xiaoyao.li@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698891606; 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=dY0Z7smCS1kHe9JjJaOLjaMy2MNGuF6q2LtbRpnMatk=; b=TFD4RWxZVYHUctAF7wXEjgIKquVIodLhepgcjtjA0V1yzTVXXwgJ5SgqBxsoVyUxT1WZrG +rG4jxu6uiLo82t0W8sjSH2oJFwn6sClctbkswMjdqkq6iU4KQWwtE9v0k2z2oJLAj/8ce etPb1eskCAMw7ivvCwPrq85QL8KYRXQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698891606; a=rsa-sha256; cv=none; b=mLDUZt2CUIsauhgtgIcYjJUtBhLghgh+4Ii09TvlBGqZ4zZIDnPU7HmDazonAem4jJem11 Laz2R/FlZWwh8oXB3MKO26DU15FUUOwBHHPeDV1kPGTB2t5awb7T33GT4NGMlKm+Ua5k3L zTkr5EkOw4Ztqlou2gj2qZSW/ic5u7o= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Nqo2aSH0; spf=pass (imf09.hostedemail.com: domain of xiaoyao.li@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698891605; x=1730427605; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=qMSrBq5gKSfvneC99jG0ycqZi9wUzkwKrG5m2lwT0dM=; b=Nqo2aSH0iDoJdyNp09dqVU6TkNwOjFaaVgXz9zzoOttMJuLXjg+NXHUK JA/d7dPAUW/+aWL5bE3FaAuvEdkMZXAS9LWMAD5hn2Nc5CghiQXxdQPuD 7X7md2nKlytLO4XzWTS1tNwmjRulfzC7TK6wfdMmVl/LPgH2CTs3JvFwX 92lDzom0DiGyn3qkGkRVRD1Xjh++7uOYnxw2mAp1hoFi7hhw2QcpykY47 2NPNf4gqV/Noa0khobnEhirD71XGTSccfmNM3pTrbB8K9k7HZ2aWVYoGJ O6waBm/qjLlXhv6dTfNWsmqpxAQq2kl7pP8vFJqzremFQ6pncOCqBmKqa Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="373665326" X-IronPort-AV: E=Sophos;i="6.03,270,1694761200"; d="scan'208";a="373665326" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 19:20:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="851761891" X-IronPort-AV: E=Sophos;i="6.03,270,1694761200"; d="scan'208";a="851761891" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.93.9.145]) ([10.93.9.145]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 19:19:53 -0700 Message-ID: <33686031-c1df-4ef5-a6ac-1aab7f5c656e@intel.com> Date: Thu, 2 Nov 2023 10:19:50 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace Content-Language: en-US To: Sean Christopherson , Kai Huang Cc: "viro@zeniv.linux.org.uk" , "aou@eecs.berkeley.edu" , "brauner@kernel.org" , "oliver.upton@linux.dev" , "chenhuacai@kernel.org" , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "maz@kernel.org" , "pbonzini@redhat.com" , "mpe@ellerman.id.au" , "willy@infradead.org" , "anup@brainfault.org" , "akpm@linux-foundation.org" , "kvm-riscv@lists.infradead.org" , "mic@digikod.net" , "liam.merwick@oracle.com" , "kvm@vger.kernel.org" , Isaku Yamahata , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "tabba@google.com" , "amoorthy@google.com" , "linuxppc-dev@lists.ozlabs.org" , "michael.roth@amd.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "chao.p.peng@linux.intel.com" , "linux-mips@vger.kernel.org" , Vishal Annapurve , "vbabka@suse.cz" , "mail@maciej.szmigiero.name" , "yu.c.zhang@linux.intel.com" , "qperret@google.com" , "dmatlack@google.com" , Yilun Xu , "isaku.yamahata@gmail.com" , "ackerleytng@google.com" , "jarkko@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Wei W Wang References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> From: Xiaoyao Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 97937140013 X-Rspam-User: X-Stat-Signature: qpbhpgbqc5c5an5tjby1kd5tozo1r1ot X-Rspamd-Server: rspam03 X-HE-Tag: 1698891605-383568 X-HE-Meta: U2FsdGVkX18sSPNnT233m0XYrEyiK7luTYPK3pZ0wz1fKXAmmARmuppLqXHBGOC10XgOETLddtIr3kK3DSiNeJM8Cbm+/fR3/675Wme0tkyQ68FTVE9CWoASy3JP7bMApv7ucEHeq3w68ZJlWbJawkTaQ7F0N4lcNDAUlDUm5L+I8U4wpdFoyZV/fsCA7OVw/Xg6u0StfraymAejVEmvZeVcDCBOU0bKb/iNRl/Z+br+QxKRqxMpgnvQpd68Y2+/Rwvh9s7lMD6Cw6LezTYBVAi3wehLVbe+EaCWX04GseTslwy0RuY8bWmou7/iIeoxzqk2E0Cp6JV8H0oSqrCHSb+BKCAGFhbVkdf1LuiMTSMuDYMUkgfh8sR5hYLOcwZ5mm4eXspJ5e/PN9bXwfSJWnHzrIJM4KD3tnHEDZwJfWG60Y+HhSj9CH1NYAyjb9W0/O8oI9oX/qhTvBVFvPSddy1ro2c9iIFHmgVdkcVfLfaJMZysD0FQgvzlWXJygfVvsF0sQzfF8S7fDlCoBvsfVxUsgDWjBoS80NnjNZ6CJAVHWL/aQmajyQIJWX2xuXwcGOm9MHKxn3guXuY5nYFzs9RKK/mt6XgE1r6GvYTRLLHnN2h7rPP7DRTl7cUGywPaVuoZwLHvcv8nVu41Rl7J1zo9ljYWpopx+SWDyIhw8wGJckRvZhPSU36pzCbjY1RS8EaOkBP+CZ7IsOVEJwTHl2PGXLmK+Wx4W0xHFpkkWwHhfhLd3nrxxbmIRHYNyPlGymfzzzXgvYyBeJAFBs5QFkraxB77X97P55TheQP/iCwZliuq+nr4wYwfVm3WpzQeayZj7krS0mIOZ5sc9sLg24le1yTiCbvRKH0CqaXzKgdz1NrIMFmuHjcL5UJtMl099Tj70FWrnTxlnIuTQCk9DSW+IvhYj0leLNBtUbTzo3MO70CVlGbxe7xgiMmvwRMqnRtHSXpe9kA40Bw5Lr5 RH/cHX8d UxMsY2EU9zKm2MYp+Hn0jaFilWRKPXN/uKu9aM8zg5u3QG2vegySjy/hvHFPwjt0RNPAuboMIyKxTRuc3L9EBprgk7ipC06GwFZM1QkD5F7kplNjhI+pSPVGN01ArxgJsDebkiG0cufss0vB3u1KSY42dQPcGdHxDcD10/LOGWXCtuY0c1XQP7KQzs1ovLhNOzTq0CnsLDGXOP5odwWqz+SkvW4IKpSeXEt6ajWNrUJ+ENjaoiwhFnbwM2utxfFuYBpjgKow5C/zKxBNNuhKDehhQGbmxMDkqryd/hhqxMhbWRMP20zcyggp052Ck5OE0anQmn35C+H0Pqc5nvCoMRo65BgDs8+Dwh2N1irCCoSCfGWU7b0ndS/wQqwZigR9TBeJA0QJcwbAiBKy2M5+9aEq2yNc5lfizaIT+tRPEjPKKK8Y= 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 11/2/2023 1:36 AM, Sean Christopherson wrote: >> KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to >> ? > I'd prefer to keep it in generic code, as it's highly likely to end up there > sooner than later. There's a known use case for ARM (exit to userspace on missing > userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. > > [*]https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com I wonder how this CAP is supposed to be checked in userspace, for guest memfd case? something like this? if (!kvm_check_extension(s, KVM_CAP_MEMORY_FAULT_INFO) && run->exit_reason == KVM_EXIT_MEMORY_FAULT) abort("unexpected KVM_EXIT_MEMORY_FAULT"); In my implementation of QEMU patches, I find it's unnecessary. When userspace gets an exit with KVM_EXIT_MEMORY_FAULT, it implies "KVM_CAP_MEMORY_FAULT_INFO". So I don't see how it is necessary in this series. Whether it's necessary or not for [*], I don't have the answer but we can leave the discussion to that patch series.