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.web11.1950.1632386907913565070 for ; Thu, 23 Sep 2021 01:48:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PK2c6jky; 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=1632386907; 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=hceY6RaAEYLi+J6aAA+6rMd2bFpI7AGZ3v/1NJVbK34=; b=PK2c6jkysQ5P1VkeY+4IYzOmaR0HFLO/pKnv9rS5a+zNh5SBKpLN5vXoXDIHyQD3/3Nt4C 1Nv/W9oq3rPg/djlUGZ6D9Lz4HjnBSDAXpcUaX9W/6fLqyB1WYTVGz2xg9DNaoFxD3auQp pI98shdFoqaKVoCUsuwXdqcR3f+35/w= 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-227--C-k3vbZOC6S9_yms9q6bQ-1; Thu, 23 Sep 2021 04:48:25 -0400 X-MC-Unique: -C-k3vbZOC6S9_yms9q6bQ-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 E7F1510247A7; Thu, 23 Sep 2021 08:48:23 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6CCE25D9DC; Thu, 23 Sep 2021 08:48:23 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id B8B83180038E; Thu, 23 Sep 2021 10:48:21 +0200 (CEST) Date: Thu, 23 Sep 2021 10:48:21 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector Message-ID: <20210923084821.yxizus3loa2p6hms@sirius.home.kraxel.org> References: <12721dade1f2f9905cc34271d9abec24650442ff.1632214561.git.min.m.xu@intel.com> <20210922074929.e5iwf24t6wyndgbu@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 On Thu, Sep 23, 2021 at 12:38:24AM +0000, Xu, Min M wrote: > On September 22, 2021 3:49 PM, Gerd Hoffmann wrote: > > Hi, > > > > > +%ifdef ARCH_X64 > > > +; > > > +; TDX Metadata offset block > > > +; > > > +; TdxMetadata.asm is included in ARCH_X64 because Inte TDX is only ; > > > +available in ARCH_X64. Below block describes the offset of ; > > > +TdxMetadata block in Ovmf image ; ; GUID : > > > +e47a6535-984a-4798-865e-4685a7bf8ec2 > > > +; > > > +tdxMetadataOffsetStart: > > > + DD tdxMetadataOffsetStart - TdxMetadataGuid - 16 > > > + DW tdxMetadataOffsetEnd - tdxMetadataOffsetStart > > > + DB 0x35, 0x65, 0x7a, 0xe4, 0x4a, 0x98, 0x98, 0x47 > > > + DB 0x86, 0x5e, 0x46, 0x85, 0xa7, 0xbf, 0x8e, 0xc2 > > > +tdxMetadataOffsetEnd: > > > + > > > +%endif > > > > This should be switched to common ovmf metadata (see patches 4-7 of the > > SEV-SNP series). > > > > Min: please have a look at these patches. > > > Hi, Gerd > I checked the patches 4-7 of the SEV-SNP series. The common > OvmfMetadata is designed for both SEV and TDX, right? That is the idea, yes. > If so, then it means the SEV and TDX metadata will be mixed in this > OvmfMetadata. Yes. > I am thinking there will always be different fields for > SEV and TDX. For example, SEV has PcdOvmfSecGhcbPageTable but TDX > doesn't need that page. If the common OvmfMetadata is consumed by > TDX-QEMU, then PcdOvmfSecGhcbPageTableBase will be initialized too. > That doesn't make sense. We have different range types. OVMF_* are the common areas. SEV_* will be used by sev only, TDX_* will be used by tdx only. TDX and SEV entries are allowed to overlap, i.e. PcdOvmfSecGhcbPageTableBase should have some SEV_* type for sev (I think this needs fixing in the series), and tdx can use the page for something else by adding an TDX_* entry for the same range. > I am thinking that SEV and TDX can keep their own Metadata (in > separate files, SevMetadata.asm and TdxMetadata.asm) which are pointed > by the SEV or TDX offsets in the GUID-ed chain in ResetVector. I'd very much prefer to have a single table to avoid duplication for the common memory areas and keep the reset vector small. Having separate SevMetadata.asm + TdxMetadata.asm files (then have OvmfMetadata.asm include these two) is an option. I think this isn't needed, we can also just group the entries in OvmfMetadata.asm. > In this case, SEV and TDX can design their own metadata flexibly, for > example, the attribute, the item structure, add/remove/update the > items, etc. Why have two ways to do the same thing? take care, Gerd