Re: [RFC PATCH v2 2/4] KVM: x86: Add optional KVM_CAP_LIVE_MIGRATION and KVM_MIGRATE_CMD

[Kishen Maloor <kishen.maloor@intel.com>]

On 8/31/26 12:13 AM, Tony Lindgren wrote:

I was wondering how a vendor would use kvm_transfer_buffer for a command that
passes an input and also returns an output. size can describe the input
length or the space available for output, not both, so the kernel has no way to
know how much it may write.

Two suggestions below. They're orthogonal.

> ...
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 5f6c1ce9673b7..d9291a8a97bb1 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -2010,6 +2010,8 @@ struct kvm_x86_ops {
>  	int (*gmem_prepare)(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order);
>  	void (*gmem_invalidate)(kvm_pfn_t start, kvm_pfn_t end);
>  	int (*gmem_max_mapping_level)(struct kvm *kvm, kvm_pfn_t pfn, bool is_private);
> +	bool (*cap_live_migration)(struct kvm *kvm);

Should this return an 'int' specifying the maximum buffer size that the vendor impl
requires/uses? Userspace can then learn this once.
> ...
> +
> +struct kvm_transfer_buffer {
> +	__u64 address;
> +	__u32 size;
> +	__u32 reserved;
> +};

Should this struct include a 'capacity' field (u32) that is set on each command?
It would be the number of bytes writable at address.
size would be the input length on entry (0 if the command passes none), and the
number of bytes produced on return (0 if none).