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

[Joel Granados]

On Tue, Apr 28, 2026 at 03:56:28AM +0000, Chaitanya Kulkarni wrote:
> On 4/27/26 11:24 AM, Joel Granados wrote:
> > On Fri, Apr 24, 2026 at 03:24:23PM +0200, Christoph Hellwig wrote:
> >> 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.
> >> And it will happen in the nvme software working group.  Which should be
> >> up an running if Samsung hadn't done everything in the power to torpedo
> > There is nothing that indicates to me that Samsung "torpedoed" the
> > creation of the nvme SW working group.
> >
> >> it.  Because of that I do not exact Samsung to have any major impact in
> >> how this will be implemented in Linux.
> >>
> >> Note that we also can't discuss any of this at LSF/MM in public, so
> > I see no reason not to have the discussion at LSF/MM. It is the perfect
> > venue to unpack the (potential) interaction between the vfio and nvme
> > drivers. Regardless of what is currently brewing in NVMe, there is no
> > reason why the fundamental architecture cannot be discussed. Of course,
> > we need to be careful of what is mentioned in public, but I see that as
> > a detail that does not prevent from having the conversation.
> >
> > Best
> >
> Thanks for your perspective — I agree that LSF/MM is generally a
> valuable venue for cross-subsystem discussions, including vfio and
> nvme interactions.
> 
> For context, we initially brought this topic forward as an RFC in
> 2022 and followed up with a dedicated session at LSFMM 2023
> where we received detailed feedback from the kernel community.
> That input has since shaped the current direction of the work.
> 
> Going forward development and discussion will happen NVMe consortium
> approved NVMe LM SW WG. To keep the discussion focused and productive,
> it would be helpful to continue deeper architectural and
> implementation discussions there.
> 
> That said, I’m very open to collaboration and would be glad to work
> with you through the NVMe LM SW WG. If you have specific questions
> or concerns around vfio/NVMe interactions, please feel free to
> raise them there — I’ll make sure they receive prompt attention.
Thx. Its good to know that that channel is open. I'll be sure to get on
that bus when the meetings start.

> 
> Also, there seems to be no response on your LSFMM topic, since this
> work is moved to NVMe LM SW WG it will be great you bring your
> concerns there.
IMO, Having the NVMe LM SW make sense as there are probably discussions
that are easier in that context, but we should not cancel the discussion
in LSF because there is an NVMe SW WG. I believe both can take place and
can complement each other.

I was given a slot in LSF and I'll be there to try to get clarity on the
use case that interest me (NVMe namespace migration).

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/20260428/b0fb5275/attachment.sig>