From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.8342.1617971396429493104 for ; Fri, 09 Apr 2021 05:29:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=i67M3RK4; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617971395; 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=p1XkuG8Pc1AaomuCPZ7QpnJNtCVPJzSqprGHQtaiJlE=; b=i67M3RK4u7i7mFU5VJrVGbtditO2f7Kd3ns0TFo0SHdTJCfezcbUDPk/jIFKfud6rbDbO6 C8wEi03aXXUjq2xmikbxjmzOl0R7l4f4uGVzu2q7pTEzz15pFhvM1klU23aa5lEriRSd7v 2v+cHplFukwy9urTsvq/P5q3zZpF9Pk= 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-358-UnE2eGpCODOqtV1ONlrhdQ-1; Fri, 09 Apr 2021 08:29:53 -0400 X-MC-Unique: UnE2eGpCODOqtV1ONlrhdQ-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 90F92107ACCD; Fri, 9 Apr 2021 12:29:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-137.ams2.redhat.com [10.36.115.137]) by smtp.corp.redhat.com (Postfix) with ESMTP id BECAB5C3E9; Fri, 9 Apr 2021 12:29:50 +0000 (UTC) Subject: Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest To: Tom Lendacky , "Xu, Min M" , "devel@edk2.groups.io" , "jejb@linux.ibm.com" , Brijesh Singh Cc: "Yao, Jiewen" , "Justen, Jordan L" , Ard Biesheuvel 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> <2ff2c569-1032-3e5f-132a-159c47c9f067@amd.com> From: "Laszlo Ersek" Message-ID: <4d83d17e-b393-7b35-fb3c-4c0c802d36d3@redhat.com> Date: Fri, 9 Apr 2021 14:29:49 +0200 MIME-Version: 1.0 In-Reply-To: <2ff2c569-1032-3e5f-132a-159c47c9f067@amd.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/08/21 15:31, Tom Lendacky wrote: > On 4/8/21 1:24 AM, Xu, Min M wrote: >> On Wednesday, April 7, 2021 11:03 PM, Laszlo 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: >> >> Yes this is the root cause. TDX requires the startup mode to be 32-bit >> protected mode while the legacy VM startup mode is 16-bit real mode. >> Add more BITS directives can work round this. I have tried it and it works. >> >> So my initial solution is to use *jmp rel8* because it works in both 16-bit >> and 32-bit mode. But *jmp rel8* depends on the distance which should >> be less than 128 bytes. If more metadata is added in the ResetVector.asm >> then we have to use the BITS solution. > > To me, it sounds like the BITS solution should be the approach you use > from the start. I agree; we have an extensible approach in place already (with the GUIDed struct list), and QEMU already knows about one magic GPA (for locating the head of the list). Using one conditional rel8 jump, and two non-conditional mode-specific (rel16/rel32) jumps, doesn't cost much in the assembly code, it's compatible with future GUID additions, and shouldn't affect QEMU's GUIDed struct list traversal. Thanks Laszlo