From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web08.8748.1617808384443847417 for ; Wed, 07 Apr 2021 08:13:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=GTIwt7gr; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 137F3feB173357; Wed, 7 Apr 2021 11:13:02 -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=bzHHY6zm5hFA5lhX5yrj/JtfsInbaSrdNBwmrK1jO/U=; b=GTIwt7grHyifgAP5Ab91+6K4fLFYW3aj9PjodWjVNt/hVk1eI+LMUatmsWcdJHAJayjk chnPa/liPAeOoYsoiIKqZW9aaJ3YGZgt2WLme8DBa3ZuZABXcJlJ73HJlTDG8VKYkDiL Qar6XsHmxXq9b05rzBjEZwhwCY5xoUkNwLakt1Nfs2yTYHCCHeJdLdqV8YxqrIDIZTCl FluZAfqCFbp/RcvFC9GWqJMFfk6ITHmSI81CeIJx1Jx0cI/464cBGNM64eaauVX30za4 jpTz8wqNmWnc/VODeXekjtVloefImkxRGdpZst4uy/v9zyq8bC+w4PrBLfgPhUwlrhn+ 8w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 37s5xshc27-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Apr 2021 11:13:02 -0400 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 137F3jsf173707; Wed, 7 Apr 2021 11:13:01 -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 37s5xshc1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Apr 2021 11:13:01 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 137EvYP2025294; Wed, 7 Apr 2021 15:13:00 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma04wdc.us.ibm.com with ESMTP id 37rvu1x820-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Apr 2021 15:13:00 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 137FCxV932178472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Apr 2021 15:12:59 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C53078067; Wed, 7 Apr 2021 15:12:59 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B2E7D78069; Wed, 7 Apr 2021 15:12:57 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.189.52]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 7 Apr 2021 15:12:57 +0000 (GMT) Message-ID: Subject: Re: [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Laszlo Ersek , "Xu, Min M" , Brijesh Singh , "devel@edk2.groups.io" Cc: "Yao, Jiewen" , Tom Lendacky , "Justen, Jordan L" , Ard Biesheuvel Date: Wed, 07 Apr 2021 08:12:56 -0700 In-Reply-To: <9aa00ba0-def0-9a4e-1578-0b55b8047ebd@redhat.com> References: <20210324153215.17971-1-brijesh.singh@amd.com> <20210324153215.17971-2-brijesh.singh@amd.com> <719a63e555376ca65a7bbe0c7e23c20b6b631cd3.camel@linux.ibm.com> <9aa00ba0-def0-9a4e-1578-0b55b8047ebd@redhat.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BNnLmptuB7W4vhU8zou2PpIxtJfyi6XQ X-Proofpoint-ORIG-GUID: GcKRehKNk9BeHy7Sc8xn6uDhSKfwgEQf X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-07_08:2021-04-07,2021-04-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 mlxscore=0 spamscore=0 impostorscore=0 mlxlogscore=962 bulkscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104070107 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-04-07 at 17:02 +0200, Laszlo Ersek wrote: > On 04/07/21 02:44, James Bottomley wrote: > > On Wed, 2021-04-07 at 00:21 +0000, Xu, Min M wrote: > > > Hi, Laszlo > > > > > > For Intel TDX supported guest, all processors start in 32-bit > > > protected mode, while for Non-Td guest, it starts in 16-bit real > > > mode. To make the ResetVector work on both Td-guest and Non-Td > > > guest, ResetVector are updated as below: > > > --------------------------------------------------------------- > > > --- > > > ALIGN 16 > > > resetVector: > > > ; > > > ; Reset Vector > > > ; > > > ; This is where the processor will begin execution > > > ; > > > nop > > > nop > > > smsw ax > > > test al, 1 > > > jnz EarlyBspPmEntry > > > jmp EarlyBspInitReal16 > > > > Well, then use the rel8 jump like the compiler would in this > > situation: > > > > smsw ax > > test al, 1 > > jz 1f > > jmp EarlyBspPmEntry > > 1: > > jmp EarlyBspInitReal16 > > > > So now both entries can be 32k away. > > The problem is that we need NASM to generate such *shared* entry code > that behaves correctly when executed in either 16-bit or 32-bit mode. > > The rel8 near jumps ("short jumps") are like that -- for example, the > "74 cb" opcode decodes to the same "JZ rel8" in both modes. > > But the rel16 ("non-short") near jumps turn into rel32 near jumps > when decoded in 32-bit mode. For example, "E9 cw" decodes to "JMP > rel16" in 16-bit mode, but it gets parsed as "E9 cd" (= "JMP rel32") > in 32-bit mode. > > So the idea is to add more BITS directives, for covering the non- > short near jumps themselves: Absolutely ... sorry, I should have said this was just the first thing I thought of. The key point is don't do a rel8 jump over the guid table, use the rel8 jump within the reset vector to sort out the final destination and use the wider jumps to go over the guid table. As you say, we have to be very careful about the wider jumps given the differences between the entry modes. James