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

[Tony Lindgren <tony.lindgren@linux.intel.com>]

On Mon, Sep 21, 2026 at 08:58:17AM +0300, Tony Lindgren wrote:
> On Thu, Sep 17, 2026 at 09:33:18PM -0700, Kishen Maloor wrote:
> > 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.
> 
> OK that sounds good to me. I assume you are thinking the maximum hardware
> specific buffer size per thread? As in 512 * 4096 bytes for the TDX case?
> 
> > > +
> > > +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).
> 
> Hmm so the transfer command return value can return how many bytes were
> written of the input. But yeah we don't know how many bytes were written
> back to the transfer buffer as result of the transfer command.
> 
> How about if we add the bytes returned to the transfer struct? Then the
> kvm_transfer_buffer can stay as just a buffer. 

Actually, for the possible cases with input+output, we could reserve space
in the transfer struct for another struct kvm_transfer_buffer for the
results?