On 2018/10/19 13:28, Ard Biesheuvel wrote:
On 19 October 2018 at 13:25, Zeng, Star <star.z...@intel.com> 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.biesheu...@linaro.org]
Sent: Friday, October 19, 2018 1:11 PM
To: Zeng, Star <star.z...@intel.com>
Cc: Peter Jones <pjo...@redhat.com>; edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>;
Leif Lindholm <leif.lindh...@linaro.org>; Kinney, Michael D <michael.d.kin...@intel.com>; Yao,
Jiewen <jiewen....@intel.com>
Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from
RtServicesData memory
On 19 October 2018 at 13:01, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
On 19 October 2018 at 12:48, Zeng, Star <star.z...@intel.com> 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?
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
