Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1022084rwb; Sat, 1 Oct 2022 13:21:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6agBBsyVYzONckVsWSJ3mx8dMeh3V28BtWAVcEWJ3vc3UZC1X7k7Hu+BcB2NDws7K2MnmI X-Received: by 2002:a17:907:16a5:b0:782:8fd0:88f6 with SMTP id hc37-20020a17090716a500b007828fd088f6mr10576539ejc.476.1664655660039; Sat, 01 Oct 2022 13:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664655660; cv=none; d=google.com; s=arc-20160816; b=MaHjI2+po6rEWOQPgOBq8QB6A0PuxRaUW5inYGmIfn1gY1sVEEfn1c/rAZVM5Jx2ln aCdRm/7TwYkW3w6NKJxOwIZs59XJpanIUVS9wmMArDCSKtc5fXLBRocp3KsnjSCpaaF0 UZAMpTKJOAGki4hotn7qc9hL1yusYj20AD3hnZVFFPWepP4oC9L0kYJtVXZk2PjvYuxH 6f/2OCe1u6tHdD3DaRY4iH16lpXEMYuDpO7rjYWm50CXAIIDYlD+EKHK18TYoGXqJktX mgf8Emtmgaak/Tw/ebzzVbl0xhOwrpm+me5ENspN0rTyT1bxqQzrtdELfIJsOG1UyLiS tYNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tXCw4blOG+lgy0RC4YVDWEQazozj/sfZ7AxmRf2ywac=; b=NyeT7phL6k/MhXWQGGJp8bmEU8UlbKm10mhTXpQW8Ndby+BVWUIJR0vX4Jzeku/7Yg xphAYYR6x50BnLsXWGEj8ydVd9KGxdqHGsv/e6xk4SXZ9/jpm6qWlng2ByMvy3YbjSd5 3bLc1S6CM69e2yLmTpYg4iJ1FH2wGO/Aboz11ildZoo5+tSc33KtsLy1bH7xF2VspvYt g99G2fBoBP5oDB+hAfc8jNiCQwRZUOshXFIF2eM+nJx1bRDkHmlyix7SI244sT99O/pY BvMOFr2Wt1XKpWp4PCD1/h+heB1YHDT+xj91Aoaewb9/g21ihLsTnf2fkCX8VS88weo1 DU+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Ilt2Azug; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp14-20020a1709071b0e00b0073dd47c3873si4551760ejc.878.2022.10.01.13.20.20; Sat, 01 Oct 2022 13:21:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=Ilt2Azug; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229616AbiJAUR7 (ORCPT + 99 others); Sat, 1 Oct 2022 16:17:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbiJAUR5 (ORCPT ); Sat, 1 Oct 2022 16:17:57 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1C223911D; Sat, 1 Oct 2022 13:17:55 -0700 (PDT) Received: from zn.tnic (p200300ea9733e707329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e707: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 F09741EC04DA; Sat, 1 Oct 2022 22:17:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1664655469; 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=tXCw4blOG+lgy0RC4YVDWEQazozj/sfZ7AxmRf2ywac=; b=Ilt2Azug3dgD7p5q8FQ6FAcg3y4AxHmVpXskS1Rdymmr14GKLinVzTb6x0N0DPGVGZ+YWL I8HeuPZPKq/nHiLmefe8/8hZFuIN3Hj4skqvfwNEHH3msW+wK/mvst85sbei5JlEy6hWE8 IIkNRyj0e2hpKjLtle207nbefi4lk1o= Date: Sat, 1 Oct 2022 22:17:44 +0200 From: Borislav Petkov To: Ashish Kalra 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 13/49] crypto:ccp: Provide APIs to issue SEV-SNP commands Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jun 20, 2022 at 11:04:45PM +0000, Ashish Kalra wrote: > From: Brijesh Singh > > Provide the APIs for the hypervisor to manage an SEV-SNP guest. The > commands for SEV-SNP is defined in the SEV-SNP firmware specification. > > Signed-off-by: Brijesh Singh > --- > drivers/crypto/ccp/sev-dev.c | 24 ++++++++++++ > include/linux/psp-sev.h | 73 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 97 insertions(+) > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > index f1173221d0b9..35d76333e120 100644 > --- a/drivers/crypto/ccp/sev-dev.c > +++ b/drivers/crypto/ccp/sev-dev.c > @@ -1205,6 +1205,30 @@ int sev_guest_df_flush(int *error) > } > EXPORT_SYMBOL_GPL(sev_guest_df_flush); > > +int snp_guest_decommission(struct sev_data_snp_decommission *data, int *error) > +{ > + return sev_do_cmd(SEV_CMD_SNP_DECOMMISSION, data, error); > +} > +EXPORT_SYMBOL_GPL(snp_guest_decommission); > + > +int snp_guest_df_flush(int *error) > +{ > + return sev_do_cmd(SEV_CMD_SNP_DF_FLUSH, NULL, error); > +} > +EXPORT_SYMBOL_GPL(snp_guest_df_flush); > + > +int snp_guest_page_reclaim(struct sev_data_snp_page_reclaim *data, int *error) > +{ > + return sev_do_cmd(SEV_CMD_SNP_PAGE_RECLAIM, data, error); > +} > +EXPORT_SYMBOL_GPL(snp_guest_page_reclaim); > + > +int snp_guest_dbg_decrypt(struct sev_data_snp_dbg *data, int *error) > +{ > + return sev_do_cmd(SEV_CMD_SNP_DBG_DECRYPT, data, error); > +} > +EXPORT_SYMBOL_GPL(snp_guest_dbg_decrypt); So this mindless repetition is getting annoying. I see ~70 SEV commands. Adding ~70 functions which parrot all the same call to sev_do_cmd() is just insane. I think you should simply export sev_do_cmd() and call it instead. Yes, when it turns out that a command and the preparation to issue it before it starts repeating pretty often, you could do a helper. But adding those silly wrappers doesn't bring anything besides confusion and code bloat. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette