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

[Joel Granados]

On Fri, Apr 24, 2026 at 10:06:15AM -0300, Jason Gunthorpe wrote:
> 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.
That is an option. If we end up with an approach that supports namespace
migration, I'm happy :)

> Media migration is only needed for local drive so there use cases that
> don't need this component.
Indeed, And there should be an approach that supports those use cases as
well.

> 
> We have many drivers fitting into the VFIO scheme now and good VMM
> coverage, I don't see a reason to throw it out.
And this is why I included it as one of the ways to implement it.

> 
> > 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.
Agreed, this RFC is just one of many ways of doing it. My original one is
fully contained inside the NVMe driver. One thing that is clear with the
tests that I have made, is that it is easy to move the CDQ logic in and
out of user space (depending on what is needed).

Best

-- 

Joel Granados
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20260427/01676bd3/attachment.sig>