From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.13595.1619797722362713861 for ; Fri, 30 Apr 2021 08:48:42 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dcwLI7a6; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619797721; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FOAUSI/cGIcWjz4980+YmXk1A5kxJ2F/QD7UTf7zn+8=; b=dcwLI7a6HH2UTPn5AHtwpOloH/xvI4z+xrmYjRHtZ7SKMPOshNLgRHjsFuc73X1LghzQtW DeWPmywIhMzC2LcB9nXTuE+wjGWZAlmVI0ayUNJi2CSvE7t1LrimWykhAQG7sY9LQY0AhF pLqQQH8JU+qaKROJYWfPdpA8B5FabVE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-526-w8vnO-E_O52cH0R29e7Bow-1; Fri, 30 Apr 2021 11:48:39 -0400 X-MC-Unique: w8vnO-E_O52cH0R29e7Bow-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 213CB1006C82; Fri, 30 Apr 2021 15:48:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-248.ams2.redhat.com [10.36.112.248]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1721D10016F8; Fri, 30 Apr 2021 15:48:31 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 4/4] OvmfPkg/Tcg2ConfigPei: Mark TPM MMIO range as unencrypted for SEV-ES To: Tom Lendacky , devel@edk2.groups.io Cc: Joerg Roedel , Borislav Petkov , Ard Biesheuvel , Jordan Justen , Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Min Xu , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Stefan Berger References: <00ff47c80f180b5b9054890de0ce5e1975fe2b1f.1619540470.git.thomas.lendacky@amd.com> <6807464e-823e-3a16-cf1c-24f612a43936@redhat.com> <096090a1-6fd4-6364-fc88-733a0b3ef422@amd.com> From: "Laszlo Ersek" Message-ID: <2232673b-69db-43ca-7c93-347b3d4fa62f@redhat.com> Date: Fri, 30 Apr 2021 17:48:31 +0200 MIME-Version: 1.0 In-Reply-To: <096090a1-6fd4-6364-fc88-733a0b3ef422@amd.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit I need to excuse myself for two items here, where your expectation was justified: On 04/28/21 21:43, Tom Lendacky wrote: > On 4/28/21 12:51 PM, Laszlo Ersek via groups.io wrote: >> I'm going to ask for v3 after all: >> >> On 04/27/21 18:21, Lendacky, Thomas wrote: >>> @@ -627,6 +627,7 @@ [Components] >>> >>> !if $(TPM_ENABLE) == TRUE >>> OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf >>> + OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecryptPei.inf >>> SecurityPkg/Tcg/TcgPei/TcgPei.inf >>> SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf { >>> >> >> (5) Functionally correct, but it reads more nicely (from a logical >> dependency POV) if we place the new PEIM first. >> >> (Please apply to the rest of the DSC files, and the FDF files too.) > > Ok, I was going with the alphabetical placement. I'll switch it up. Well, you are not wrong; what I request for ordering between lib classes and between FDF/DSC entries is indeed inconsistent. I guess for lib classes, showing the construction order makes little, as that is determined with respect to particular library instances, plus we wrangle lib classes all the time, and keeping consistency is simplest with alphabetical ordering. Dispatch order is *somewhat* more directly visible in a FDF file... but yes, keeping INF references in alphabetical order there too would certainly plausible >>> + DEBUG ((DEBUG_INFO, "%a: failed to map TPM MMIO address range unencrypted\n", __FUNCTION__)); >> >> (13) Overlong line. > > Ok, I'll change that. I though that was ok now since PatchCheck.py didn't > complain. Sorry about my pickiness; this is a point where I strongly disagree with the rest of the edk2 maintainers -- I really do insist on 80 chars per line, as my eyesight isn't the greatest, I totally depend on two code windows being shown side by side, and I *also* can't work with multiple monitors (I've tried it, I just can't). So... one monitor, mid-size fonts, two columns of text --> 80 chars per column. Thanks & sorry about the trouble, Laszlo