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.web10.7063.1617801884158174053 for ; Wed, 07 Apr 2021 06:24:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LzP7Eh0W; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617801883; 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=G8ZJsVHfQsu18NlJN94PTTehB2Ki1ljjGw5kDO4uEyg=; b=LzP7Eh0WQOGMsPhcz50CKZ9IyR5EZWrCZtSOyIghescc6zyPQMFIMLJ+aplR9oTIGfyHaj NOigk7uNiiCFXkksnDLBEXvjjKZwy2qWom2Sbpe6+flWCFGNpnaBEvvUYp5bvl+YY0jkcm 7FSMlLL5GQj7iKDAqbdNI25vhD0YiBI= 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-265-NUpD8CPwNQeY8G3TnafZHw-1; Wed, 07 Apr 2021 09:24:41 -0400 X-MC-Unique: NUpD8CPwNQeY8G3TnafZHw-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 245861008060; Wed, 7 Apr 2021 13:24:40 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-38.ams2.redhat.com [10.36.112.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 57C8B1DB; Wed, 7 Apr 2021 13:24:38 +0000 (UTC) Subject: Re: [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest From: "Laszlo Ersek" To: "Xu, Min M" , Brijesh Singh , "devel@edk2.groups.io" Cc: James Bottomley , "Yao, Jiewen" , Tom Lendacky , "Justen, Jordan L" , Ard Biesheuvel References: <20210324153215.17971-1-brijesh.singh@amd.com> <20210324153215.17971-2-brijesh.singh@amd.com> <47bf3b5a-dde6-0807-ee54-704870326ef9@redhat.com> Message-ID: <69ebd115-e071-827b-be64-0ecaf27ca8bb@redhat.com> Date: Wed, 7 Apr 2021 15:24:37 +0200 MIME-Version: 1.0 In-Reply-To: <47bf3b5a-dde6-0807-ee54-704870326ef9@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 04/07/21 15:22, Laszlo Ersek wrote: > On 04/07/21 02:21, Xu, Min M wrote: > >> Intel TDX also has metadata which is consumed by QEMU. We put the metadata >> in a single file (TdxMetadata.asm) and put it at the end of ResetVectorVtf0. >> Then a pointer is placed in a known location in ResetVector.nasm. In this way >> QEMU can easily read the Metadata by the pointer. >> ------------------------------------------------------------------ >> ALIGN 8 >> ; >> ; TDX Virtual Firmware injects metadata in VTF0. >> ; The address of the metadata is injected in this location (0xffffffe8) >> ; >> DD (OVMF_IMAGE_SIZE_IN_KB * 1024 - (fourGigabytes - TdxMetadataGuid - 16)) >> ; >> ; The VTF signature >> ; >> ; VTF-0 means that the VTF (Volume Top File) code does not require >> ; any fixups. >> ; >> vtfSignature: >> DB 'V', 'T', 'F', 0 >> ------------------------------------------------------------------ >> >> The space in ResetVector is very precious and we all want a known location so that QEMU >> can find the metadata easily. Putting the metadata in a single file give the developers >> more flexible (They can put anything they want). So I think a pointer (point to a metadata >> file) in a known location maybe a better solution. > > Assuming a QEMU version has been released that looks for the chain of > GUID-ed structs already, then I think such a change would break > compatibility with that QEMU version. > > If we definitely need a separate spot to include more information in the > flash, for QEMU's parsing, then please introduce a new GUIDed structure, > which contains nothing but a pointer to that spot. Ah, upon re-reading James's earlier message which he just referenced, namely at https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg01063.html it's clear that James had already proposed this: > That's not to say we can't have a larger table ... we definitely can, > but it can't be where it is now. we'd have to do something different > like make the table guid describe where the actual table is located > (as a 32 bit offset and length) so as not to break up the 16 bit jump > code. Thanks Laszlo