On Aug 7, 2013, at 1:19 PM, Matt Fleming <[email protected]> wrote:
> [ Readding Matthew Garrett to the Cc list, seeing as we both got removed > for some unknown reason ] > > On Wed, 07 Aug, at 10:23:56AM, Andrew Fish wrote: > >> OK so I think I need some Cliff Notes here to help me understand what >> is going on... >> >> type 4 is EfiBootServicesData and attr 0x0f is cache attributes with >> no request for a runtime mapping. This is not runtime memory so to the >> OS loader it is just memory EFI has used that will get freed back to >> the OS after ExitBootServices(), along with EfiBootServicesCode, >> EfiLoaderCode, and EfiLoaderData. The EfiLoaderCode and EfiLoaderData >> also get freed back to the OS and they just exist for the convenience >> of the OS loader. >> >> So I can't figure out why this maters? Given: > > We've seen a bunch of systems that make calls into EfiBootServicesCode > after ExitBootServices(). There were some Apple machines in that list, > though I don't have the details but Matthew should. > I think there was some very old EDK (pre edk2) bug that caused some SMM code to grab EfiBootServicesCode at runtime. In some older Apple machines I remember working with Mathew to track down a bug in the WiFi driver not shutting down its DMA at ExitBootServices() time. I'm guessing in general that pre-Windows 8 systems may tend to be buggy. > So we map these regions unconditionally and in their original state, > otherwise the firmware will generate fatal page faults when trying to > access those memory regions. > Well the issue I see is I don't think OS X or Windows are doing this. So I'm guessing there is some unique thing beings done on the Linux side and we don't have good tests to catch bugs in the EFI implementations. If the Linux loader hides the bugs and we don't hit them with other operating systems they are never going to get fixed. It would be good if we could track down some of these issues and make a request for some tests that can help catch these issues. The tests would be part of UEFI.org, but since some of us play in both worlds we can forward the known issues to the UEFI test work group. Is it possible to have a switch to turn off the not required behavior (hiding EFI implementation bugs) so that bad platforms could be detected? This would be a good thing to try on platforms at the upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI Forum, so the bad behavior can be detected and the vendors can fix the issue. Thanks, Andrew Fish PS Also maybe it would be possible to key this work around behavior on the EFI/UEFI version. So for example no work-around after UEFI v2.3.1? > -- > Matt Fleming, Intel Open Source Technology Center ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
