Messages in this thread | | | Date | Fri, 10 Aug 2012 12:22:12 -0700 | Subject | Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting | From | Yinghai Lu <> |
| |
On Thu, Aug 9, 2012 at 1:51 AM, Matt Fleming <matt.fleming@intel.com> wrote: > On Tue, 2012-08-07 at 11:50 +0100, Jan Beulich wrote: >> > >> > I managed to find a machine to reproduce this on and it looks like the >> > ASUS firmware engineers are upto their old tricks of referencing >> > physical addresses after we've taken control of the memory map, >> >> Yippie. On such systems we simply can't do any runtime calls. >> Should we add a command line option forcing efi_native to false, >> thus suppressing all runtime calls? Or would the "noefi" one be >> enough already? > > I think a better solution for this, seeing as there appear to be *so* > many ASUS machines in the wild with this inability to do virtual EFI > calls, is to provide a 1:1 mapping as well as our regular virt->phys > mapping for the benefit of the firmware. We can load our special page > table in efi_call_*, etc. > > One thing to note is that because of breakage seen on Apple machines > last time Matthew tried this approach, we (the kernel) can't actually > access the 1:1 mapping, it would exist purely for the benefit of > firmware that was broken enough to reference physical addresses after > SetVirtualAddressMap(). >
What is solution for this regression?
It seems Jan's commit broke our setup with UEFI too.
Assume other systems with AMI code base would have same problem.
Thanks
Yinghai
| |