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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0D78BC00140 for ; Thu, 18 Aug 2022 09:40:26 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.389410.626296 (Exim 4.92) (envelope-from ) id 1oOc0Z-0003pb-Qg; Thu, 18 Aug 2022 09:40:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 389410.626296; Thu, 18 Aug 2022 09:40:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oOc0Z-0003pU-Ms; Thu, 18 Aug 2022 09:40:11 +0000 Received: by outflank-mailman (input) for mailman id 389410; Thu, 18 Aug 2022 09:40:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oOc0X-0003pO-Ol for xen-devel@lists.xenproject.org; Thu, 18 Aug 2022 09:40:09 +0000 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bf621e66-1ed9-11ed-bd2e-47488cf2e6aa; Thu, 18 Aug 2022 11:40:08 +0200 (CEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CF914B8102F; Thu, 18 Aug 2022 09:40:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67CA5C433D6; Thu, 18 Aug 2022 09:40:06 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oOc0S-003xEK-66; Thu, 18 Aug 2022 10:40:04 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bf621e66-1ed9-11ed-bd2e-47488cf2e6aa DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660815606; bh=ai7BSOjpcpre9tGP0w1yVZgucAkj3DS4uxlAm2blW3k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QJ9u6akj8unTH1uyQF5yePFroQxCSr1Kh104rNxBgFXSlMXvOjVDY2VsmMXcAoiQF I5ArzuxqJ4wGzKPTOg0TAgh/DfuezhyaIrS7knKf5C74b/4XNtDC092J85VKyaYJ/B dXuipFdvFYpV4QL/HzoyC/pLyqQ2HB+q4uWsfENzqC0RhNa4rcvBNky+huMV4SzAe9 KVNJm82byHlUwn8SyT1fXwRmV+t+NfLLG5HeqqhvFZSv81V0O8yhPoR71s/E8UiPI4 9YRzwE+WSrM9PupksMbn2xRAYu+EoSIjBJDWnwXwMsMU0sqgXLzyStXKtYYwnzqFmA 8QrrxMfxFa8yQ== Date: Thu, 18 Aug 2022 10:40:03 +0100 Message-ID: <87o7whx53g.wl-maz@kernel.org> From: Marc Zyngier To: Leo Yan Cc: Ard Biesheuvel , Jan Beulich , Bertrand Marquis , Rahul Singh , Peter Griffin , xen-devel , Julien Grall Subject: Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table In-Reply-To: References: <20220817105720.111618-1-leo.yan@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: leo.yan@linaro.org, ardb@kernel.org, jbeulich@suse.com, Bertrand.Marquis@arm.com, Rahul.Singh@arm.com, peter.griffin@linaro.org, xen-devel@lists.xenproject.org, jgrall@amazon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 18 Aug 2022 10:15:30 +0100, Leo Yan wrote: > > Hi Ard, > > On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote: > > [...] > > > > This header holds ACPI spec defined data structures. This one looks > > > to be a Linux one, and hence shouldn't be defined here. You use it > > > in a single CU only, so I see no reason to define it there. > > > > > > Furthermore - what if Linux decided to change their structure? Or > > > is there a guarantee that they won't? > > > > No, there is not. The memreserve table is an internal interface > > between the EFI stub loader and the Linux kernel proper. > > > > As I have argued many times before, booting the arm64 kernel in > > EFI/ACPI mode without going through the EFI stub violates the ACPI > > spec, and relies on interfaces that were not intended for public > > consumption. > > Let me ask a question but sorry it might be off topic. > > In the Linux kernel function: > > static int gic_reserve_range(phys_addr_t addr, unsigned long size) > { > if (efi_enabled(EFI_CONFIG_TABLES)) > return efi_mem_reserve_persistent(addr, size); > > return 0; > } > > We can see it will reserve persistent memory region for GIC pending > pages, so my question is if a platform is booting with DT binding > rather than ACPI table, how the primary kernel can reserve the pages > and pass the info to the secondary kernel? This is a false dichotomy. DT and UEFI are not exclusive, far from it. That's actually how most non-ACPI systems boot these days, and they are able to use kexec out of the box, using the EFI MEMRESERVE internal API. The real difference is between UEFI and non-UEFI. If you're allergic to it, you have two options: - you delegate the redistributor configuration to your bootloader, mark the corresponding memory as reserved in the DT from the bootloader, and you're done. A bunch of embedded systems do that, and are able to kexec. - you keep configuring the RDs from Linux, but you must then mark the regions as reserved in the DT that is passed to the secondary kernel. It requires some cooperation from the kexec userspace to parse /proc/iomem and insert the correct annotations in that DT. > Seems it's broken for kdump/kexec if kernel boots with using DT? You equate kexec to kdump, which is wrong. kdump does *not* reuse the memory from the previous kernel, and thus is immune to the RD table reallocation problem. You don't need anything for kdump, as you will use the RD tables as configured by the initial kernel. M. -- Without deviation from the norm, progress is not possible.