From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEB0E37DAA2 for ; Wed, 17 Jun 2026 18:57:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781722661; cv=none; b=jqcHATf12UFYhq+8QcKpfhEwA8nWSLAyHzzAgRZ4g6F7lT6nWtZ7wGltk72Jh5cp5LB09ubKOpEa2KDVR30yNnx3Ah0kz4i0LiCVwuso2Yy2f+s5k5xyOWqqUSWT1dAvO9pWgtehrJA7DloEPraWTdUzF90gxiwG+oRhi1zJ2TI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781722661; c=relaxed/simple; bh=FoJvKD5tzCWdva/dUURhAsU1GE2s2i6XbtyVyeIwJxo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rF1HU6P0lYtiLynSiTdGsXprN83SrP32cNV0yFKUpxytOSz3bR53ECUgpPflerXx709/bPWw5KhkI3vEZqKh+OFxpo0jOkbpZ8OETVrfa6WNwNXf+jPEY/ly52yiq+zLUyY0pUKQvGMNgq3tDbw12ekdODsoRF538B/c078xpi4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fXryMjMk; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fXryMjMk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D7891F00A3A; Wed, 17 Jun 2026 18:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781722660; bh=MuHmxF3Q3Im7lyehrUggcluXuhikWRgzOx5fgePtduM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=fXryMjMk/Xq0WcxFi0hr2UMx4uUqPl2Mf+U9u1XOSgK97gCt9F2Qm2zCSpchld2X1 vfC2fdVvpzjCo3Z9nE+pNnZI9XoAGHR5qfhtC4Q2v4OBXjWdQ8gaqUoL9eCDuxcXER xedFJeKWCkOW7+5sRRdytlXq/QqYQhGgJqFmrYNyT0nllTv/ZUNuiDlzC2prcNqvb/ 8dz/HpV3EQ9T90n+zh5IiZ8qKomMPZAeeA3UGDdcVlp+Ywim0K6W0R150Qcj3fGN1q Ej1mYOlwedKVnNOTm2EjbjCH4U3hB27BjqzilFy1KDmqWYsrIOR9dZAuJzC25K8GFG o3Ys2n/hyo46Q== Date: Wed, 17 Jun 2026 21:57:34 +0300 From: Mike Rapoport To: Samiullah Khawaja Cc: Pasha Tatashin , Pratyush Yadav , Alexander Graf , David Matlack , open list , "open list:KEXEC HANDOVER (KHO)" , "open list:KEXEC HANDOVER (KHO)" Subject: Re: [PATCH v2 0/3] kho: Add support for kunit mocking KHO restore API Message-ID: References: <20260521193202.746810-1-skhawaja@google.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: Hi Sami, On Tue, Jun 16, 2026 at 07:15:03PM +0000, Samiullah Khawaja wrote: > On Mon, Jun 01, 2026 at 10:00:05AM +0300, Mike Rapoport wrote: > > Hi Samiullah, > > > > On Thu, May 21, 2026 at 07:31:59PM +0000, Samiullah Khawaja wrote: > > > To write kunit tests for preservation and restoration of liveupdate > > > state in various subsystems without triggering the actual kexec, the KHO > > > restore API needs to be mocked by the test writer. The mocking is done > > > to allow testing of the individual components or functions in isolation. > > > > > > The patch series adds the following to support kunit testing when using the KHO > > > API: > > > > > > - Add static stub hooks to mock the KHO restore API so the restore path > > > can be tested without triggering kexec. > > > - Add helper function that can be used by the test writer to check if > > > memory is preserved in KHO tree. > > > > > > Finally, it adds a KUnit test for the KHO API that verifies the allocation of > > > preserved memory, and the preservation/restoration of pages and folios. > > > > I looked at the tests for preservation and apparently they don't add > > coverage beyond the existing KHO selftest. How hard and/or intrusive would > > be adding tests for example for error paths? > > > > Do you have an example of a kunit test for another subsystem that would > > benefit from mocking of KHO APIs? > > I think intrusive tests to get more coverage for KHO would probably not > use the stubs added in this series, as these are meant to mock the KHO > restore API itself. > > My motivation was to allow downstream users of KHO to test their own > preservation logic (making sure their ABI doesn't have bugs). LUO or the > recently added KHO linked-block can probably be a start? > > The KHO kunit test added here is just a minimum example of how to use the > stubs, which is why it doesn't provide much extra coverage. > > I am perfectly happy to drop this patch for now. We can get this in > later when we have kunit tests for KHO users. WDYT? I wouldn't want to merge this upstream before the actual users appear, but we can apply this to a branch in the liveupdate tree and keep it there so that subsystems that plan to use these stubs could base their work on that branch. Let's revisit this after -rc1 is out. > Thanks, > Sami -- Sincerely yours, Mike.