Date:	Fri, 13 Sep 2013 15:12:40 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Vivek Goyal <vgoyal@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, kexec@...ts.infradead.org,
	akpm@...ux-foundation.org, zohar@...ux.vnet.ibm.com,
	d.kasatkin@...sung.com, ebiederm@...ssion.com,
	matthew.garrett@...ula.com
Subject: Re: [PATCH 15/16] bootparam: Pass acpi_rsdp pointer in bootparam

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists