From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web08.8761.1623249405669718693 for ; Wed, 09 Jun 2021 07:36:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=JexOE4we; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 159EWg4O092654; Wed, 9 Jun 2021 10:36:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=9kSO//XJFufDG+k9hWhtyC1vAwG7o5rv1BsXxpTGXfA=; b=JexOE4we9Ic/kHtYmDMxZpCguN6BiGxynHHAwmJtjoTPPtXD3Kq0+KaihIdDMTGq47kp amSKykQpbULoGmbVOF0E6lRFX2eAP0rohbHpEKw2Dr0bnfemCin39vh+teM1kiHU+dgy re4Vzzbcpupn2plerGr+JGOU6xZKNi1tCNbhiM/b8wuTT9EnM/OzVKh8bOOVrb8rrpuL NOpoR3nsbHZaWJ3CoHK/N7Vof1BzyY+ZQtrG+mdp5ohngDwpy8AEm8X+CnDjHi8Cn2Cs +1g4/iAy9ThMylz03ioRWgEqmc+5AheOe04sf2CeaoPxO5THhEO2YsorIgAMnz3BDBVV nw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 392wfwvrqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 10:36:43 -0400 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 159EWoLX093342; Wed, 9 Jun 2021 10:36:43 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 392wfwvrpw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 10:36:43 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 159EI1qj006916; Wed, 9 Jun 2021 14:36:42 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma04wdc.us.ibm.com with ESMTP id 3900w9rapx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 14:36:42 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 159Eafhg31457672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jun 2021 14:36:41 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0CD0178060; Wed, 9 Jun 2021 14:36:41 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 897B478066; Wed, 9 Jun 2021 14:36:37 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.129.99]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 9 Jun 2021 14:36:37 +0000 (GMT) Message-ID: Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Laszlo Ersek , "Xu, Min M" , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." Date: Wed, 09 Jun 2021 07:36:36 -0700 In-Reply-To: <27ee4270-7f88-6939-ffa8-6d52bbe266a2@redhat.com> References: <27ee4270-7f88-6939-ffa8-6d52bbe266a2@redhat.com> User-Agent: Evolution 3.34.4 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 2foKApISLEO8C0xzqcC7nKYfHOR4I5W6 X-Proofpoint-ORIG-GUID: XzNYnFdTc98dnK4H6965wfNkxrjipakF X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-09_04:2021-06-04,2021-06-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 impostorscore=0 clxscore=1015 adultscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=780 lowpriorityscore=0 mlxscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106090072 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-06-09 at 13:00 +0200, Laszlo Ersek wrote: > On 06/09/21 02:58, Xu, Min M wrote: > > On 06/09/2021 3:33 AM, Laszlo wrote: > > > On 06/08/21 18:01, James Bottomley wrote: > > > > On your slide 13 Question: "Open: How will the QEMU find the > > > > metadata location?" can't you just use the mechanism for SEV > > > > that's already upstream in both QEMU and OVMF? > > > > > > I think I made the same comment, in different words. (Point (12) > > > at > > > > > June/msg00143.html>.) > > > > > So my understanding to this solution is that: > > 1) GUID-ed structure chain is started from a fixed GPA in > > ResetVector. > > 2) Append a TDX-specific GUID-ed structure in the chain > > 3) Qemu search the GUID-ed chain from the fixed GPA and find the > > TDX-specific GUID-ed structure based on TDX-specific GUID. > > Is the expected process for QEMU? > > This is my understanding, yes; James will know more details though. Pretty much, yes. The guided structure is designed as a backwards table, so you can tell if it's present or not by looking for the table guid (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If you find that, it gives you the size of the table as the u16 preceding the GUID. All entries are of the form You can see how it works in OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm Beginning around line 35. In QEMU you want the function pc_system_ovmf_table_find() which is in hw/i386/pc_sysfw.c and finds entries by guid. James