On 09/30/14 16:16, Brian J. Johnson wrote: > 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.
Yes. PEIM, DXE_CORE, DXE_RUNTIME_DRIVER, DXE_DRIVER would all be covered by the same library instance (for simplicity), and your recommendation looks good for all of them. > (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.) Sounds good, 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.) I think we all believe that noone would try to run OVMF's UEFI_DRIVER's on different (physical) systems :) Thanks Laszlo ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
