From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web11.43548.1606169793600297840 for ; Mon, 23 Nov 2020 14:16:34 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Gv+O38ME; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606169792; 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=oD4hKpAaYCFxJw0cx5R6+bIGAf7GVlXQOi2tFZJwo1Y=; b=Gv+O38MEuq5QSYSp8RSpfFOgRTqQaoO66K7azwJOiXr+I7bcGINjyYQN2A0n/4RAUt0HiD VRYbD1mCdnSg1vPHsVYPVa0tH3NTZG8yHzSc6n/0/AyXDsJvcGiCc3AgqcvsSJXfQ06ae7 X0did+KQhlXmYNv6DqPHch0ZXLYVSN8= 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-288-uOimzzGDMN-cIlNfQINkVw-1; Mon, 23 Nov 2020 17:16:26 -0500 X-MC-Unique: uOimzzGDMN-cIlNfQINkVw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0E46D1842177; Mon, 23 Nov 2020 22:16:25 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-230.ams2.redhat.com [10.36.112.230]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F0CD5D9CC; Mon, 23 Nov 2020 22:16:22 +0000 (UTC) Subject: Re: [PATCH v2 3/6] OvmfPkg: convert ES Reset Block structure to be guided To: James Bottomley , devel@edk2.groups.io Cc: dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@amd.com, brijesh.singh@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com, "Dr . David Alan Gilbert" References: <20201120184521.19437-1-jejb@linux.ibm.com> <20201120184521.19437-4-jejb@linux.ibm.com> From: "Laszlo Ersek" Message-ID: Date: Mon, 23 Nov 2020 23:16:21 +0100 MIME-Version: 1.0 In-Reply-To: <20201120184521.19437-4-jejb@linux.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 On 11/20/20 19:45, James Bottomley wrote: > Convert the current ES reset block structure to an extensible guid > based structure by appending a header and length, which allow for > multiple guid based data packets to be inserted. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 > Signed-off-by: James Bottomley > > --- > > v2: added > --- > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 49 +++++++++++++++----- > 1 file changed, 38 insertions(+), 11 deletions(-) (1) Please update the subject line to: OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDed - edk2 prefers including module names too in the patch subjects - "ES" is harder to understand than "SEV-ES" - "GUIDed" is harder to misread as "guided" - subject length is still OK (70 chars) > > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > index 980e0138e7fe..baf9d09f3625 100644 > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > @@ -25,21 +25,40 @@ ALIGN 16 > TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0 > %endif > > +; > +; Padding to ensure first guid starts at 0xffffffd0 > +; > +TIMES (32 - ((guidedStructureEnd - guidedStructureStart) % 32)) DB 0 (2) This will insert 32 zero bytes if the size is already aligned to 32 bytes (because 32-0 = 32). In other words, the above produces 1 to 32 zero bytes, dependent on table size. The variant I proposed in point (5) at https://edk2.groups.io/g/devel/message/67621 https://www.redhat.com/archives/edk2-devel-archive/2020-November/msg00781.html takes this into account, and only prepends 0 to 31 bytes (inclusive): TIMES (31 - (guidedStructureEnd - guidedStructureStart + 31) % 32) DB 0 - This variant subtracts 1 inside the remainder operation (which is expressed as adding 31). - For compensation, it adds 1 just outside of the remainder operation. This addition in effect increases the subtrahend for the leftmost 32. Therefore this (-1) addend is ultimately folded into the leftmost 32, yielding 31 on the leftmost side. TIMES (32 - ((guidedStructureEnd - guidedStructureStart - 1) % 32 + 1)) DB 0 ^^^ ^^^ | | | compensate | in the | remainder | slide down residue class modulo 32 TIMES (32 - ((guidedStructureEnd - guidedStructureStart + 31) % 32) - 1) DB 0 ^^^^ ^^^ | | | unnest | increment | from | subtrahend | express modular subtraction as addition, to avoid using % on a negative integer (in case size were 0) TIMES (31 - ((guidedStructureEnd - guidedStructureStart + 31) % 32)) DB 0 ^^ | fold previous (-1) addend into leftmost constant - This juggling of 1 results in no changes for residue classes 1 through 31, but wraps the outermost result (the padding size) for residue class 0, from 32 to 0. > + > +; Guided structure. To traverse this you should first verify the > +; presence of the table header guid (3) suggest "table footer GUID" (the GUID follows the data, in address order) > +; (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If that > +; is found, the two bytes at 0xffffffce are the entire table length. (4) can we make the whole table size field 32-bit? I don't have a particular use case in mind, it just looks more extensible than 16-bit. We can still keep the individual structs we have in mind 16-bit sized. > +; > +; The table is composed of structures with the form: > +; > +; Data (arbitrary bytes identified by guid) > +; length from start of guid to end of data (2 bytes) (5) This is hard to interpret, as "data" precedes "guid" in address space (guid is a footer, not a header). I suggest "length from start of data to end of GUID" > +; guid (16 bytes) > +; > +; so work back from the header using the length to traverse until you (6) suggest "from the footer" > +; either find the guid you're looking for or run off the end of the > +; table. (7) suggest "run off the beginning of the table" ... I realize "start" and "end" can be interpreted temporally and spatially. In a forward traversal they are the same, but now they aren't. I suggest we use the spatial (address space order) interpretation. > +; > +guidedStructureStart: > + > ; > ; SEV-ES Processor Reset support > ; > ; sevEsResetBlock: > ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be > -; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset > -; and GUID will be used to locate this block in the firmware and extract > -; the build time RIP value. The GUID must always be 48 bytes from the > -; end of the firmware. > +; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. The data > +; format is > ; > -; 0xffffffca (-0x36) - IP value > -; 0xffffffcc (-0x34) - CS segment base [31:16] > -; 0xffffffce (-0x32) - Size of the SEV-ES reset block > -; 0xffffffd0 (-0x30) - SEV-ES reset block GUID > -; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) > +; IP value [0:15] > +; CS segment base [31:16] > +; > +; SEV-ES reset block GUID: 00f771de-1a7e-4fcb-890e-68c77e2fb44e (8) Did I understand from the v1 discussion that the corresponding QEMU parser is not upstream yet? (Or at least not released?) (9) The 16-bit size field of the SEV-ES reset block structure is not documented. > ; > ; A hypervisor reads the CS segement base and IP value. The CS segment base > ; value represents the high order 16-bits of the CS segment base, so the > @@ -48,8 +67,6 @@ ALIGN 16 > ; program the EIP register with the IP value as read. > ; > > -TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > - > sevEsResetBlockStart: > DD SEV_ES_AP_RESET_IP > DW sevEsResetBlockEnd - sevEsResetBlockStart > @@ -57,6 +74,16 @@ sevEsResetBlockStart: > DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E > sevEsResetBlockEnd: > > +; > +; Table header: length of whole table followed by table header (10) I suggest "table footer" (twice) > +; guid: 96b582de-1fb2-45f7-baea-a366c55a082d > +; > + DW guidedStructureEnd - guidedStructureStart > + DB 0xDE, 0x82, 0xB5, 0x96, 0xB2, 0x1F, 0xF7, 0x45 > + DB 0xBA, 0xEA, 0xA3, 0x66, 0xC5, 0x5A, 0x08, 0x2D > + > +guidedStructureEnd: > + > ALIGN 16 > > applicationProcessorEntryPoint: > Thanks! Laszlo