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 0E2F9ECAAD3 for ; Tue, 6 Sep 2022 02:30:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BFC480246; Mon, 5 Sep 2022 22:30:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5479180224; Mon, 5 Sep 2022 22:30:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C10D80246; Mon, 5 Sep 2022 22:30:25 -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 27C9A80224 for ; Mon, 5 Sep 2022 22:30:25 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EF69C1A0499 for ; Tue, 6 Sep 2022 02:30:24 +0000 (UTC) X-FDA: 79880081568.12.BF9F4D6 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf12.hostedemail.com (Postfix) with ESMTP id 3F0EA40087 for ; Tue, 6 Sep 2022 02:30:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662431424; x=1693967424; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=G15JBOOK8EI0eKdSgCyHHPZ83FHdpeAzR9JiZNu8Z80=; b=PZ2XM96RPPBTPDu3svuKe0C6b1/b+mF2C5LRsqD3Op1TKJfgoW/reflc G5YKxPUxnrRPgSr7y9w7JPAfgzCCgTEEBgWOfIW5egAZ7dOfE5XoeWvu8 9oMpSlTl2Lh6WE+LaUIJJu5NsdPXT+eZqMK9/EV/J0DxMKiRhXeqTrL7+ jsX9CwTjKJzxEeydNnvuGAk7TZI2CkOnxB3jQmFXE8cgy1TWyo2/F+PBF 1D8XycV28bHZlR/ZJVgQdaQS9kOIG2bTuyNV7cSp3LZ0ANGpFDai3s/Tr JAjhBRNaNuanL48FtnirzH0Ing2zL4hH4ziYZ8BeLZec4fPiRnUaRS8gm A==; X-IronPort-AV: E=McAfee;i="6500,9779,10461"; a="360435931" X-IronPort-AV: E=Sophos;i="5.93,292,1654585200"; d="scan'208";a="360435931" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2022 19:30:22 -0700 X-IronPort-AV: E=Sophos;i="5.93,292,1654585200"; d="scan'208";a="643983689" Received: from chenchar-mobl1.amr.corp.intel.com (HELO [10.212.193.190]) ([10.212.193.190]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2022 19:30:22 -0700 Message-ID: <0ce441af-c825-3061-ad92-c360c339e924@intel.com> Date: Mon, 5 Sep 2022 19:30:21 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address Content-Language: en-US To: Ashish Kalra , 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 Cc: tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, 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, michael.roth@amd.com, 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, jarkko@kernel.org References: <0ecb0a4781be933fcadeb56a85070818ef3566e7.1655761627.git.ashish.kalra@amd.com> From: Dave Hansen In-Reply-To: <0ecb0a4781be933fcadeb56a85070818ef3566e7.1655761627.git.ashish.kalra@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662431424; 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=/mEtO4HPNKN4j/pgEacyBvt5bmM6ptd1d8BKIRCV7mk=; b=hZdTursooC9BlQ0MQz+yMYgKGJeKVuSlMhKYo1J2adowoXTCvWrybfzSB73Lfzes02rfUT 2A0DRUgLuvQfc1W/GgCcXW/NjEiUzPDQg2qwIaTMZfv5hci+Y9+v88CWciaODY/tRu0/EZ fNjf2D3Mn7e3/IcGOWvJSTwhS58JEvs= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=PZ2XM96R; spf=softfail (imf12.hostedemail.com: 134.134.136.100 is neither permitted nor denied by domain of dave.hansen@intel.com) smtp.mailfrom=dave.hansen@intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662431424; a=rsa-sha256; cv=none; b=cV2myMC7ivjxYoPDLdvuIzTdLpMHo7FRGshgMfAF9AO8DfhLeOhrpPOowkdd0EgXJaDiFB 33mE1XaG8UEe45V++64GnVUe2ANbgGXanlCs8hqgJ10BzTyy2wBvLdZeLQpItm+d19+o5q pdxa1gbkp1O00HJTBedDI7uDQ6nyFro= X-Rspam-User: X-Stat-Signature: tdsqoauy8bzbym4kids3zujhw4z1r14x X-Rspamd-Queue-Id: 3F0EA40087 Authentication-Results: imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=PZ2XM96R; spf=softfail (imf12.hostedemail.com: 134.134.136.100 is neither permitted nor denied by domain of dave.hansen@intel.com) smtp.mailfrom=dave.hansen@intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam04 X-HE-Tag: 1662431424-160504 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 6/20/22 16:03, Ashish Kalra wrote: > > When SEV-SNP is enabled globally, a write from the host goes through the > RMP check. When the host writes to pages, hardware checks the following > conditions at the end of page walk: > > 1. Assigned bit in the RMP table is zero (i.e page is shared). > 2. If the page table entry that gives the sPA indicates that the target > page size is a large page, then all RMP entries for the 4KB > constituting pages of the target must have the assigned bit 0. > 3. Immutable bit in the RMP table is not zero. > > The hardware will raise page fault if one of the above conditions is not > met. Try resolving the fault instead of taking fault again and again. If > the host attempts to write to the guest private memory then send the > SIGBUS signal to kill the process. If the page level between the host and > RMP entry does not match, then split the address to keep the RMP and host > page levels in sync. When you're working on this changelog for Borislav, I'd like to make one other suggestion: Please write it more logically and _less_ about what the hardware is doing. We don't need about the internal details of what hardware is doing in the changelog. Mentioning whether an RMP bit is 0 or 1 is kinda silly unless it matters to the code. For instance, what does the immutable bit have to do with all of this? There's no specific handling for it. There are really only faults that you can handle and faults that you can't. There's also some major missing context here about how it guarantees that pages that can't be handled *CAN* be split. I think it has to do with disallowing hugetlbfs which implies that the only pages that might need splitting are THP's.+ /* > + * If its an RMP violation, try resolving it. > + */ > + if (error_code & X86_PF_RMP) { > + if (handle_user_rmp_page_fault(regs, error_code, address)) > + return; > + > + /* Ask to split the page */ > + flags |= FAULT_FLAG_PAGE_SPLIT; > + } This also needs some chatter about why any failure to handle the fault automatically means splitting a page.