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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5906FEB64DA for ; Sat, 8 Jul 2023 12:03:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbjGHMDO (ORCPT ); Sat, 8 Jul 2023 08:03:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbjGHMDN (ORCPT ); Sat, 8 Jul 2023 08:03:13 -0400 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E728B8 for ; Sat, 8 Jul 2023 05:03:12 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-52cb8e5e9f5so1855509a12.0 for ; Sat, 08 Jul 2023 05:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1688817792; x=1691409792; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=pmW+hS9M/nuHr1o+UJdiTC8iEB1m1jPftzrxBZrYbqo=; b=Cgx32CzVjbgsu10mxr5sIU/3c+N6ldXoy6BzzWOBMTIGC9t2Mg4tZtwqFYZ2z7JZpL EeGF6w355DMuzE85qokbs18VK9Gvqqm2Qorj24pqu8E84cO2bG2p11UShZMr3wpsCF0k 1WR8q8vC68MrUMmUOdtnQh2Hsi+dYU7MJIOLJA8DgGA4JjGPMFVCeKsBkySaQKPLKwsL MKzDPTuDc5dgc4qLxIxAm89ois4f+C3c+M5Qb4NoYh29nDvjF0Dn8AOBYIUSm07sxQ/j RESBR25MqbVD+tva7z63hUlEXq0GZAoFS8HgWibdOnNJp2FYh6N2Fqlk4HC+8qaTcGw5 nByg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688817792; x=1691409792; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pmW+hS9M/nuHr1o+UJdiTC8iEB1m1jPftzrxBZrYbqo=; b=hpmU4aGh+IOpq31eIsg+Yx0J2+UjBNC9xaFLXG4NpUCkFvD1YJWepod58X6Tb6MNnG GeMZ47lCXNfSsQX5qIRe6kJjhM/NTec2yAHcGXfj390eE8WCkvue3xPZlOIT0sCC5o4d 7DyfXAcRg9gVVbEff0o3fC4iV8He6K6OOGi2T+2Qk+X0NLnGmA/x1zZzjxr4HjENbd6s yBukfHvoz7G81Ewr6ZjUwnTHaXjWtrKRWIQxo2vd+vAxIoDMJQEyunFrXkhlXyhGB0Me ku0CBYT+dFcafJEOI/UId7XVAuozQvOivocshlVDRvGCDAR+5Ky4/qChWTJWSewi/0vr emTA== X-Gm-Message-State: ABy/qLYPgI7cv2IKxpI7KgM7LEn6ZcaMo02A1mI4Io9540ia4Af79wFm is6ptKJ0WkObyTA69/xzL3ekhQ== X-Google-Smtp-Source: APBJJlFRc9kwODiRcw6uSg+iVQe/4Kk5wsuH2F52nIAIw5ZGfOzMcKcldwdMs7dd4MdwFE3W7lBf7w== X-Received: by 2002:a17:90b:357:b0:262:ec04:4ff7 with SMTP id fh23-20020a17090b035700b00262ec044ff7mr16375949pjb.16.1688817791704; Sat, 08 Jul 2023 05:03:11 -0700 (PDT) Received: from sunil-laptop ([106.51.184.72]) by smtp.gmail.com with ESMTPSA id v2-20020a17090a960200b00262e9fbd5fbsm2932101pjo.32.2023.07.08.05.03.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Jul 2023 05:03:11 -0700 (PDT) Date: Sat, 8 Jul 2023 17:33:01 +0530 From: Sunil V L To: Ard Biesheuvel Cc: Dong Wei , Conor Dooley , =?utf-8?B?6JGb5aOr5bu6?= , Conor Dooley , ron minnich , Palmer Dabbelt , "cuiyunhui@bytedance.com" , "jrtc27@jrtc27.com" , "kernel@esmil.dk" , Paul Walmsley , "aou@eecs.berkeley.edu" , "linux-riscv@lists.infradead.org" , Mark Rutland , "lpieralisi@kernel.org" , "rafael@kernel.org" , "lenb@kernel.org" , "jdelvare@suse.com" , "yc.hung@mediatek.com" , "angelogioacchino.delregno@collabora.com" , "allen-kh.cheng@mediatek.com" , "pierre-louis.bossart@linux.intel.com" , "tinghan.shen@mediatek.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "weidong.wd@bytedance.com" Subject: Re: [External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI Message-ID: References: <20230707-attach-conjuror-306d967347ce@wendy> <20230707-gargle-enjoyable-f9f7f87fc7ea@spud> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Sat, Jul 08, 2023 at 10:45:27AM +0200, Ard Biesheuvel wrote: > On Fri, 7 Jul 2023 at 18:21, Dong Wei wrote: > > > > On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table. > > > > > > > > So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue… > > > > Hello Dong, > > This fixes the RSDP issue perhaps, but that is not the only problem. I > have mentioned this many times already, but let me mention it again > for completeness: > > ACPI does not have a memory map, and ARM is much more finicky about > mapping memory regions with the right attributes, given that uncached > accesses don't snoop the caches like they do on x86. This means it is > essential that memory mappings constructed from AML code (which > doesn't provide any context pertaining to the memory type either) are > created with the right memory type. > > Currently, the Linux/arm64 glue code for the ACPI core > cross-references every memory mapping created from a SystemMemory > OpRegion by AML code against the EFI memory map, and uses the EFI > memory type and attributes to infer the memory type to program into > the page tables. So simply providing the RSDP is *not* sufficient: on > arm64, more work is needed and currently, booting ACPI without a EFI > memory map results in SystemMemory OpRegions not working at all. > > Of course, we might be able to work around that by providing a > 'coreboot' memory map for doing ACPI on arm64, but that results in > more fragmentation and an inflated validation matrix, which puts the > burden on the Linux subsystem maintainers to make sure that all these > different combinations remain supported. > > AIUI, this memory type issue does not exist for RISC-V today, but I'd > suggest to the RISC-V maintainers to take a careful look at arm64's > acpi_os_ioremap() implementation and decide whether or not RISC-V > needs similar logic. Currently, basic ACPI support is merged for RISC-V. Still many features including external interrupt controller support are WIP. Enhancing the acpi_os_ioremap() similar to arm64 version is in plan for next series. Bjorn had also provided this feedback. https://lore.kernel.org/lkml/87leidtvn9.fsf@all.your.base.are.belong.to.us/ So, the issue will be applicable to RISC-V also even if the implementation may differ slightly.