Re: [PATCH 0/5] x86_64 EFI support -v3

[ebiederm@xmission.com (Eric W. Biederman)]

"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/