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.web10.8571.1623248895842892391 for ; Wed, 09 Jun 2021 07:28:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=QkFvqTTe; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 159E2oe8036017; Wed, 9 Jun 2021 10:28:14 -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 : mime-version : content-transfer-encoding; s=pp1; bh=miuzuxeyHm/GaKHJ+RyQrvxEThnFsodX+SgsBZ8hL3U=; b=QkFvqTTeNgNijiv6WuXN3JQV0wlTr0u7qFSzEIYuzbXnPqw8L8bB+ciMgPMHY4cfqI50 Pptkh2tI4Jz1hO9vj9DGzeCg0vpT7FP7wKT5dx5RUl3ZJqIZrtAgY9RwcdvNp4SSNiju yNi5VWkSDJg9Bjn3OScSOVFQyIGwbGmZ/DBrnudfZWMdh6zq8pMOlx50bVfGUaThMj+z Rem1gF9IlRVDPbpfKqE2RT8Y4K5uu+41AOBo3P5mMsHBKqxmE1SbxJddMUSALHD4jj2T qP4aVl9HAWX3Ini6grZwK/IbmW6L6qtikel51WokcYJrwxSnAHty5gpj8Jq66FhevNYl VA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 392xw5140b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 10:28:13 -0400 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 159E31j7037050; Wed, 9 Jun 2021 10:28:13 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 392xw513y0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 10:28:13 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 159EGo5u027162; Wed, 9 Jun 2021 14:28:12 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma05wdc.us.ibm.com with ESMTP id 3900w9r7fd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 14:28:11 +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 159ESAog27459952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jun 2021 14:28:11 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DB2C778060; Wed, 9 Jun 2021 14:28:10 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6362E78066; Wed, 9 Jun 2021 14:28:07 +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:28:07 +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: "Xu, Min M" , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: Laszlo Ersek , 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:28:05 -0700 In-Reply-To: References: User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 5aGRKG0vCWiv8ndraCa2024BjB7zFbUj X-Proofpoint-ORIG-GUID: eLUpRN-gtZgiM6CkrPdeVMT1HXYvDsuP 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 bulkscore=0 clxscore=1015 impostorscore=0 mlxlogscore=723 priorityscore=1501 spamscore=0 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106090070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-06-09 at 02:01 +0000, Xu, Min M wrote: > On 06/09/2021 12:01 AM, James Bottomley wrote: [...] > > On slide 19, the mucking with the reset vector really worries me > > because we don't have that much space to play with. Given that > > you're starting in 32 bit mode and can thus enter anywhere in the > > lower 4GB, why not simply use a different and TDX specific entry > > point? > > > If TDVF has a separate DSF/FDF, this is not a problem. > > I once think about below solution, that different mode goes to its > specific entry point. > For example: > real-mode goes to 0xfffffff0, > protected-mode goes to 0xffffffe0, > long-mode goes to 0xffffffd0. That would cut across the ApEntrypoint and the guidedStructureEnd. However, nothing says anything in the reset vector guided structure has to be data ... so it could equally well be code. That means we can do guid based entries that contain the 32 bit real and 64 bit entry points. This would also come with the added advantage that we can scan the OVMF binary to see what entry points it supports. James