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 10/8/26 2:22 AM, Tony Lindgren wrote:
> On Thu, Sep 24, 2026 at 10:15:17AM +0300, Tony Lindgren wrote:
>> On Wed, Sep 23, 2026 at 10:34:14PM -0700, Kishen Maloor wrote:
>>> On 9/22/26 11:50 PM, Tony Lindgren wrote:
> ...
> Based on the ARM CCA live migration presentation at LPC by Mathias
> Brossard, we now have a user for a separate metadata buffer. Adding
> Mathias to Cc.
> 
> Page 8 of the presentation at [0] below lists it under feedback. And see
> also page 10 for feedback.
> 
> Probably best to make the buffer a userspace array with an arch specific
> define for the number of buffers. So far looks like two buffers for ARM,
> and one might be enough for x86.

I'm not sure -- I think we need to first understand the issue here.

TDX also exports separate content (encrypted pages) and metadata (GPA
lists, MACs). The UAPI refers to an array of page-sized buffers, but the
QEMU and KVM backends for a platform can decide and agree on how
everything is laid out within them.

In the TDX case, the UAPI caller (QEMU) doesn't need to inspect the
blobs returned by the kernel (from the TDX module), but if it did,
QEMU's TDX backend could be given the know-how to find what it needs.

Mathias, is there something in CCA's case that a single array of buffers
with a backend-defined layout can't handle?

> Looks like we should have a separate SETUP command to query the buffer
> sizes for cmd, memory and vCPU transfers.

I think we agreed to return the maximum buffer size (in pages) that a
vendor implementation ever needs (across all its calls) through
KVM_CAP_LIVE_MIGRATION. That gives userspace a single reference, so it
allocates those buffers once and reuses them across calls.

Mathias, does this model hold for CCA? Could KVM_CAP_LIVE_MIGRATION for
CCA calculate and return a single max buffer size that suffices for the
whole migration?