Messages in this thread | | | Subject | Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting | From | Matt Fleming <> | Date | Thu, 09 Aug 2012 09:51:35 +0100 |
| |
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().
| |