Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [PATCH 0/5] x86_64 EFI support -v3 | Date | Wed, 08 Aug 2007 10:45:53 -0600 |
| |
"Huang, Ying" <ying.huang@intel.com> writes:
> On Tue, 2007-07-31 at 12:47 +0800, Eric W. Biederman wrote: >> Using efi_set_virtual means kdump doesn't work which means that no >> one is going to use this in a prebuilt kernel. > > It is possible to make kexec/kdump work with EFI virtual mode, in > following ways:
Yes we can make it work if we absolutely have to. There doesn't seem to be much point to jump through hoops for a feature we don't need. A fixed virtual address and a fixed physical address have essentially the same implications for the kernel. A fixed address we are stuck with and if the kernel diverge by very much we have problems.
Since there are people actively investigating things like booting OpenBSD via kexec things get even worse. Nothing hardly runs on ia64 so that issue doesn't come up.
As for not using EFI at all. If we can avoid it/not use it in the dump kernel there is very little point in having it in the primary kernel.
Especially since it appears EFI is only 64 bit or only 32 bit I think we need to forget about efi_set_virtual_address and only call into EFI via a trampoline that set things up properly whatever mode EFI is running in on that particular box.
So far there don't seem to be any compelling advantages to running EFI in virtual address mode and several compelling disadvantages included having to change the permissions on the kernels memory map to running EFI in virtual mode.
Please let's stick to a physical mode trampoline and only revisit the topic when users start having problems because of the performance hit of going through our trampoline to the EFI runtime services.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |