On Thu, Aug 9, 2012 at 1:51 AM, Matt Fleming <matt.flem...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
