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.129.124]) by mx.groups.io with SMTP id smtpd.web11.10985.1683704914621992301 for ; Wed, 10 May 2023 00:48:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=d6GYo/wc; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683704913; 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: in-reply-to:in-reply-to:references:references; bh=wFMVyXWGVsp+P/oSkWN9ncQMI0C3DRzU8JsqpvIpado=; b=d6GYo/wcUG0m0vN0sLp15MbaZkGULbotq9Sn1R+RI+0dRWZSv1QHFjcStN8r+mk2D1zPIN O4k3IzIf6ZFzFr3LaTnmfn7c+JkHin1ZBo4CuG+vS7ByHgSAaruW98dMkqJLf3XRc0ZWR4 DhiepZIVpjfm03Hye7ng5/k94XmXlX0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-263-m82gdJRlO3er-kYijnH7rg-1; Wed, 10 May 2023 03:48:32 -0400 X-MC-Unique: m82gdJRlO3er-kYijnH7rg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9FDD81C087AC; Wed, 10 May 2023 07:48:31 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 540CD48FB12; Wed, 10 May 2023 07:48:31 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 841C018003AB; Wed, 10 May 2023 09:48:25 +0200 (CEST) Date: Wed, 10 May 2023 09:48:25 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, ray.ni@intel.com Cc: "Wu, Jiaxin" , "Dong, Eric" , "Zeng, Star" , "Kumar, Rahul R" Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page table to permanent memory Message-ID: References: <20230509102253.16632-1-jiaxin.wu@intel.com> <20230509102253.16632-2-jiaxin.wu@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote: > Gerd, > My understanding is that when code dereferences memory address, the code itself is responsible for > supplying the sign-extended linear address. > The page table creation logic still maps the entire linear memory space supported by the CPU. > > Why do you think covering the half of the space is better? edk2 boot services operate on the assumption that everything is identity mapped, only runtime services know the concept of virtual addresses. The lower half of the address space can be identity-mapped (virtual address == physical address). The upper half can not, so I think it's better for efi boot services to restrict themself to the lower half. take care, Gerd