From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.34102.1599207831977080998 for ; Fri, 04 Sep 2020 01:23:52 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) 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-420-k71MY0EpOLKTdXPHwsDZEQ-1; Fri, 04 Sep 2020 04:23:49 -0400 X-MC-Unique: k71MY0EpOLKTdXPHwsDZEQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 54DB818B9F85; Fri, 4 Sep 2020 08:23:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-161.ams2.redhat.com [10.36.112.161]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F4C11A4D6; Fri, 4 Sep 2020 08:23:46 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTog5Zue5aSNOiBbZWRrMi1kZXZlbF0gW1BBVENIIHYyXSBVZWZpQ3B1UGtnL01wSW5pdExpYjogQWRkIGNoZWNrIGZvciBDUjMvR0RUL0lEVC4=?= To: Fan Jeff , "devel@edk2.groups.io" , "eric.dong@intel.com" , "Ni, Ray" Cc: "Lou, Yun" References: <20200903151147.1196-1-eric.dong@intel.com> <9c9d8289-4f8e-75d8-2816-750195a54842@redhat.com> From: "Laszlo Ersek" Message-ID: <65af66ca-5eaf-163f-1973-cb8260cc50c1@redhat.com> Date: Fri, 4 Sep 2020 10:23:45 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US On 09/04/20 09:32, Fan Jeff wrote: > Laszlo, > > Why sync the BSP's CR3/GDT/IDT values for AP when AP wakes up instead > of using old cached BSP's CR3/GDT/IDT values when CPU driver > initiallly dispatched is that we CANNOT assume original values are > still valid during POST phase. > > On this senario, BSP's CR3/GDT/IDT are just like input parameters for > one function. Validating them are necessary. > > For example, DebugAgentDxe driver may be loaded in UEFI shell to setup > source level debugging enviroment of EDKII debugger tools. It may > setup new IDT space. Then DebugAgentDxe should be changed to allocate the new IDT in the 32-bit address space. I don't think it's acceptable that loading DebugAgentDxe from the UEFI shell may or may not render the MP services protocol unusable. What if the programmer wants to debug something related to MP services? "I've loaded DebugAgentDxe, but now I cannot start the payload I want to debug." As far as I can see, "SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/DxeDebugAgentLib.c" uses the static variable "mIdtEntryTable" as IDT. I think it should be possible to replace "mIdtEntryTable" with a dynamically allocated object. The allocation should be restricted to 32-bit. It should be possible to perform the allocation very early (perhaps in the library constructor). Again, I'm OK with adding ASSERT()s to FillExchangeInfoData(). If IDT / GDT / CR3 are out of 32-bit address space, then that's a programming error, or a platform misconfiguration. It's not something we should try to dynamically recover from. The MP services protocol implementation may not expect that the CR3/GDT/IDT remain unchanged on the BSP during the DXE/BDS phases, but it does expect them to remain under 4GB. - A UEFI driver or app must not break this assumption at all, because a UEFI driver or app has no business messing with these artifacts. - Whereas a DXE driver (such as DebugAgentDxe), exactly because it is part of the platform firmware, is expected to collaborate with CpuDxe / MpInitLib, and to satisfy the invariants. Thanks, Laszlo