Re: [PATCH RFC 0/5] nvme: Controller Data Queue (CDQ) support

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Apr 24, 2026 at 01:37:50PM +0200, Joel Granados wrote:

> There is however, no clear consensus on how NVMe Live Migration should
> land in the Linux kernel. The 2022 discussion [1] explored a VFIO-based
> approach but reached no conclusion, likely because the specification was
> not yet mature.

Yes it was paused until the spec matures, then I expect it to go
forward.
 
> To move CDQ forward, I would like to understand where the LM logic belongs. I
> currently see two options (of which I have no particular preference):
> 
> 1. VFIO: Implement NVMe LM following the VFIO state machine, similar to what
>    was proposed in 2022.
> 2. VM manager interface: Bypass VFIO and implement LM logic in the interface
>    between the VM manager (e.g., QEMU) and the NVMe driver.

I imagined it to be split between VFIO for the pci and volatile guest
state and something else for the namespace setup and media migration.
Media migration is only needed for local drive so there use cases that
don't need this component.

We have many drivers fitting into the VFIO scheme now and good VMM
coverage, I don't see a reason to throw it out.

> One aspect that has not received much attention in previous discussions
> is namespace migration as prior work focused on migrating state and not
> the actual data. Migrating potential terabytes is IMO a distinct use
> case worth considering. 

Yes

Though IDK if just plumbing the entire CDQ to userspace is the right
choice for NVMe.. We don't know what future specs will add to CDQ, it
may not be appropriate to treat it so insecurely.

Jason