From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68284C433E0 for ; Sun, 28 Feb 2021 18:10:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11B4664E54 for ; Sun, 28 Feb 2021 18:10:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11B4664E54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=KuJE2mSMu3uuZWMwDf9BsUlW8M8U0CVAyil0Ap6F5Ms=; b=iFXxaPkkOPeHLDpeS8cHH0QQl v2uo8Uwc5nKQrfsENjf+7xvc41LDSoU93mZTpnvBYk3LvaxcCq3EmvaUVY2MFmevI9W7q9aXYyVsU M4iB4V/sm5pwVpl1Y97QfetUEcVZ8ymNpOQ0J+7SN0wBltp08QNKpVVOjt47xkkN/zKWj6vH8dIyu y9yx9pSn5efBAj53NWMjxbDZw02QcI5pkcuaumzeflOzrHvM9/RfclTnUYxindlQq4EivuUKuxXkA k+vfN6EPYz2A1xua+C+QH6rmlgxqzthhW6u3oFMga8lXdIn5aBYc1ZZKMpJ5RiYZnDkYA5IY9uhK9 M9Vw41SGg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGQV9-0003sE-0R; Sun, 28 Feb 2021 18:09:07 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGQV6-0003ra-UC for linux-arm-kernel@lists.infradead.org; Sun, 28 Feb 2021 18:09:05 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11SI4TRM141005; Sun, 28 Feb 2021 13:08:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=pp1; bh=4bb935c/UZyEQhCai159ASVF1c2deNbr/2p5TWhmbJc=; b=YE21XdX46aBFkYH+sul7Ck3aEc2l0vgnZmGUCKfZQ2CaRwZPVfLVpv+vwEFSVj1Ek63z p+y7Y8aCs0OIbCj/QQekJTEBPA15o9aCKHcGOsYDk4N045E/wAuxVQlwzOpS5nFWdVbi CKgWrKtRfQ/aVZgoXfZSdCbWjlyT2BEpSgFe0UMVIvX2soiyB5K6hOjEsZGMAozTn0fl BaXW5MdQaKY60GGZBPit4bv5p23ZiCc8qgCHswTqKg1/pfZjFEZ02/WJkLVvjkDj1LDi 1UxXog3LZMHNPzICgDfUacOFhNPsnJ0jlJLVUFb4Xim3uFTliNYOVn3cTaNVdMWWGqNY IA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:41 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 11SI4iI1141354; Sun, 28 Feb 2021 13:08:40 -0500 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9u7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:40 -0500 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 11SI2b3G020519; Sun, 28 Feb 2021 18:08:38 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03ams.nl.ibm.com with ESMTP id 36ydq893ed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 18:08:37 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 11SI8Zsh31588766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Feb 2021 18:08:35 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C302BAE045; Sun, 28 Feb 2021 18:08:35 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A0D7AE051; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.18.192]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Date: Sun, 28 Feb 2021 20:08:31 +0200 From: Mike Rapoport To: George Kennedy Subject: Re: [PATCH] mm, kasan: don't poison boot memory Message-ID: References: <9b7251d1-7b90-db4f-fa5e-80165e1cbb4b@oracle.com> <20210225085300.GB1854360@linux.ibm.com> <9973d0e2-e28b-3f8a-5f5d-9d142080d141@oracle.com> <20210225145700.GC1854360@linux.ibm.com> <20210225160706.GD1854360@linux.ibm.com> <6000e7fd-bf8b-b9b0-066d-23661da8a51d@oracle.com> <20210226111730.GL1854360@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-28_07:2021-02-26, 2021-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102280156 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210228_130905_132840_A7D477A0 X-CRM114-Status: GOOD ( 36.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Marco Elver , Dhaval Giani , David Hildenbrand , Andrey Konovalov , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Christoph Hellwig , Andrey Ryabinin , Alexander Potapenko , Evgenii Stepanov , Catalin Marinas , Konrad Rzeszutek Wilk , Andrew Morton , Vincenzo Frascino , Peter Collingbourne , Linux Memory Management List , Dmitry Vyukov Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote: > On 2/26/2021 6:17 AM, Mike Rapoport wrote: > > Hi George, > > = > > On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote: > > > = > > > Not sure if it's the right thing to do, but added > > > "acpi_tb_find_table_address()" to return the physical address of a ta= ble to > > > use with memblock_reserve(). > > > = > > > virt_to_phys(table) does not seem to return the physical address for = the > > > iBFT table (it would be nice if struct acpi_table_header also had a > > > "address" element for the physical address of the table). > > > > virt_to_phys() does not work that early because then it is mapped with > > early_memremap() which uses different virtual to physical scheme. > > = > > I'd say that acpi_tb_find_table_address() makes sense if we'd like to > > reserve ACPI tables outside of drivers/acpi. > > = > > But probably we should simply reserve all the tables during > > acpi_table_init() so that any table that firmware put in the normal mem= ory > > will be surely reserved. > > > Ran 10 successful boots with the above without failure. > > That's good news indeed :) > = > Wondering if we could do something like this instead (trying to keep chan= ges > minimal). Just do the memblock_reserve() for all the standard tables. I think something like this should work, but I'm not an ACPI expert to say if this the best way to reserve the tables. = > diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinsta= l.c > index 0bb15ad..830f82c 100644 > --- a/drivers/acpi/acpica/tbinstal.c > +++ b/drivers/acpi/acpica/tbinstal.c > @@ -7,6 +7,7 @@ > =A0 * > *************************************************************************= ****/ > = > +#include > =A0#include > =A0#include "accommon.h" > =A0#include "actables.h" > @@ -14,6 +15,23 @@ > =A0#define _COMPONENT=A0=A0=A0=A0=A0=A0=A0=A0=A0 ACPI_TABLES > =A0ACPI_MODULE_NAME("tbinstal") > = > +void > +acpi_tb_reserve_standard_table(acpi_physical_address address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 struct acpi_table_header *header) > +{ > +=A0=A0=A0 struct acpi_table_header local_header; > + > +=A0=A0=A0 if ((ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS)) || > +=A0=A0=A0 =A0=A0=A0 (ACPI_VALIDATE_RSDP_SIG(header->signature))) { > +=A0=A0=A0 =A0=A0=A0 return; > +=A0=A0=A0 } > +=A0=A0=A0 /* Standard ACPI table with full common header */ > + > +=A0=A0=A0 memcpy(&local_header, header, sizeof(struct acpi_table_header)= ); > + > +=A0=A0=A0 memblock_reserve(address, PAGE_ALIGN(local_header.length)); > +} > + > =A0/*********************************************************************= ********** > =A0 * > =A0 * FUNCTION:=A0=A0=A0 acpi_tb_install_table_with_override > @@ -58,6 +76,9 @@ > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_desc= ->flags, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_desc= ->pointer); > = > +=A0=A0=A0 acpi_tb_reserve_standard_table(new_table_desc->address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->pointer); > + > =A0=A0=A0=A0 acpi_tb_print_table_header(new_table_desc->address, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->pointer= ); > = > There should be no harm in doing the memblock_reserve() for all the stand= ard > tables, right? It should be ok to memblock_reserve() all the tables very early as long as we don't run out of static entries in memblock.reserved. We just need to make sure the tables are reserved before memblock allocations are possible, so we'd still need to move acpi_table_init() in x86::setup_arch() before e820__memblock_setup(). Not sure how early ACPI is initialized on arm64. = > Ran 10 boots with the above without failure. > = > George -- = Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6DBBC433DB for ; Sun, 28 Feb 2021 18:09:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3307364E74 for ; Sun, 28 Feb 2021 18:09:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3307364E74 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 523A28D0025; Sun, 28 Feb 2021 13:09:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D3F98D0019; Sun, 28 Feb 2021 13:09:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B428D0025; Sun, 28 Feb 2021 13:09:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 22B5F8D0019 for ; Sun, 28 Feb 2021 13:09:04 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D21F3824999B for ; Sun, 28 Feb 2021 18:09:03 +0000 (UTC) X-FDA: 77868462966.12.2178608 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf09.hostedemail.com (Postfix) with ESMTP id 79D29600249E for ; Sun, 28 Feb 2021 18:08:58 +0000 (UTC) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11SI4TRM141005; Sun, 28 Feb 2021 13:08:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=pp1; bh=4bb935c/UZyEQhCai159ASVF1c2deNbr/2p5TWhmbJc=; b=YE21XdX46aBFkYH+sul7Ck3aEc2l0vgnZmGUCKfZQ2CaRwZPVfLVpv+vwEFSVj1Ek63z p+y7Y8aCs0OIbCj/QQekJTEBPA15o9aCKHcGOsYDk4N045E/wAuxVQlwzOpS5nFWdVbi CKgWrKtRfQ/aVZgoXfZSdCbWjlyT2BEpSgFe0UMVIvX2soiyB5K6hOjEsZGMAozTn0fl BaXW5MdQaKY60GGZBPit4bv5p23ZiCc8qgCHswTqKg1/pfZjFEZ02/WJkLVvjkDj1LDi 1UxXog3LZMHNPzICgDfUacOFhNPsnJ0jlJLVUFb4Xim3uFTliNYOVn3cTaNVdMWWGqNY IA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:41 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 11SI4iI1141354; Sun, 28 Feb 2021 13:08:40 -0500 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9u7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:40 -0500 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 11SI2b3G020519; Sun, 28 Feb 2021 18:08:38 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03ams.nl.ibm.com with ESMTP id 36ydq893ed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 18:08:37 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 11SI8Zsh31588766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Feb 2021 18:08:35 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C302BAE045; Sun, 28 Feb 2021 18:08:35 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A0D7AE051; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.18.192]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Date: Sun, 28 Feb 2021 20:08:31 +0200 From: Mike Rapoport To: George Kennedy Cc: David Hildenbrand , Andrey Konovalov , Andrew Morton , Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Konrad Rzeszutek Wilk , Will Deacon , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , Christoph Hellwig , kasan-dev , Linux ARM , Linux Memory Management List , LKML , Dhaval Giani Subject: Re: [PATCH] mm, kasan: don't poison boot memory Message-ID: References: <9b7251d1-7b90-db4f-fa5e-80165e1cbb4b@oracle.com> <20210225085300.GB1854360@linux.ibm.com> <9973d0e2-e28b-3f8a-5f5d-9d142080d141@oracle.com> <20210225145700.GC1854360@linux.ibm.com> <20210225160706.GD1854360@linux.ibm.com> <6000e7fd-bf8b-b9b0-066d-23661da8a51d@oracle.com> <20210226111730.GL1854360@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761 definitions=2021-02-28_07:2021-02-26,2021-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102280156 X-Stat-Signature: t5a6ctzd8ggcmsip3hc791r59cqjk5d1 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 79D29600249E Received-SPF: none (linux.ibm.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mx0a-001b2d01.pphosted.com; client-ip=148.163.156.1 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614535738-719371 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote: > On 2/26/2021 6:17 AM, Mike Rapoport wrote: > > Hi George, > >=20 > > On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote: > > >=20 > > > Not sure if it's the right thing to do, but added > > > "acpi_tb_find_table_address()" to return the physical address of a = table to > > > use with memblock_reserve(). > > >=20 > > > virt_to_phys(table) does not seem to return the physical address fo= r the > > > iBFT table (it would be nice if struct acpi_table_header also had a > > > "address" element for the physical address of the table). > > > > virt_to_phys() does not work that early because then it is mapped wit= h > > early_memremap() which uses different virtual to physical scheme. > >=20 > > I'd say that acpi_tb_find_table_address() makes sense if we'd like to > > reserve ACPI tables outside of drivers/acpi. > >=20 > > But probably we should simply reserve all the tables during > > acpi_table_init() so that any table that firmware put in the normal m= emory > > will be surely reserved. > > > Ran 10 successful boots with the above without failure. > > That's good news indeed :) >=20 > Wondering if we could do something like this instead (trying to keep ch= anges > minimal). Just do the memblock_reserve() for all the standard tables. I think something like this should work, but I'm not an ACPI expert to sa= y if this the best way to reserve the tables. =20 > diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbins= tal.c > index 0bb15ad..830f82c 100644 > --- a/drivers/acpi/acpica/tbinstal.c > +++ b/drivers/acpi/acpica/tbinstal.c > @@ -7,6 +7,7 @@ > =A0 * > ***********************************************************************= ******/ >=20 > +#include > =A0#include > =A0#include "accommon.h" > =A0#include "actables.h" > @@ -14,6 +15,23 @@ > =A0#define _COMPONENT=A0=A0=A0=A0=A0=A0=A0=A0=A0 ACPI_TABLES > =A0ACPI_MODULE_NAME("tbinstal") >=20 > +void > +acpi_tb_reserve_standard_table(acpi_physical_address address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 struct acpi_table_header *header) > +{ > +=A0=A0=A0 struct acpi_table_header local_header; > + > +=A0=A0=A0 if ((ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS))= || > +=A0=A0=A0 =A0=A0=A0 (ACPI_VALIDATE_RSDP_SIG(header->signature))) { > +=A0=A0=A0 =A0=A0=A0 return; > +=A0=A0=A0 } > +=A0=A0=A0 /* Standard ACPI table with full common header */ > + > +=A0=A0=A0 memcpy(&local_header, header, sizeof(struct acpi_table_heade= r)); > + > +=A0=A0=A0 memblock_reserve(address, PAGE_ALIGN(local_header.length)); > +} > + > =A0/*******************************************************************= ************ > =A0 * > =A0 * FUNCTION:=A0=A0=A0 acpi_tb_install_table_with_override > @@ -58,6 +76,9 @@ > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_de= sc->flags, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_de= sc->pointer); >=20 > +=A0=A0=A0 acpi_tb_reserve_standard_table(new_table_desc->address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->pointer= ); > + > =A0=A0=A0=A0 acpi_tb_print_table_header(new_table_desc->address, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->point= er); >=20 > There should be no harm in doing the memblock_reserve() for all the sta= ndard > tables, right? It should be ok to memblock_reserve() all the tables very early as long a= s we don't run out of static entries in memblock.reserved. We just need to make sure the tables are reserved before memblock allocations are possible, so we'd still need to move acpi_table_init() in x86::setup_arch() before e820__memblock_setup(). Not sure how early ACPI is initialized on arm64. =20 > Ran 10 boots with the above without failure. >=20 > George --=20 Sincerely yours, Mike.