[PATCH] x86: do not enable efi boot for sgi uv machine

[Borislav Petkov]

On Fri, May 23, 2014 at 09:47:08AM -0400, Dave Young wrote:
> Hi,
> 
> Vivek, replying with webmail, sorry for the formatting issue.
> 
> Another way is export the mapping scheme in sysfs. So if kernel boot
> with efi=old_map we can detect it as well. OTOH in future there's probably
> other quirk system.
> 
> So kexec-tools can switch to use old way if kernel use ioremap.
> 
> Adding Matt and Boris to cc, to see if they have idea.
> 
> Thanks
> Dave
> 
> ----- Original Message -----
> From: "Vivek Goyal" <vgoyal at redhat.com>
> To: "Dave Young" <dyoung at redhat.com>
> Cc: horms at verge.net.au, kexec at lists.infradead.org
> Sent: Friday, May 23, 2014 9:28:34 PM
> Subject: Re: [PATCH] x86: do not enable efi boot for sgi uv machine
> 
> On Fri, May 23, 2014 at 06:14:55PM +0800, Dave Young wrote:
> > 
> > kexec/kdump uefi support depends on the 1:1 mapping scheme
> > in 3.14 kernel but SGI reported that 1:1 mapping does not work on
> > their UV system. thus there's below commit to switch back to
> > old ioremap way for sgi uv machines.
> > 
> > So for kexec-tools before we got the 1:1 mapping support on those
> > machines we should also use old way that means boot 2nd kernel
> > without uefi.

Well, we did find the bug in a combined debug session and SGI will be
issuing a fix soon. I don't know whether any quirk will be needed for
systems which don't have the fix - I guess that's something for SGI
people to decide. CCed and leaving in the rest for reference.

@Alex, Russ: this is about using kexec on UEFI boxes.

> > 
> > Tested on a uv1 machine.
> > 
> > Here is the kernel commit to quirk out SGI UV:
> > commit a5d90c923bcfb9632d998ed06e9569216ad695f3
> > Author: Borislav Petkov <bp at suse.de>
> > Date:   Tue Mar 4 17:02:17 2014 +0100
> > 
> >     x86/efi: Quirk out SGI UV
> >     
> >     Alex reported hitting the following BUG after the EFI 1:1 virtual
> >     mapping work was merged,
> >     
> >      kernel BUG at arch/x86/mm/init_64.c:351!
> >      invalid opcode: 0000 [#1] SMP
> >      Call Trace:
> >       [<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15
> >       [<ffffffff818a5e20>] uv_system_init+0x22b/0x124b
> >       [<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d
> >       [<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7
> >       [<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd
> >       [<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7
> >       [<ffffffff8153d955>] ? printk+0x72/0x74
> >       [<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6
> >       [<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb
> >       [<ffffffff81535530>] ? rest_init+0x74/0x74
> >       [<ffffffff81535539>] kernel_init+0x9/0xff
> >       [<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0
> >       [<ffffffff81535530>] ? rest_init+0x74/0x74
> >     
> >     Getting this thing to work with the new mapping scheme would need more
> >     work, so automatically switch to the old memmap layout for SGI UV.
> > 
> > 
> > Signed-off-by: Dave Young <dyoung at redhat.com>
> > ---
> >  kexec/arch/i386/x86-linux-setup.c |   15 ++++++++++++++-
> >  1 file changed, 14 insertions(+), 1 deletion(-)
> > 
> > --- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
> > +++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
> > @@ -817,12 +817,25 @@ out:
> >  	return;
> >  }
> >  
> > +static int is_sgi_uv_machine(void)
> > +{
> > +	DIR *sgi_dir;
> > +
> > +	sgi_dir = opendir("/sys/firmware/sgi_uv");
> > +	if (sgi_dir) {
> > +		closedir(sgi_dir);
> > +		return 1;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  void setup_linux_system_parameters(struct kexec_info *info,
> >  				   struct x86_linux_param_header *real_mode)
> >  {
> >  	/* get subarch from running kernel */
> >  	setup_subarch(real_mode);
> > -	if (bzImage_support_efi_boot)
> > +	if (bzImage_support_efi_boot && !is_sgi_uv_machine())
> >  		setup_efi_info(info, real_mode);
> 
> Hi Dave,
> 
> I think instead of always falling back to old "noefi" method for SGI UV
> machines, we should probably provide a config option to override default
> behavior. Something like "--nouefi". And let user/distributions decide
> in what cases to use that parameter.
> 
> Reason being, that at some point of time this limitation will be fixed.
> And at that point of time if we modify kexec-tools, then it will stop
> working with older kernels. And then same issue will arise that
> kexec-tools is not working with older kernels.
> 
> If we just provide a way to override default, then distributions in their
> scripts should know what kernels work what way and automatically use or
> not use option accordingly.
> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--