Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp310441img; Wed, 27 Mar 2019 23:44:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfmT3FrYkdgvFcgREFDtVM5Tqz9OCjiUuOH/OooN+d69WUuQJn7Crg+NKXeiS8DiYF2gzn X-Received: by 2002:a17:902:7e49:: with SMTP id a9mr38750723pln.303.1553755484792; Wed, 27 Mar 2019 23:44:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553755484; cv=none; d=google.com; s=arc-20160816; b=mqje9sCAxu0nQuqCmwi9LfKOPSXRpp0kv2u8rNWA4Zb7hpzdccKyEvfaQWHsrfJPv2 Dvuj/1Rp/yh6pXgukAgmfw4j5v20amIcO9enX/jbDiAeW3y6isSvlDDSgp0C0U/0GDTT G7i8E1MUL5MkhPUkGPsbZY9hH3LE8pBKdNiQKjYZjZqV8+INM8dDNoKhD+l/u7uF7QfJ HO/z0eO/MX2DfAPvmA40+/l2EXH5Dhs4OUpHYvfgs2o1u0l3qI7A6lGzB33E/F3uxSHB 0DCCVWQ32zwd6WxJC7jXY+2VZk8SXqzxu0tqgbZpzppCyvsn1gWqPHT5B9zeEWaDDO4m 69Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=TLxIFG2ckMwR2Q9dtKy0Cls2rw2KXti6iFunaCSQRSo=; b=0JEa+JdrsUaThaP+NcEfQny5+3ZXJ3sagMue5Y5+9MDg0TRBOPbCBtlIV53jMeM2D1 2YKwPWLluHZPj5s+a7S97O+XLdLIbRzKKIWzAwRM33bSlILlABg2IG4P6g7iPf93u2L7 n3p8YHjVnQtjj/vDlO7DuOIoPmN05k5BFuHqRhyo6ModFiHXIK/XlpXzcN3KOXv/clem h6yUdeG7moWbr1VBQP2QS3F828RWonDz7LFkeBkU7cculNDEzPd65RIB8iz3b87Iy84V WTd80LHh5Zz6LFwgzN8Bf8lIg6Ij3QpFlRFR4sxalj6d6//Fcrmwxwnhmf1Vq7O9PgNK FmMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k9si11999468pgc.156.2019.03.27.23.44.29; Wed, 27 Mar 2019 23:44:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726185AbfC1Gns (ORCPT + 99 others); Thu, 28 Mar 2019 02:43:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725853AbfC1Gns (ORCPT ); Thu, 28 Mar 2019 02:43:48 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F9FF330244; Thu, 28 Mar 2019 06:43:48 +0000 (UTC) Received: from localhost (ovpn-12-23.pek2.redhat.com [10.72.12.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 441E41001E69; Thu, 28 Mar 2019 06:43:45 +0000 (UTC) Date: Thu, 28 Mar 2019 14:43:43 +0800 From: "bhe@redhat.com" To: Junichi Nomura Cc: Borislav Petkov , Dave Young , "fanc.fnst@cn.fujitsu.com" , "kasong@redhat.com" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] x86/boot: Use EFI setup data if provided Message-ID: <20190328064343.GA1877@MiWiFi-R3L-srv> References: <51D9A7D1-49BF-4679-B102-0FC5AC300C9F@alien8.de> <20190325101509.GA13160@dhcp-128-65.nay.redhat.com> <701c8e69-e1d4-c653-1d87-1c41789d3d54@ce.jp.nec.com> <20190325120149.GI12016@zn.tnic> <20190325122302.GC13160@dhcp-128-65.nay.redhat.com> <20190325123229.GL12016@zn.tnic> <20190325231000.GA9184@jeru.linux.bs1.fc.nec.co.jp> <20190326135714.GG1867@zn.tnic> <20190327014852.GA3659@MiWiFi-R3L-srv> <73322ba9-e436-68db-7863-afd31607d969@ce.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73322ba9-e436-68db-7863-afd31607d969@ce.jp.nec.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 28 Mar 2019 06:43:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/28/19 at 04:17am, Junichi Nomura wrote: > On 2019/03/27 10:48, bhe@redhat.com wrote: > >>> So efi_get_rsdp_addr() needs to be refactored in such a way so that at > >>> least the loop towards the end gets carved out into a separate function > >>> - __efi_get_rsdp_addr() or so - which gets config_tables, nr_tables and > >>> size as arguments and finds the RSDP address in the kexec-ed kernel. > >> > >> You need to carve out the loop at the end and make it into a separate > >> __efi_get_rsdp_addr() function which gets the physical or the virtual > >> address. > > > > I guess Boris is suggesting code like below. Please correct me if I am > > wrong. > > > > static acpi_physical_address _efi_get_rsdp_addr(efi_config_table tbl, ...) > > { > > /* Get EFI tables from systab. */ > > for (i = 0; i < nr_tables; i++) { > > ... > > } > > return rsdp_addr; > > } > > > > static acpi_physical_address efi_get_rsdp_addr(void) > > { > > ... > > /* Get systab from boot params. */ > > ... > > /* Handle EFI bitness properly */ > > ... > > return _efi_get_rsdp_addr(); > > } > > > > > > static acpi_physical_address kexec_get_rsdp_addr(void) > > { > > if (!is_kexec_booted) > > return 0; > > > > efi_get_setup_data_addr(); > > ... > > /* Handle EFI bitness properly */ > > ... > > return _efi_get_rsdp_addr(); > > } > > I still don't get it... We still need systab for kexec case as well > to get nr_tables. Don't we? Yes, simpler. As Dave replied in another mail, efi/kexec is only added for x86_64. See how it does in setup_linux_system_parameters() of kexec_tools utility, and we only have bzImage64 handling in kernel for kexec_file loading, see prepare_add_efi_setup_data(). You may only need to get kexec ei_info to use directly. > > > acpi_physical_address get_rsdp_addr(void) > > { > > acpi_physical_address pa; > > > > pa = get_acpi_rsdp(); > > > > if (!pa) > > pa = boot_params->acpi_rsdp_addr; > > > > > > /** > > /*I think here we should check if it's kexec booted firstly. > > * Skip it if not kexec. this can avoid the wrong kexec virt > > * addr parsing./ > > if (!pa) > > pa = kexec_get_rdsp_addr(); <--- new function > > > > if (!pa) > > pa = efi_get_rsdp_addr(); > > > > Shouldn't t efi_get_rsdp_addr() check "is_kexec_booted" and exit > early so that it never tries to use virtual config_tables pointer > if for some unknown resason kexec_get_rsdp_addr() failed. Well, you can just call your efi_get_setup_data_addr() in kexec_get_rdsp_addr(), if succeed, go ahead to read ei_info and call _efi_get_rsdp_addr(). If failed, return to try efi_get_rsdp_addr(). > > Currently I check "is_kexec_booted" by subset of efi_get_setup_data_addr(). > Do you know a simpler way to check "is_kexec_booted"? There seems to be no another way to check, I think your way is good. Tryint to get it in kexec_get_rdsp_addr() earlier, you don't need to judge specifically in efi_get_rsdp_addr() again. > > > if (!pa) > > pa = bios_get_rsdp_addr(); > > > > return pa; > > } > > -- > Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.