Re: [PATCH v3 7/9] docs: add documentation for guest_memfd preservation via LUO

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch includes an undocumented logic bug fix in C code while being labeled as a pure documentation change.
- [Low] Typos and grammatical errors in the new documentation.
--

commit eb552713cd5f980d69c6b422467b4dfbb265bad1
Author: Tarun Sahu <tarunsahu@google.com>

docs: add documentation for guest_memfd preservation via LUO

This commit adds documentation under the "Preserving file descriptors" section
of LUO's documentation. It describes the requirements and limitations for
guest_memfd preservation.

> diff --git a/Documentation/liveupdate/vmm.rst b/Documentation/liveupdate/vmm.rst
> new file mode 100644
> index 0000000000000..8353e236471d2
> --- /dev/null
> +++ b/Documentation/liveupdate/vmm.rst

[ ... ]

> +Scope and Limitations
> +---------------------
> +
> +At this stage, the scope of guest_memfd preservation is restricted to:
> +
> +1. **Fully Shared guest_memfd**:
> +   This time only fully shared guest_memfd supported. Any system that
> +   supports coco vm (which uses private guest_memfd), will not support
> +   the preservation.

[Severity: Low]
This isn't a bug, but there are some grammatical issues here. "This time only
fully shared guest_memfd supported" seems like it should be "At this time, only
fully shared guest_memfd is supported". Also, "coco vm" should probably be
capitalized as "CoCo VM".

[ ... ]

> +Retrieval Order
> +~~~~~~~~~~~~~~~
> +
> +Similarly, there is no strict ordering required for retrieving the VM
> +and guest_memfd files. Any file can be retrieved at any order.
> +
> +If guest_memfd file is retrieved and VM file is not retrieved, and
> +luo_finish is called, then vm_file will be lost and guest_memfd file
> +will be hanging around.
> +
> +NOTE: Before Initiating the preservation/retirval, it is necessary to make

[Severity: Low]
This isn't a bug, but there is a typo here: "retirval" should be "retrieval".

> +sure that the kvm module is loaded (/dev/kvm must be available).
> +
> +

[ ... ]

> diff --git a/virt/kvm/guest_memfd_luo.c b/virt/kvm/guest_memfd_luo.c
> index c242b1d14c0ac..8411fe86dc2a1 100644
> --- a/virt/kvm/guest_memfd_luo.c
> +++ b/virt/kvm/guest_memfd_luo.c
> @@ -119,11 +119,11 @@ static bool kvm_gmem_luo_can_preserve(struct liveupdate_file_handler *handler, s
>  	/*
>  	 * Only Fully-shared guest_memfd preservation is supported
>  	 */
> -	if (GMEM_I(inode)->flags & GUEST_MEMFD_FLAG_INIT_SHARED)
> +	if (!(GMEM_I(inode)->flags & GUEST_MEMFD_FLAG_INIT_SHARED))
>  		return 0;

[Severity: Medium]
Should this functional logic fix in kvm_gmem_luo_can_preserve() be split into
its own patch? 

The commit message explicitly states this is a documentation change, but this
modifies the condition for GUEST_MEMFD_FLAG_INIT_SHARED in C code, which
violates the rule of one logical change per commit and makes tracking bug
fixes difficult.

>  
>  	/*
> -	 * It makes sure that no memory can converted to private
> +	 * It makes sure that no memory can be converted to private
>  	 * even if it was initially fully shared (in-place conversions are
>  	 * prevented).
>  	 */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622184851.2309827-1-tarunsahu@google.com?part=7