From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-3816309-1516882003-2-79680583285071705 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='com', MailFrom='org' X-Spam-charsets: plain='utf-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516882003; b=j+KoeG6azFi94cAlV8MQD5BwQ/d1KXmoy5WEbgs8niYw4Dx y0MMhml24KPgD6iUoymOYHXP1yOPhRzt+3KWC1o1hVcNzLXZiGp6DOjU47CZ6+Tn N9UXeyObAii0+smy6QqtlflGt4jeitJxMIASphnckKWCwrZOMYqd+HJ+ZR/BETur GNIB86AfRPkD+ADStWNhV5xZBYRYhJ2cOvSbOfuxd1Xs2Ai/bfY+Eqb1cCm2wmPR Yg8ic47/R6FoLhMVf6ApeOm0mnnd5pAfM/enejjECpOxSbVtgRCqKmqMZcw77AoI TwkKYuVQsh8jepA3PSj/KXC1CcdoNCjXt758LeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1516882003; bh=WjDX0AlOP7hR+fXh/Crh2qeIc9MzJ9Qwp0I73DotX0Q=; b=h VHNIteixKzmPcrG71SUWYpu+eG86ZEz0jA6dlkkKUY2y4wTn4y9yzNIbkwbLetIY sRkOIzltGn9b9DcTzitPriu38zsin5MPz8X4qCHpaYrkr8wqf4yQ3cNPUdG6iT8D 5vUIePYdfnmR3hEgI3o9l4XcfV5oeBZGe6VaJcLBfyBaf6nj7VY1LdmLcpQaHQEV ZAErF2JxMm6FzEKCa+IdgKuiyCQGIGuComFJ+iOEg53d60BycjK03hLX3c3eSCVZ sGDm/TDP26GKOZpTndO5CeoFS9q3sewtDbnya9k9sb6IjwnNzHwRrebhGKIDLRh0 me5j9dNasxDH00uB6yjWg== ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=suse.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=suse.com header.result=pass header_is_org_domain=yes Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=suse.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=suse.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751821AbeAYMGa (ORCPT ); Thu, 25 Jan 2018 07:06:30 -0500 Received: from mx2.suse.de ([195.135.220.15]:38611 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751184AbeAYMG3 (ORCPT ); Thu, 25 Jan 2018 07:06:29 -0500 Subject: Re: [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests To: Greg KH Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, lenb@kernel.org, rafael.j.wysocki@intel.com, mingo@redhat.com, boris.ostrovsky@oracle.com, stable@vger.kernel.org References: <20180125100454.23203-1-jgross@suse.com> <20180125100454.23203-3-jgross@suse.com> <20180125103719.GA16777@kroah.com> <033717a8-f53a-3379-1e05-58b3d2bed24b@suse.com> <20180125110051.GA31911@kroah.com> From: Juergen Gross Message-ID: Date: Thu, 25 Jan 2018 13:06:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180125110051.GA31911@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 25/01/18 12:00, Greg KH wrote: > On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote: >> On 25/01/18 11:37, Greg KH wrote: >>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote: >>>> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate >>>> the address of the RSDP table given to the kernel via Xen start info. >>>> >>>> This makes the kernel boot again in PVH mode after on recent Xen the >>>> RSDP was moved to higher addresses. So up to that change it was pure >>>> luck that the legacy method to locate the RSDP was working when >>>> running as PVH mode. >>>> >>>> Cc: # 4.11 >>>> Signed-off-by: Juergen Gross >>>> --- >>>> arch/x86/xen/enlighten_pvh.c | 15 ++++++++++++--- >>>> 1 file changed, 12 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c >>>> index 436c4f003e17..9a5c3a7fe673 100644 >>>> --- a/arch/x86/xen/enlighten_pvh.c >>>> +++ b/arch/x86/xen/enlighten_pvh.c >>>> @@ -16,15 +16,24 @@ >>>> /* >>>> * PVH variables. >>>> * >>>> - * xen_pvh and pvh_bootparams need to live in data segment since they >>>> - * are used after startup_{32|64}, which clear .bss, are invoked. >>>> + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data segment >>>> + * since they are used after startup_{32|64}, which clear .bss, are invoked. >>>> */ >>>> bool xen_pvh __attribute__((section(".data"))) = 0; >>>> struct boot_params pvh_bootparams __attribute__((section(".data"))); >>>> +struct hvm_start_info pvh_start_info __attribute__((section(".data"))); >>>> >>>> -struct hvm_start_info pvh_start_info; >>>> unsigned int pvh_start_info_sz = sizeof(pvh_start_info); >>>> >>>> +acpi_physical_address acpi_arch_get_root_pointer(void) >>>> +{ >>>> + if (xen_pvh) >>>> + return pvh_start_info.rsdp_paddr; >>>> + >>>> + return 0; >>>> +} >>>> +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer); >>> >>> Why does this have to be an exported symbol? Does this code get built >>> as a module and will the linker somehow go and rewrite the previous call >>> places with this one if it gets loaded? >> >> With being called by drivers/acpi/... I just wanted to make sure it is >> working properly even in case the acpi code is built as a module. > > I didn't think the core ACPI code can be built as a module, have you > tried that? No, but as the build wouldn't break whenever this is changed I wanted to make sure the symbol is found. If you feel strong about that I can remove the EXPORT_SYMBOL_GPL(). Juergen