From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [PATCH 40/70] x86/sev-es: Setup per-cpu GHCBs for the runtime handler Date: Tue, 14 Apr 2020 15:18:36 -0500 Message-ID: References: <20200319091407.1481-1-joro@8bytes.org> <20200319091407.1481-41-joro@8bytes.org> <09757a84-1d81-74d5-c425-cff241f02ab9@amd.com> <27da7cf5-5ff4-a10c-a506-de77aeff8dd6@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <27da7cf5-5ff4-a10c-a506-de77aeff8dd6@amd.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org To: Dave Hansen , Mike Stunes , Joerg Roedel Cc: "x86@kernel.org" , "hpa@zytor.com" , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Hellstrom , Jiri Slaby , Dan Williams , Juergen Gross , Kees Cook , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , Joerg Roedel List-Id: virtualization@lists.linuxfoundation.org On 4/14/20 3:16 PM, Tom Lendacky wrote: > > > On 4/14/20 3:12 PM, Dave Hansen wrote: >> On 4/14/20 1:04 PM, Tom Lendacky wrote: >>>> set_memory_decrypted needs to check the return value. I see it >>>> consistently return ENOMEM. I've traced that back to split_large_page >>>> in arch/x86/mm/pat/set_memory.c. >>> >>> At that point the guest won't be able to communicate with the >>> hypervisor, too. Maybe we should BUG() here to terminate further >>> processing? >> >> Escalating an -ENOMEM into a crashed kernel seems a bit extreme. >> Granted, the guest may be in an unrecoverable state, but the host >> doesn't need to be too. >> > > The host wouldn't be. This only happens in a guest, so it would be just > causing the guest kernel to panic early in the boot. And I should add that it would only impact an SEV-ES guest. Thanks, Tom > > Thanks, > Tom >