On 10/29/13 at 11:05am, Dave Young wrote:
> On 10/28/13 at 06:53pm, Dave Young wrote:
> > On 10/28/13 at 10:51am, Matthew Garrett wrote:
> > > On Mon, Oct 28, 2013 at 06:45:32PM +0800, Dave Young wrote:
> > > > On 10/28/13 at 10:39am, Matthew Garrett wrote:
> > > > > On Mon, Oct 28, 2013 at 06:34:12PM +0800, Dave Young wrote:
> > > > > > On 10/28/13 at 10:12am, Matthew Garrett wrote:
> > > > > > > Right, but previously acpi_rsdp was passed automatically and now 
> > > > > > > it 
> > > > > > > won't be?
> > > > > > 
> > > > > > Yes, it was. I'm removing them in kexec-tools patches for efi 
> > > > > > runtime support.
> > > > > 
> > > > > If I upgrade kexec-tools and try to launch an old kernel, I now need 
> > > > > to 
> > > > > add an extra parameter?
> > > > 
> > > > Yes, it should work by passing the acpi_rsdp= via --append
> > > 
> > > Yes, that's my point. You're breaking old configurations by requiring 
> > > the user to pass an additional argument.
> > 
> > Hmm, I will do some test without this patch, if it works well it's not
> > harmful to drop this one.
> 
> Removing this patch does not work because in this series efi_info is passed 
> into
> 2nd kernel thus 2nd kernel will initilize efi but it does not have related 
> code
> to handle the converted talbe addresses and it will endter virtual mode 
> again. 
> 
> I will think about how to solve this problem.
> 

The only way what I can think out is introduce a flag in x86 setup header.
Will try this way, the userspace code will use old logic if the kernel is old.

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to