On 09/12/13 at 02:53pm, Borislav Petkov wrote:
> On Thu, Sep 12, 2013 at 03:34:15PM +0800, Dave Young wrote:
> > I'm playing with skipping SetVirtualAddressMap in kexec kernel, for
> > same kernel the test result is ok for me both for kexec and kdump.
> > Takao Indoh sent a patch with this approatch, but his V2 switched to
> > use physical mapping. During my test, additional data of config table
>
> Physical mapping won't work because of some very brilliant Apple UEFI
> implementations, as I came to realize. My previous version did that :)
>
> > elems need to be saved besides of fw_vendor, runtime and tables or
> > dereference taglep->guid will panic.
> >
> > Also kexec userspace need to fill efi_info in bootparams and pass the
> > previous saved efi data to 2nd kernel.
>
> Hmm, yes, we need to tell the kexec kernel the EFI regions.
>
> > I'm worrying just skiping enter virt mode have risk though it's an
> > easy solution. Your 1:1 mapping approatch looks better. I look forward
> > to test your new patchset.
>
> Yeah, we had a discussion at the SUSE Labs conf about whether we could
> really skip SetVirtualAddressMap in the first kernel and do it in the
> kexec kernel but the first kernel might want to call runtime services
> for whatever reason and for that we need the runtime services. So we
> opted for the stable VA mappings.
I means only skipping SetVirtualAddressMap in kexec kernel, ioremap result
should be same with 1st kernel, but I'm not sure, it's what I worried about.
With 1:1 mapping, even we do not call SetVirtualAddressMap in kexec kernel
the mapping will be same in theory.
>
> > Are you also working on kexec userspace part? Already have a patch?
>
> Why userspace part - I'm thinking the kexec'ed kernel would simply add
> the mappings made by SetVirtualAddressMap without calling it. And it
> will know which mappings go to which virtual addresses because we start
> at the -4G virtual address and go downwards and the mappings will have
> the same addresses per UEFI implementation.
>
> It'll make more sense when you see the code, I hope :)
For user space part, we need at least fill efi_info in kexec boot loader.
I have a test patch for this.
Also the fw_vendor, runtime, tables elements will be fixed up to use
virtual address after 1st kernel call SetVirtualAddress, so even with
1:1 mapping we still need save them and use in kexec kernel.
Such as below code assume fw_vendor is physical address:
c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
So as what Takao has done we need to save them and use the saved value
in kexeced kernel. Previously he used is_kdump_kernel() to check if it's
a kdump kernel. But this is not enough because we'd better to also
consider kexec. I'm thinking below two approatches:
1. use bootloader_type as below
#define LOADER_TYPE_KEXEC 0x0D
int is_kexec_boot()
{
if (bootloader_type == LOADER_TYPE_KEXEC)
return 1;
return 0;
}
2. 1) is specific to X86, if consider other futuer arch, maybe add a
kernel cmdline like kexecboot=X [X=0|1|2], 0:not kexec 1:kexec 2:kdump
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
