Date: Mon, 29 Jan 2024 16:26:01 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Borislav Petkov <bp@...en8.de>, Michael Roth <michael.roth@....com>
Cc: x86@...nel.org, kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
 linux-mm@...ck.org, linux-crypto@...r.kernel.org,
 linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
 jroedel@...e.de, thomas.lendacky@....com, hpa@...or.com, ardb@...nel.org,
 pbonzini@...hat.com, seanjc@...gle.com, vkuznets@...hat.com,
 jmattson@...gle.com, luto@...nel.org, dave.hansen@...ux.intel.com,
 slp@...hat.com, pgonda@...gle.com, peterz@...radead.org,
 srinivas.pandruvada@...ux.intel.com, rientjes@...gle.com, tobin@....com,
 kirill@...temov.name, ak@...ux.intel.com, tony.luck@...el.com,
 sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
 jarkko@...nel.org, ashish.kalra@....com, nikunj.dadhania@....com,
 pankaj.gupta@....com, liam.merwick@...cle.com
Subject: Re: [PATCH v2 11/25] x86/sev: Adjust directmap to avoid inadvertant
 RMP faults

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@....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@....com>
> Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
> Link: https://lore.kernel.org/r/20240126041126.1927228-12-michael.roth@amd.com

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

Thanks!

Powered by blists - more mailing lists