From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D698C04FDE for ; Mon, 12 Dec 2022 07:57:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231336AbiLLH5N (ORCPT ); Mon, 12 Dec 2022 02:57:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231213AbiLLH5K (ORCPT ); Mon, 12 Dec 2022 02:57:10 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 573AFBF49; Sun, 11 Dec 2022 23:57:10 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id A09EB68AA6; Mon, 12 Dec 2022 08:57:07 +0100 (CET) Date: Mon, 12 Dec 2022 08:57:07 +0100 From: Christoph Hellwig To: "Dong, Eddie" Cc: Christoph Hellwig , Jason Gunthorpe , "Rao, Lei" , "kbusch@kernel.org" , "axboe@fb.com" , "kch@nvidia.com" , "sagi@grimberg.me" , "alex.williamson@redhat.com" , "cohuck@redhat.com" , "yishaih@nvidia.com" , "shameerali.kolothum.thodi@huawei.com" , "Tian, Kevin" , "mjrosato@linux.ibm.com" , "linux-kernel@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "kvm@vger.kernel.org" , "Li, Yadong" , "Liu, Yi L" , "Wilk, Konrad" , "stephen@eideticom.com" , "Yuan, Hang" Subject: Re: [RFC PATCH 5/5] nvme-vfio: Add a document for the NVMe device Message-ID: <20221212075707.GD11162@lst.de> References: <20221206130901.GB24358@lst.de> <20221206140002.GB27689@lst.de> <20221206143126.GB30297@lst.de> <20221206150131.GA32365@lst.de> <20221206153546.GA2266@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 06, 2022 at 06:00:27PM +0000, Dong, Eddie wrote: > NVMe spec is general, but the implementation details (such as internal state) may > be vendor specific. If the migration happens between 2 identical NVMe devices > (from same vendor/device w/ same firmware version), migration of > subsystem-wide state can be naturally covered, right? No. If you want live migration for nvme supported in Linux, it must be speced in the NVMe technical working group and interoperate between different implementations.