From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC8AF4414 for ; Tue, 12 Jul 2022 14:54:09 +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> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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