From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5CE4721168207 for ; Thu, 18 Oct 2018 23:02:09 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2018 23:02:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,398,1534834800"; d="scan'208";a="83850955" Received: from shzintpr01.sh.intel.com (HELO [10.7.209.51]) ([10.239.4.80]) by orsmga006.jf.intel.com with ESMTP; 18 Oct 2018 23:02:06 -0700 To: Ard Biesheuvel Cc: "Dong, Eric" , "edk2-devel@lists.01.org" , Peter Jones , "Yao, Jiewen" , "Kinney, Michael D" , star.zeng@intel.com References: <20181019025418.3037-1-ard.biesheuvel@linaro.org> <0C09AFA07DD0434D9E2A0C6AEB0483103BC2352B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BC2357A@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BC235A6@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BC23615@shsmsx102.ccr.corp.intel.com> From: "Zeng, Star" Message-ID: <7178203c-074b-b592-801c-41901bd59fda@intel.com> Date: Fri, 19 Oct 2018 14:01:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:02:09 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 2018/10/19 13:28, Ard Biesheuvel wrote: > On 19 October 2018 at 13:25, Zeng, Star wrote: >> Be honest, I am not clear about the history why EfiBootServicesData is required for ESRT. But OS indeed cares about ESRT table, for example, I guess the Firmware in Device Manager for Windows is built based on ESRT table. In fact, I think OS loader can access either EfiBootServicesData or EfiRuntimeServicesData configuration table as it controls the runtime phase point. >> > > The problem is not with the OS. The OS can access it it any time it > want, and create a virtual mapping for it. > > The problem is with the firmware: any table that the firmware wants to > access *itself* requires a virtual mapping to be provided by the OS in > SetVirtualAdressMap(), so that the virtual address is known to the > firmware. Only when firmware wants to access it at *runtime*. > >> I am concerning that even the spec could be updated, our code may still need caching for backward compatibility. >> > > I don't think that should be a problem: Linux permits the ESRT to > reside in EfiRuntimeServicesData already, because certain x86 > production systems do that. This means that it is highly unlikely that > Windows disallows this. I meant firmware compatibility. If we assume ESRT is only produced by EsrtDxe/EsrtFmpDxe (common code), that should be ok. But if the ESRT is produced by other codes (non-common), it may be hard to assume they could be updated at the same time. I admit it is rarely case. :) Thanks, Star > > > >> >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Friday, October 19, 2018 1:11 PM >> To: Zeng, Star >> Cc: Peter Jones ; edk2-devel@lists.01.org; Dong, Eric ; Leif Lindholm ; Kinney, Michael D ; Yao, Jiewen >> Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory >> >> On 19 October 2018 at 13:01, Ard Biesheuvel wrote: >>> On 19 October 2018 at 12:48, Zeng, Star wrote: >>>> Ok, thanks and got the case. >>>> >>>> DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not allocate pool to do caching. >>>> I meant registering gEfiSystemResourceTableGuid event group notification(installconfigurationtable will trigger event group) and do caching in the notification function. >>>> >>>> >>> >>> OK, I will create a bugzilla for this. >>> >> >> As I understand it, the reason we require EfiBootServicesData for the ESRT is because the OS may not care about this table, and so we don't want to waste the memory. However, if we end up caching the entire table in EfiRuntimeServicesData anyway [so that the firmware itself can access it], is there still a point to keeping this requirement? >> Shouldn't we update the spec regardless?