[PATCH v2 0/3] kho: Add support for kunit mocking KHO restore API

[Samiullah Khawaja]

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