Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4145135ybb; Mon, 23 Mar 2020 14:31:29 -0700 (PDT) X-Google-Smtp-Source: ADFU+vthoqONdpqPKoR9FCC5GowM8ENi9PAP3R8vt4Y4r0819tYuZXBOb2eHXwewbMnWachJoFql X-Received: by 2002:a9d:6446:: with SMTP id m6mr18694302otl.122.1584999089647; Mon, 23 Mar 2020 14:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584999089; cv=none; d=google.com; s=arc-20160816; b=RPb2P8Rs1bkA0HrlISdPRpFzQxabpnSlVPm4b1JHDKbuYB5kFiBM1Q80hKLCT8ne6f nuCCPiL0j75VgyI0qReMTh88nqUXhAP7IS2I5bqmKKKaGoICT5r5d2Ruolt0lkqynZoT 0kUJ6o90OK1gDhpAFYLWPSrnF8CUGkNCvJzg/gUuVeTbOQ0MO5k5PqcVD7sMZ0jR4nuj VTKeXXPc2EP2MLwdKJ9+c6Lf3Ze8T7zEawwHC1ZKBAfI93W0uU1j/fnofnTEm9xtl7gJ xQznsc2XlHWrCsnSwqLLINEkIcfA2UEHPSddamkjlUZUZFWdaCpagrUmntxJ2vLdaBwA IAEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=ZVsEY6cNKMHIU4w2rXsM2TCIqoA6fSVNDl3M8SH4l6g=; b=DkUeIqBMRWg4/Z1KpgZWz7ksWsSQJQ0Zk9bJ4pU8RY++HMMr4khcyXTmEu+kDltT0d pxZ1x0fOmXIdlMCwXZ4Pa68zzHBcJNtfw+3BVtDGxyYxQqUQ+I34uuftmaEvfGT9LaF6 aWJt5Gv9XWKvi3gV6CaoMe7Kuiv/UTb4caYRw+NKMJohzxOO8uRDyQcKbnUf/lTTESc2 tuYUU+pTEYDOxfvL90V6qTqoKYGhQ1uH1Rr7JExGCv/pF7rxhVHRpfychLq8Iv5yJamy j9RAgVOsCqjW6i+MbgGrkSXKW06hvTze2F9YDqkomIhznPtUA12sldEoMqKCJ5EDvBRO r/3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dmIBPfG9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r82si8120922oia.155.2020.03.23.14.31.17; Mon, 23 Mar 2020 14:31:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dmIBPfG9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727240AbgCWVaV (ORCPT + 99 others); Mon, 23 Mar 2020 17:30:21 -0400 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]:55170 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726203AbgCWVaU (ORCPT ); Mon, 23 Mar 2020 17:30:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584999019; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZVsEY6cNKMHIU4w2rXsM2TCIqoA6fSVNDl3M8SH4l6g=; b=dmIBPfG9V1I/WxDzg/hZwdfDj2J8fpaXgoK18IerITJF56Ddpi9jz3NEVWoAQ5TtRromFK yGMPPAUf6vKI79VGCeIg+mfa8pvFnR7NEGRS2el0H4eoiKWROLLDuWnScdLgjIaBqHT41n CMLiGcfygK3Q5oPgZF4x4p3pcN7IkYA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-426-suLvxhWCM16kHxyllzdYtw-1; Mon, 23 Mar 2020 17:30:15 -0400 X-MC-Unique: suLvxhWCM16kHxyllzdYtw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E714A10CE782; Mon, 23 Mar 2020 21:30:12 +0000 (UTC) Received: from w520.home (ovpn-112-162.phx2.redhat.com [10.3.112.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id 21B2F60BF3; Mon, 23 Mar 2020 21:30:00 +0000 (UTC) Date: Mon, 23 Mar 2020 15:29:59 -0600 From: Alex Williamson To: Yan Zhao Cc: "intel-gvt-dev@lists.freedesktop.org" , "aik@ozlabs.ru" , "Zhengxiao.zx@alibaba-inc.com" , "shuangtai.tst@alibaba-inc.com" , "qemu-devel@nongnu.org" , "eauger@redhat.com" , "Liu, Yi L" , "Yang, Ziye" , "mlevitsk@redhat.com" , "pasic@linux.ibm.com" , "felipe@nutanix.com" , "Liu, Changpeng" , "Ken.Xue@amd.com" , "jonathan.davies@nutanix.com" , "He, Shaopeng" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "libvir-list@redhat.com" , "dgilbert@redhat.com" , "cohuck@redhat.com" , "Tian, Kevin" , "zhenyuw@linux.intel.com" , "Wang, Zhi A" , "cjia@nvidia.com" , "kwankhede@nvidia.com" , "berrange@redhat.com" , "dinechin@redhat.com" Subject: Re: [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration Message-ID: <20200323152959.1c39e9a7@w520.home> In-Reply-To: <20190604003422.GA30229@joy-OptiPlex-7040> References: <20190531004438.24528-1-yan.y.zhao@intel.com> <20190603132932.1b5dc7fe@x1.home> <20190604003422.GA30229@joy-OptiPlex-7040> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Jun 2019 20:34:22 -0400 Yan Zhao wrote: > On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote: > > On Thu, 30 May 2019 20:44:38 -0400 > > Yan Zhao wrote: > > > > > This patchset introduces a migration_version attribute under sysfs of VFIO > > > Mediated devices. > > > > > > This migration_version attribute is used to check migration compatibility > > > between two mdev devices of the same mdev type. > > > > > > Patch 1 defines migration_version attribute in > > > Documentation/vfio-mediated-device.txt > > > > > > Patch 2 uses GVT as an example to show how to expose migration_version > > > attribute and check migration compatibility in vendor driver. > > > > Thanks for iterating through this, it looks like we've settled on > > something reasonable, but now what? This is one piece of the puzzle to > > supporting mdev migration, but I don't think it makes sense to commit > > this upstream on its own without also defining the remainder of how we > > actually do migration, preferably with more than one working > > implementation and at least prototyped, if not final, QEMU support. I > > hope that was the intent, and maybe it's now time to look at the next > > piece of the puzzle. Thanks, > > > > Alex > > Got it. > Also thank you and all for discussing and guiding all along:) > We'll move to the next episode now. Hi Yan, As we're hopefully moving towards a migration API, would it make sense to refresh this series at the same time? I think we're still expecting a vendor driver implementing Kirti's migration API to also implement this sysfs interface for compatibility verification. Thanks, Alex