Received-SPF: pass (google.com: domain of linux-kernel+bounces-42999-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <2068cfca-b99b-4cf0-addc-43376c2681cb@suse.cz>
Date: Mon, 29 Jan 2024 16:26:01 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/25] x86/sev: Adjust directmap to avoid inadvertant
 RMP faults
Content-Language: en-US
To: Borislav Petkov <bp@alien8.de>, Michael Roth <michael.roth@amd.com>
Cc: x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-mm@kvack.org, linux-crypto@vger.kernel.org,
 linux-kernel@vger.kernel.org, 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, tobin@ibm.com,
 kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com,
 sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com,
 jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com,
 pankaj.gupta@amd.com, liam.merwick@oracle.com
References: <20240126041126.1927228-1-michael.roth@amd.com>
 <20240126041126.1927228-12-michael.roth@amd.com>
 <20240126153451.GDZbPRG3KxaQik-0aY@fat_crate.local>
 <20240126170415.f7r4nvsrzgpzcrzv@amd.com>
 <20240126184340.GEZbP9XA13X91-eybA@fat_crate.local>
 <20240126235420.mu644waj2eyoxqx6@amd.com>
 <20240127114207.GBZbTsDyC3hFq8pQ3D@fat_crate.local>
 <20240127154506.v3wdio25zs6i2lc3@amd.com>
 <20240127160249.GDZbUpKW_cqRzdYn7Z@fat_crate.local>
 <20240129115928.GBZbeTIJUYivEMSonh@fat_crate.local>
From: Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <20240129115928.GBZbeTIJUYivEMSonh@fat_crate.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 1/29/24 12:59, Borislav Petkov wrote:
> On Sat, Jan 27, 2024 at 05:02:49PM +0100, Borislav Petkov wrote:
>> This function takes any PFN it gets passed in as it is. I don't care
>> who its users are now or in the future and whether they pay attention
>> what they pass into - it needs to be properly defined.
> 
> Ok, we solved it offlist, here's the final version I have. It has
> a comment explaining what I was asking.
> 
> ---
> From: Michael Roth <michael.roth@amd.com>
> Date: Thu, 25 Jan 2024 22:11:11 -0600
> Subject: [PATCH] x86/sev: Adjust the directmap to avoid inadvertent RMP faults
> 
> If the kernel uses a 2MB or larger directmap mapping to write to an
> address, and that mapping contains any 4KB pages that are set to private
> in the RMP table, an RMP #PF will trigger and cause a host crash.
> 
> SNP-aware code that owns the private PFNs will never attempt such
> a write, but other kernel tasks writing to other PFNs in the range may
> trigger these checks inadvertently due to writing to those other PFNs
> via a large directmap mapping that happens to also map a private PFN.
> 
> Prevent this by splitting any 2MB+ mappings that might end up containing
> a mix of private/shared PFNs as a result of a subsequent RMPUPDATE for
> the PFN/rmp_level passed in.
> 
> Another way to handle this would be to limit the directmap to 4K
> mappings in the case of hosts that support SNP, but there is potential
> risk for performance regressions of certain host workloads.
> 
> Handling it as-needed results in the directmap being slowly split over
> time, which lessens the risk of a performance regression since the more
> the directmap gets split as a result of running SNP guests, the more
> likely the host is being used primarily to run SNP guests, where
> a mostly-split directmap is actually beneficial since there is less
> chance of TLB flushing and cpa_lock contention being needed to perform
> these splits.
> 
> Cases where a host knows in advance it wants to primarily run SNP guests
> and wishes to pre-split the directmap can be handled by adding
> a tuneable in the future, but preliminary testing has shown this to not
> provide a signficant benefit in the common case of guests that are
> backed primarily by 2MB THPs, so it does not seem to be warranted
> currently and can be added later if a need arises in the future.
> 
> Signed-off-by: Michael Roth <michael.roth@amd.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Link: https://lore.kernel.org/r/20240126041126.1927228-12-michael.roth@amd.com

Acked-by: Vlastimil Babka <vbabka@suse.cz>

Thanks!