Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp6748727rdb; Tue, 2 Jan 2024 11:58:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IG2tB9WzYO2IT0+LZFLPSHipnfR9YGwsPIC2l892MeuyrBW7sfWjaEamVNGbo88gdkXW6Bf X-Received: by 2002:ae9:f40b:0:b0:781:5a43:de7e with SMTP id y11-20020ae9f40b000000b007815a43de7emr7910260qkl.51.1704225537489; Tue, 02 Jan 2024 11:58:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704225537; cv=none; d=google.com; s=arc-20160816; b=xJjF0OKPohoaOVLlwzy3u9mXyWJKtFHFiq+2cUGrE3UxlMI+ult2W4cDjByrJgFilp m+2txDPDN22xyKf01plqeT3nK9s9BEoQ/NJrdxur7523WAyA9QujOUpn0sKTrFA0dPK6 4wVRSItOzZasttDTNLtIrlKd7lYMqK8VM+3rbVST3opNw8RiTXgwAyKdmmnaJUGX/1EK Ke+DNwqqIJZ6/99xKb149md8/aQCoUWREzYROfASjsy8P8QPrICVLejs254bFMfNQ4qm 4LDiscUA/EP+6g8RQ12lCeMRzDjaITv2d4E49y4m72I3ri5YXv1NXQJz+QLpyLOoJ3iS njkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:subject:cc:to:from :date:dkim-signature:dkim-filter:message-id; bh=2UaDwV/oGm+Epqzq+iuoXLl1XYKs/iiOjHPSgAf4WNI=; fh=AS3R6UXbIyAF6jzq/MgRt2kJwpRsAl3CIwnHJsqk2U8=; b=V2RZTs8zSUWt/JaIKqV4EeLPiqDAM9g5rgKrcAFOFPUb7ydMZVULjRudqGGaVVymQJ 2HB536C3xyXW/z1+ur0zas5LYS86mevFuxPKndMu2jRqnDzzeH5mG3kjAmLt1rrBZm3I pzWHJrL4VB1CgQqxlBAAysAcAfgejr2TSa2oZdXi25vCE2OnlWw6T+PdFwQJmkq0js+o C+CyeX2vt4frlvQ2cuuHDencTNZQYrR6g/OFvdkmA3d5NQYMfpcYOdWDHnhOsOp3bVXJ FsVZJ0lyJzIH8/3NE/AH5Y/HbanlrSwV/sRVthX4fUxjsbs1wHGfOhCM4FsWGDCgVCT5 WrIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=sf+h60Ai; spf=pass (google.com: domain of linux-kernel+bounces-14788-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14788-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d7-20020a05620a136700b007819b6d71f9si9141674qkl.528.2024.01.02.11.58.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 11:58:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-14788-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=sf+h60Ai; spf=pass (google.com: domain of linux-kernel+bounces-14788-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14788-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Message-ID: <65946b01.050a0220.813ce.bfd4SMTPIN_ADDED_BROKEN@mx.google.com> X-Google-Original-Message-ID: <20240101033301.GA765@skinsburskii.> Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0B9391C229D3 for ; Tue, 2 Jan 2024 19:58:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1DB361640A; Tue, 2 Jan 2024 19:58:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="sf+h60Ai" X-Original-To: linux-kernel@vger.kernel.org Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2541F168D6; Tue, 2 Jan 2024 19:58:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: from skinsburskii. (c-73-239-240-195.hsd1.wa.comcast.net [73.239.240.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 2C6DD20B3CC1; Tue, 2 Jan 2024 11:58:13 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2C6DD20B3CC1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1704225493; bh=2UaDwV/oGm+Epqzq+iuoXLl1XYKs/iiOjHPSgAf4WNI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sf+h60AikfAoNDWIfOQf+gp/7n62YjqR91jk021dI0v+1a8M9a0OEjS7fQlNbGHtT ipeSl4ZqBYQjVEH3GZlLaVHYTWm8e6nUV0SEqCtKnbq135a3/00oHsQNKX3wd4Z7BD ICaDdMQVBMMzyyO3sadV/R66AVE4C1KSJe3ErDtk= Date: Sun, 31 Dec 2023 19:33:01 -0800 From: Stanislav Kinsburskii To: Alexander Graf Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, linux-doc@vger.kernel.org, x86@kernel.org, Eric Biederman , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Rob Herring , Steven Rostedt , Andrew Morton , Mark Rutland , Tom Lendacky , Ashish Kalra , James Gowans , arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com, Anthony Yznaga , Usama Arif , David Woodhouse , Benjamin Herrenschmidt Subject: Re: [PATCH v2 04/17] kexec: Add KHO parsing support References: <20231222193607.15474-1-graf@amazon.com> <20231222193607.15474-5-graf@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231222193607.15474-5-graf@amazon.com> On Fri, Dec 22, 2023 at 07:35:54PM +0000, Alexander Graf wrote: > +/** > + * kho_reserve_previous_mem - Adds all memory reservations into memblocks > + * and moves us out of the scratch only phase. Must be called after page tables > + * are initialized and memblock_allow_resize(). > + */ > +void __init kho_reserve_previous_mem(void) > +{ > + void *mem_virt = __va(mem_phys); > + int off, err; > + > + if (!handover_phys || !mem_phys) > + return; > + > + /* > + * We reached here because we are running inside a working linear map > + * that allows us to resize memblocks dynamically. Use the chance and > + * populate the global fdt pointer > + */ > + fdt = __va(handover_phys); > + > + off = fdt_path_offset(fdt, "/"); > + if (off < 0) { > + fdt = NULL; > + return; > + } > + > + err = fdt_node_check_compatible(fdt, off, "kho-v1"); > + if (err) { > + pr_warn("KHO has invalid compatible, disabling."); It looks like KHO preserved regions won't be reserved in this case. Should KHO DT state be destroyed here to prevent KHO memory regions reuse upon rollback? > + > +void __init kho_populate(phys_addr_t handover_dt_phys, phys_addr_t scratch_phys, > + u64 scratch_len, phys_addr_t mem_cache_phys, > + u64 mem_cache_len) > +{ > + void *handover_dt; > + > + /* Determine the real size of the DT */ > + handover_dt = early_memremap(handover_dt_phys, sizeof(struct fdt_header)); > + if (!handover_dt) { > + pr_warn("setup: failed to memremap kexec FDT (0x%llx)\n", handover_dt_phys); > + return; > + } > + > + if (fdt_check_header(handover_dt)) { > + pr_warn("setup: kexec handover FDT is invalid (0x%llx)\n", handover_dt_phys); > + early_memunmap(handover_dt, PAGE_SIZE); > + return; > + } > + > + handover_len = fdt_totalsize(handover_dt); > + handover_phys = handover_dt_phys; > + > + /* Reserve the DT so we can still access it in late boot */ > + memblock_reserve(handover_phys, handover_len); > + > + /* Reserve the mem cache so we can still access it later */ > + memblock_reserve(mem_cache_phys, mem_cache_len); > + > + /* > + * We pass a safe contiguous block of memory to use for early boot purporses from > + * the previous kernel so that we can resize the memblock array as needed. > + */ > + memblock_add(scratch_phys, scratch_len); > + > + if (WARN_ON(memblock_mark_scratch(scratch_phys, scratch_len))) { > + pr_err("Kexec failed to mark the scratch region. Disabling KHO."); > + handover_len = 0; > + handover_phys = 0; Same question here: doesn't all the KHO state gets invalid in case of any restoration error?