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 B12BAC38A2D for ; Tue, 25 Oct 2022 08:39:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F6A28E0002; Tue, 25 Oct 2022 04:39:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A7758E0001; Tue, 25 Oct 2022 04:39:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFE1B8E0002; Tue, 25 Oct 2022 04:39:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E18B78E0001 for ; Tue, 25 Oct 2022 04:39:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A5640A0C52 for ; Tue, 25 Oct 2022 08:39:37 +0000 (UTC) X-FDA: 80058823194.22.E3AC133 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf04.hostedemail.com (Postfix) with ESMTP id C8E9440022 for ; Tue, 25 Oct 2022 08:39:36 +0000 (UTC) Received: from zn.tnic (p200300ea9733e753329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e753:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 457331EC064C; Tue, 25 Oct 2022 10:31:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1666686660; h=from:from: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:in-reply-to:in-reply-to: references:references; bh=SsCnaY6vsw/dlWcb5dAlVwUs2sKUOOm4xMSiV3vNbVc=; b=erN1LR4tBXE7W+2GQ21IylqAaTg3ibHJFZBzxlPhJR2N+B40rgmHY8IbEnrxZgvdUnmZ7l 2UrDoeUh/cI1b94V/yzn43xMsPQmRb0CJ3ZlOSF+QMqruxwiiwQZQ1KUHCYTUNrZjImCG+ Mjw1VpelZAdMyy4Xjpx0d5aG9UwNN0c= Date: Tue, 25 Oct 2022 10:30:56 +0200 From: Borislav Petkov 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, 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, 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 Subject: Re: [PATCH Part2 v6 12/49] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Message-ID: References: <87a0481526e66ddd5f6192cbb43a50708aee2883.1655761627.git.ashish.kalra@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=erN1LR4t; spf=pass (imf04.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666687177; a=rsa-sha256; cv=none; b=6Sx4H74wAiqQF1ao77/9bRF9Lu3uA7/8Lo0hYSDhkafyNbxQAogUwVcTPbrKApHzY9+SBX W3dWXtqiLqV/tjWfgOkpdVNhXAyYSMWg0Y+tmre4p70KFPAPg8DHjtHe62dS50LhYi0uDD 5eE9H7j1NKhB1BhGS7FLuyNnC5qZi4Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666687177; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SsCnaY6vsw/dlWcb5dAlVwUs2sKUOOm4xMSiV3vNbVc=; b=pU7clzCpJMBd5XiDY/2vJbrKs/om/XKnuv7RV5S5tTYU/Q4OJfYUd4kLxaWZJhrcvzSCMX LMGxITv9x91DZqwSDUEj8ik8rJEQYcRXKKNvO9eoLoOVZhbFX2Q/WbsenEvY5v/5liQhc6 WBg+tnVB9yUsP1HZnSTaDuzCSrK8B8Y= X-Rspamd-Queue-Id: C8E9440022 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=erN1LR4t; spf=pass (imf04.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: njj6tf8ioxcq7qy3yzt9nnatfg66a9nn X-HE-Tag: 1666687176-970272 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 Fri, Oct 14, 2022 at 04:09:11PM -0500, Kalra, Ashish wrote: > Yes, we need to do: > > wbinvd_on_all_cpus(); > SNP_DF_FLUSH > > Need to ensure all the caches are clear before launching the first guest and > this has to be a combination of WBINVD and SNP_DF_FLUSH command. Ok. > > Why isn't this retval checked? > > From the SNP FW ABI specs, for the SNP_SHUTDOWN command: > > Firmware checks for every encryption capable ASID that the ASID is not in > use by a guest and a DF_FLUSH is not required. If a DF_FLUSH is required, > the firmware returns DFFLUSH_REQUIRED. > > Considering that SNP_SHUTDOWN command will check if DF_FLUSH was > required and if so, and not invoked before that command, returns > an error indicating that DFFLUSH is required. > > This way, we can cleverly avoid taking the error code path for > DF_FLUSH command here and instead let the SNP_SHUTDOWN command > failure below indicate if DF_FLUSH command failed. > > This also ensures that we always invoke SNP_SHUTDOWN command, > irrespective of SNP_DF_FLUSH command failure as SNP_DF_FLUSH may > actually not be required by the SHUTDOWN command. This all sounds just silly. The proper way to do this is: retry: ret = __sev_do_cmd_locked(SEV_CMD_SNP_SHUTDOWN, NULL, error); if (ret == DFFLUSH_REQUIRED) { ret = __sev_do_cmd_locked(SEV_CMD_SNP_DF_FLUSH, NULL, NULL); if (ret) "... DF_FLUSH failed..."; goto retry; } I'm assuming here the firmware is smart enough to not keep returning DFFLUSH_REQUIRED constantly and cause an endless loop. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette