From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.5355.1634189419389083028 for ; Wed, 13 Oct 2021 22:30:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R7IK3KaJ; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634189418; 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: in-reply-to:in-reply-to:references:references; bh=xCWZ5FrfL95ZgTnJJzpOtDAgK8yYKWizOugyxnFIi34=; b=R7IK3KaJRhBi8jfaNeq+AChyJajVkp8NTou520it8MHzvTZRDahEdnZU8XMF8wNSImgc13 JLrLfSDNfRvtmBa2eRdyDZSuO4X2J1Jz7mpNiaLZHV/KMw3zqknMgn+D5upQS8CdlU4aON dYPuuF1M29KoABww515ouNVn6OPmEEY= 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-167-rhalS5zYPxe-U8VQ3nT6jw-1; Thu, 14 Oct 2021 01:30:15 -0400 X-MC-Unique: rhalS5zYPxe-U8VQ3nT6jw-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 65AC9801AA7; Thu, 14 Oct 2021 05:30:13 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD8445C232; Thu, 14 Oct 2021 05:30:12 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1E34F18007AC; Thu, 14 Oct 2021 07:30:11 +0200 (CEST) Date: Thu, 14 Oct 2021 07:30:11 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V2 05/28] MdePkg: Add TdxLib to wrap Tdx operations Message-ID: <20211014053011.sgzov5q3bym7x2pf@sirius.home.kraxel.org> References: <20211012082206.2j5eptadquhf3pmg@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > > +UINT8 *mExtendBufferAddress = NULL; > > > +TDX_EXTEND_BUFFER mExtendBuffer; > > > + > > > +/** > > > + TD.RTMR.EXTEND requires 64B-aligned guest physical address of > > > + 48B-extension data. In runtime we walk thru the Buffer to find > > > + out a 64B-aligned start address. > > > > Can't you just use __attribute__((aligned(64))) for that? > > > In the PoC of TDVF I had thought about it. But at last I gave up such solution. The reasons are: > 1) OVMF/TDVF supports both GCC and VS2019 tool chain. __attribute__((aligned(64))) is for GCC. Its counterpart of VS2019 Tool chain is __declspec(align(x)). > 2) There is the limitation of /ALIGN:32 in the build scripts which means aligned 64 exceeds the /ALIGN 32, unless /ALIGN is updated to 64. > That's why the current solution is used. MdePkg/Include/Base.h has a bunch of ALIGN_* macros to do the math for you, which should simplify this alot. I'd suggest to also drop the mExtendBufferAddress and the function calculating it. Just use the macro instead when needed. take care, Gerd