On 09/30/2014 04:36 AM, Laszlo Ersek wrote:
> ...
> - The OvmfPlatformsLib class would have the following *three* instances:
>
> (a) for SEC and PEI_CORE: interrogate the registers all the time.
>
> (b) for PEIM, DXE_CORE, DXE_RUNTIME_DRIVER, DXE_DRIVER: call
> GetFirstGuidHob(). If it succeeds, return data from the structure
> found, if it fails, interrogate the registers.
>
> This library will show the following behavior:
>
> - in PEIM code running before PlatformPei: query registers
>
> - in PEIM code running after PlatformPei: use HOB
>
> - in DXE_CORE: use HOB (yes, available)
>
> - in DXE_RUNTIME_DRIVER, DXE_DRIVER: use HOB
I don't believe the HOB list is available at runtime, after
ExitBootServices, is it? On many physical platforms it's not; I haven't
checked OVMF specifically. The DXE_RUNTIME_DRIVER version would need to
look up the values at boot time in its constructor and cache them in
globals, or fall back to reading the registers at runtime.
(My soapbox speech for the day: In general, I'd recommend caching the
values in a constructor whenever possible, instead of traversing the HOB
list. On some platforms the HOB list may be short, but on other,
real-world systems, it can be huge. Linear searches are surprisingly
expensive, especially if they get done frequently.... For OVMF it may
not be an issue, and optimizing before measuring is always risky. But
as someone who works on large systems for a living, I encourage
scalability in public sample code. Thanks.)
>
> (c2) A (much faster) alternative for UEFI_DRIVER, UEFI_APPLICATION:
> the HOB-based library instance (b) would work just as well for
> UEFI_DRIVER and UEFI_APPLICATION, at the price of some
> theoretical portability. (Note that it's still better / less
> intrusive than using PCDs.)
>
> - GetFirstGuidHob() has a valid implementation for these module
> types (see "MdePkg/Library/DxeHobLib/DxeHobLib.inf").
>
> - That implementation is based on the UEFI System Config Table.
>
> - Although the GUID used in HobLibConstructor() to locate the
> HOB list in the UEFI System Config Table -- ie.
> gEfiHobListGuid -- is only part of the PI spec, and not the
> UEFI spec, we already depend on it heavily, because:
>
> - HobLibConstructor() asserts that the HOB list be found,
>
> - and we *already* resolve the HobLib library class to
> DxeHobLib for UEFI_DRIVER.
>
> - This dependency has a graceful, explicit failure mode, in
> relation to portability: ASSERT() if HOB List is not found --
> which will never happen on PI-compliant platforms -- and
> query registers if HOB List is found but our specific HOB is
> not found.
Would anyone take a driver or app built from the OVMF tree and use it on
another, non-PI system? I suppose OVMF is a handy development and
testing tool... But if a developer is building for portability, they
need to be careful about their library instances in any case. Your
proposal sounds OK to me (although I'm not one whose opinion matters
here, since I'm not involved with OVMF development. I'm just
commenting, since I was already responding to this thread.)
--
Brian Johnson
--------------------------------------------------------------------
"You have greater impact on others by the way you listen than by the
way you talk."
-- Unknown
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
