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 90FCDC43334 for ; Tue, 12 Jul 2022 14:54:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FB996B012D; Tue, 12 Jul 2022 10:54:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AB246B012E; Tue, 12 Jul 2022 10:54:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12535940063; Tue, 12 Jul 2022 10:54:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F155E6B012D for ; Tue, 12 Jul 2022 10:54:12 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C728931E9D for ; Tue, 12 Jul 2022 14:54:12 +0000 (UTC) X-FDA: 79678743144.22.91635B1 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id 20C0E160058 for ; Tue, 12 Jul 2022 14:54:11 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AD67DB819B0; Tue, 12 Jul 2022 14:54:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C65F4C341C0; Tue, 12 Jul 2022 14:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657637649; bh=VkRGH3NNN+HIyw30NEGUMWuNTYMnRNznF6Yoz8xWvHE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h60oAnU1aXZaRC7VpVhzHcRhXIV0KfZ9Zm2lzo6YT5TOw0wuZD1nO+KNGFKijNu34 lZMJhtnZZrJ70MJD808JKzGh4pRAxRdcL3a0ILc5SyRdisTaoaN366Hej78Ejbb9hU qQhKS8myxFGhQucR5emZKGxqwZouBqiCzh1hvojeRta93T3o+ZLOqYTTNwDbuWGHvN S3zKyxs52kUBo0yn5c18FEEkQbZthkLG59WuRvdr7PYWgFvCS36XTvHf6rkyjxirCj k0YNOyFS/olS3uOxmKphzfuDqxHtU9n41plGVYyb8bHq3C+1p8JS2e/sLZOKzUb4Ym xn26XlW9iX5Lw== Date: Tue, 12 Jul 2022 17:54:05 +0300 From: Jarkko Sakkinen To: "Kalra, Ashish" Cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-mm@kvack.org" , "linux-crypto@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "jroedel@suse.de" , "Lendacky, Thomas" , "hpa@zytor.com" , "ardb@kernel.org" , "pbonzini@redhat.com" , "seanjc@google.com" , "vkuznets@redhat.com" , "jmattson@google.com" , "luto@kernel.org" , "dave.hansen@linux.intel.com" , "slp@redhat.com" , "pgonda@google.com" , "peterz@infradead.org" , "srinivas.pandruvada@linux.intel.com" , "rientjes@google.com" , "dovmurik@linux.ibm.com" , "tobin@ibm.com" , "bp@alien8.de" , "Roth, Michael" , "vbabka@suse.cz" , "kirill@shutemov.name" , "ak@linux.intel.com" , "tony.luck@intel.com" , "marcorr@google.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "alpergun@google.com" , "dgilbert@redhat.com" Subject: Re: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address Message-ID: References: <0ecb0a4781be933fcadeb56a85070818ef3566e7.1655761627.git.ashish.kalra@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657637652; 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=UvIHOvehwZ+LUlek6c63Cs/tWYVVPW113KH383KcrzM=; b=d4woXLhIcH7teP4DKRj2HaVkCiyN9xYpU0h5181NKXVmZf7+o7c5bRsq60M5Z9MnHdElFE WklnEXsFp374tuNMtT6bn914O6YGeGFRnZ6QvBoW/Kip+vt1tSL1wNPzpyC6HSOZKQxV1L DTLb8u7v+vRcjDyf3GN1tslpczASXRk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657637652; a=rsa-sha256; cv=none; b=tS+273Ag/5QR4p11x31EpM4+IJbJGyTvkLQAcnrVlez1pX+Z8mjlkoeUT2vGbUe+AkFsaX FkqyHxzfUZkxS2m1DFzTMDqjv0RdXpcdX6IgeGXhCU0K+6JFlJO6vlYptOqTnzV/Fxsggv ufC8EUNzB6Dvjg8kkmm/ePnMhcdMbas= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h60oAnU1; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org X-Stat-Signature: ebenxgb6njrpb468qd3s3hyg8cyzmp8c X-Rspamd-Queue-Id: 20C0E160058 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h60oAnU1; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org X-Rspamd-Server: rspam05 X-HE-Tag: 1657637651-545437 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: On Tue, Jul 12, 2022 at 02:29:18PM +0000, Kalra, Ashish wrote: > [AMD Official Use Only - General] > > >> +static int handle_user_rmp_page_fault(struct pt_regs *regs, unsigned long error_code, > >> + unsigned long address) > >> +{ > >> + int rmp_level, level; > >> + pte_t *pte; > >> + u64 pfn; > >> + > >> + pte = lookup_address_in_mm(current->mm, address, &level); > > >As discussed in [1], the lookup should be done in kvm->mm, along the lines of host_pfn_mapping_level(). > > With lookup_address_in_mm() now removed in 5.19, this is now using > lookup_address_in_pgd() though still using non init-mm, and as mentioned > here in [1], it makes sense to not use lookup_address_in_pgd() as it does > not play nice with userspace mappings, e.g. doesn't disable IRQs to block > TLB shootdowns and doesn't use READ_ONCE() to ensure an upper level entry > isn't converted to a huge page between checking the PAGE_SIZE bit and > grabbing the address of the next level down. > > But is KVM going to provide its own variant of lookup_address_in_pgd() > that is safe for use with user addresses, i.e., a generic version of > lookup_address() on kvm->mm or we need to duplicate page table walking > code of host_pfn_mapping_level() ? It's probably cpen coded for the sole reason that there is only one call site, i.e. there has not been rational reason to have a helper function. Helpers are usually created only in-need basis, and since the need comes from this patch set, it should include a patch, which simply encapsulates it into a helper. > > Thanks, > Ashish BR, Jarkko