From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE96A3DD532 for ; Tue, 16 Jun 2026 19:15:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781637309; cv=none; b=p/qK1s0POM60pvGz4GM/9dHnoyorCBMXv9HPTrhD9GUh+PRGlXmGq8uji1PaN+S4bRJ7DuKbFZtALkqBeF87Fu0xp9yLtcEwW/v7jqE34XcfYVQjYK/ct1BCH04dbW48rDrp7/MQzasLt90NqnTmF7wFBZxee63hKVzxJf0MV90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781637309; c=relaxed/simple; bh=4ik0M3kWxvZHAtr8QRXpQEdpsvfHRxSbcpJEnzqBmEA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aJpcIT1O9eJvk8APJUhMnJykKJ6j3TxjAj9il12GMOsBZK8cTgHUhtSf7XCoDKtAUQGTT5QlIIiduvvbPcG75QPaJPqAgguf2VlA1QG+WFXV8seuRBuDmhP+92K8x5/knZ0tBp8DhlSF1kLM8NX4fcMQLB41gygX1KlDXAvT72s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=uz5wvY/C; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uz5wvY/C" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2c6a4eccab1so10095ad.1 for ; Tue, 16 Jun 2026 12:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781637307; x=1782242107; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uJNdmkiK3PhuRperaiQ6089ov2561C0H0udd8xzGUrk=; b=uz5wvY/C1lxnpcCbBgz+CGPM3/t9O3UHlhAd4Ud+M2NE1dKcRpA8M5DqCyX1iIv/j4 tyOkLQgEp6GfolhO5T80yFapX1MJrVOLU3XPqabFfzRA6wfj2KRTWqf3z6tPRYIfyJXW OXfMsTjIdsDpEveDoapKkcRpukmYz7axqPd3CiABN6UqEHxY4qAbJqPaEDyEPj0xp4op QVVyqPoSqH0h0Buv6Bc0Kz3hS19/GRrt/ZOe7/aGImbkU1ZgStSN/jGfYPUvoiEvjLfr 43Vb+85VskmLSfcv0C1GSLNkzMPHZ2GMUHCNeD1PGvzTSFJ+Xm3RuiqNz/M9GznK7Gao Orxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781637307; x=1782242107; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uJNdmkiK3PhuRperaiQ6089ov2561C0H0udd8xzGUrk=; b=V2SsvwX4u+lrPObrqdDwXTaRqzwN0zhaLtUeyDQH3GQHv3q2CZNzJzQZwe+uB9w1ij mWPfwIDdAzCM2Sk+oyEaUC3+XQ3EIG0yl7QIG2iCN2SJedDWOTbr/zK5X1LH7FSrLETS aIq7k8+QRXV+QOW2LtJrWBFb6EhYMDWl/5IRVUQVnU6fFr237Hzv+TatrVZMoujBchyL A7m5x8u28E7U3ZZG8tiyvPG+PaCOd7z2dN6NaHFFyAM/pIFCqBBCneOVsxovmsdvfTwz o5EfygYWlmoetadDvRH2sablnTHW2S9bv70SigrhtFh6kHXpm18CsKpfd/5oMBK2UhR+ 1onQ== X-Forwarded-Encrypted: i=1; AFNElJ8vZ4biuVDmkk5aLK2F+tx6aruxNGJmvf7Pb1dbbl1SHDNPE2qfc5IOW3fNtj10DJvcYZYfGeNa1ZOTZIg=@vger.kernel.org X-Gm-Message-State: AOJu0YyJhWUTsajkjFoWZ0IbEdtl1E6G9w2fc5+mMmVnNYcG9AmolqQ/ pNsBwZ98pdsz5l3qlAAEs7p6SX8M1DTeO8YKkS4pY3HtoL7L9VxpMIfxpnczfkX7nA== X-Gm-Gg: AfdE7cms07kcptgZ9cNPn9+QEDcmrUWVs1U7TC8voq0v5QFBQsq2bBExPKNCP/YVL0E nhAHBL01FIc3b8Iw3HS9uf7W1ucBhyDRjIydurxQQS/LhXslTggn0+tpMzCwSql3EfIxkj+34Zx hChUBt8m/L2/lugIG0Xv02Is22bOHQ+dogQKsDKOHe3eaueq5l32GSfnN3iHNoRx3yGvUlkhYtQ tOkj6LIWWbQtc5YYbZAcoraSQgi1YB+7InM9P8s/ab4/06fVscVnKXIHBH7r9WEyhV/twTIhvqK 5WQAjVZOlkWKD0JtF4XMnsBGnMGd04yNn8fj+t0OQLVawkftnr542kBQNo2nlC9aceZyB6LkdD1 8//PngAKdC+dECw0RhXVXK/xrhmvyaV9ivjkC7KO3Z/eCHvc/flF0k9NJF46hoZR61TohirPY8v Dp40gXNiISXa1m65aZhw/JxRamwu68GcOTMTDG634Fw2ypB1tuTOG/rT491qU5F0yjugxfXDQB4 uz41RdT5F3wZXJHKXk= X-Received: by 2002:a17:902:f706:b0:2c6:8564:46b9 with SMTP id d9443c01a7336-2c6bbb030femr394805ad.30.1781637306612; Tue, 16 Jun 2026 12:15:06 -0700 (PDT) Received: from google.com (25.75.145.34.bc.googleusercontent.com. [34.145.75.25]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c432d86501sm132585345ad.61.2026.06.16.12.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 12:15:06 -0700 (PDT) Date: Tue, 16 Jun 2026 19:15:03 +0000 From: Samiullah Khawaja To: Mike Rapoport 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; format=flowed Content-Disposition: inline In-Reply-To: Hi Mike, Sorry for the late reply, I got pulled into some other stuff. 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? > [snip] > >-- >Sincerely yours, >Mike. Thanks, Sami