From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6349321DFA917 for ; Mon, 27 Mar 2017 03:07:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C51B11555E; Mon, 27 Mar 2017 10:07:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C51B11555E Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C51B11555E Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-77.phx2.redhat.com [10.3.116.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id E47B65C884; Mon, 27 Mar 2017 10:07:49 +0000 (UTC) To: Brijesh Singh , michael.d.kinney@intel.com, jordan.l.justen@intel.com, edk2-devel@ml01.01.org, liming.gao@intel.com References: <149013076154.27235.10725020825643505862.stgit@brijesh-build-machine> <149013078709.27235.16179070664669554073.stgit@brijesh-build-machine> Cc: brijesh.singh@amd.com, leo.duran@amd.com, Thomas.Lendacky@amd.com From: Laszlo Ersek Message-ID: <6f2a60a0-2480-457a-ca30-bc260b20f13f@redhat.com> Date: Mon, 27 Mar 2017 12:07:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 27 Mar 2017 10:07:52 +0000 (UTC) Subject: Re: [RFC PATCH v2 04/10] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 10:07:52 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/27/17 11:19, Laszlo Ersek wrote: > On 03/21/17 22:13, Brijesh Singh wrote: >> + Returns a boolean to indicate whether SEV is enabled >> + >> + @retval TRUE When SEV is active >> + @retval FALSE When SEV is not enabled >> + **/ >> +BOOLEAN >> +EFIAPI >> +MemEncryptSevIsEnabled ( >> + VOID >> + ); > > Would it make sense to call this library function in PlatformPei, rather > than add a separate SevIsEnabled() function to it (in patch #3)? The > implementations look nearly identical. I realize that earlier I seemingly suggested the opposite: http://mid.mail-archive.com/dd9436dc-415c-9fab-081c-39dd2cd71fd5@redhat.com http://mid.mail-archive.com/9193d837-6a78-b1c4-42c0-427fbc1f2364@redhat.com However, at that time, my understanding was that this library would only be used in PlatformPei (hence the single user wouldn't justify the new library instance). Now it seems that there are going to be several client modules that check on SEV enablement. Is that right? Thanks Laszlo