Re: [RFC PATCH v2 0/4] Add KVM API for confidential guest live migration

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

On Wed, Oct 07, 2026 at 04:13:32PM -0400, Peter Xu wrote:
> On Tue, Oct 06, 2026 at 09:27:47PM -0700, Kishen Maloor wrote:
> > Hi Peter,
> 
> Hi, Kishen,
> 
> [...]
> 
> > > Especially, MEM.IMPORT seems trickier to me: MEM.EXPORT even if described
> > > in in GPA address space, can be converted to other address spaces at will,
> > > as long as QEMU has full knowledge of the mappings.  MEM.IMPORT, OTOH, may
> > > not trivially work in GPA terms, if memory mappings can overlap.
> > 
> > I can appreciate that. Working in GPA terms assumes that a GPA reference is
> > unambiguous over the duration of migration, which holds true in the TDX case.
> > 
> > But it would break if another backend is able to point a mapped GPA at a
> > different protected page while keeping both pages valid -- essentially
> > the PAM case on regular VMs.
> > 
> > One option that comes to mind is to add a 2nd optional identifier to
> > kvm_memory_transfer consisting of a guest_memfd fd and an offsets array.
> > That would be at parity with QEMU's block+offset and directly reference
> > specific storage units. Then QEMU and KVM backends for a platform would
> > decide what identifier to use.
> > 
> > The value might be that a bundle could be accepted by a backend for
> > storage that isn't currently mapped in a memslot.
> > 
> > OTOH, slot+offset as an identifier might face the same problem as GPA in
> > this case when a particular RAMBlock's storage isn't mapped at the time
> > on the destination.
> > 
> > Not sure if this idea is viable or even makes sense; this is mostly
> > for discussion, but would appreciate your thoughts.
> 
> Yes, I would think (gmemfd, [array of fd offsets]) a nice interface.
> 
> If we say gmemfd is the container of data in KVM world, then if it can
> provide all data accessors it feels all natural and fit.  And yes, it also
> works for overlapped.
> 
> Said that, it's a matter of if, TDX or any other solution, will use GPA to
> be part of attestation process when loading the data.  My intepretation is
> GPA was part of TDX MEM.IMPORT workflow and required, but now since you
> proposed gmem for indexing pages, maybe I was wrong.  In this case, I'd be
> more than happy if I was wrong..

Yes GPAs are part of the MAC generated by tdh_export_mem() so cannot change
for import. This can be seen at the TDX module source at [0] below.

What if we add a flag for the memory functions to describe the type of
addressing used?

[0] https://github.com/intel/confidential-computing.tdx.tdx-module/blob/tdx_1.5/src/vmm_dispatcher/migration_api_calls/tdh_export_mem.c#L1083