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

[Dave Young]

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.
> 
> 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