From: Cornelia Huck <cohuck@redhat.com> To: Yan Zhao <yan.y.zhao@intel.com> Cc: "intel-gvt-dev@lists.freedesktop.org" <intel-gvt-dev@lists.freedesktop.org>, "libvir-list@redhat.com" <libvir-list@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "aik@ozlabs.ru" <aik@ozlabs.ru>, "Zhengxiao.zx@alibaba-inc.com" <Zhengxiao.zx@alibaba-inc.com>, "shuangtai.tst@alibaba-inc.com" <shuangtai.tst@alibaba-inc.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "eauger@redhat.com" <eauger@redhat.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "Zeng, Xin" <xin.zeng@intel.com>, "Yang, Ziye" <ziye.yang@intel.com>, "mlevitsk@redhat.com" <mlevitsk@redhat.com>, "pasic@linux.ibm.com" <pasic@linux.ibm.com>, "felipe@nutanix.com" <felipe@nutanix.com>, "Liu, Changpeng" <changpeng.liu@intel.com>, "Ken.Xue@amd.com" <Ken.Xue@amd.com>, "jonathan.davies@nutanix.com" <jonathan.davies@nutanix.com>, "He, Shaopeng" <shaopeng.he@intel.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "eskultet@redhat.com" <eskultet@redhat.com>, "dgilbert@redhat.com" <dgilbert@redhat.com>, "Tian, Kevin" <kevin.tian@intel.com>, "zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>, "Wang, Zhi A" <zhi.a.wang@intel.com>, "cjia@nvidia.com" <cjia@nvidia.com>, "kwankhede@nvidia.com" <kwankhede@nvidia.com>, "berrange@redhat.com" <berrange@redhat.com>, "dinechin@redhat.com" <dinechin@redhat.com>, "corbet@lwn.net" <corbet@lwn.net> Subject: Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration Date: Fri, 17 Apr 2020 13:24:57 +0200 [thread overview] Message-ID: <20200417132457.45d91fe3.cohuck@redhat.com> (raw) In-Reply-To: <20200417095202.GD16688@joy-OptiPlex-7040> On Fri, 17 Apr 2020 05:52:02 -0400 Yan Zhao <yan.y.zhao@intel.com> wrote: > On Fri, Apr 17, 2020 at 04:44:50PM +0800, Cornelia Huck wrote: > > On Mon, 13 Apr 2020 01:52:01 -0400 > > Yan Zhao <yan.y.zhao@intel.com> 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. > > > > > > Currently, it has two locations: > > > (1) under mdev_type node, > > > which can be used even before device creation, but only for mdev > > > devices of the same mdev type. > > > (2) under mdev device node, > > > which can only be used after the mdev devices are created, but the src > > > and target mdev devices are not necessarily be of the same mdev type > > > (The second location is newly added in v5, in order to keep consistent > > > with the migration_version node for migratable pass-though devices) > > > > What is the relationship between those two attributes? > > > (1) is for mdev devices specifically, and (2) is provided to keep the same > sysfs interface as with non-mdev cases. so (2) is for both mdev devices and > non-mdev devices. > > in future, if we enable vfio-pci vendor ops, (i.e. a non-mdev device > is binding to vfio-pci, but is able to register migration region and do > migration transactions from a vendor provided affiliate driver), > the vendor driver would export (2) directly, under device node. > It is not able to provide (1) as there're no mdev devices involved. Ok, creating an alternate attribute for non-mdev devices makes sense. However, wouldn't that rather be a case (3)? The change here only refers to mdev devices. > > > Is existence (and compatibility) of (1) a pre-req for possible > > existence (and compatibility) of (2)? > > > no. (2) does not reply on (1). Hm. Non-existence of (1) seems to imply "this type does not support migration". If an mdev created for such a type suddenly does support migration, it feels a bit odd. (It obviously cannot be a prereq for what I called (3) above.) > > > Does userspace need to check (1) or can it completely rely on (2), if > > it so chooses? > > > I think it can completely reply on (2) if compatibility check before > mdev creation is not required. > > > If devices with a different mdev type are indeed compatible, it seems > > userspace can only find out after the devices have actually been > > created, as (1) does not apply? > yes, I think so. How useful would it be for userspace to even look at (1) in that case? It only knows if things have a chance of working if it actually goes ahead and creates devices. > > > One of my worries is that the existence of an attribute with the same > > name in two similar locations might lead to confusion. But maybe it > > isn't a problem. > > > Yes, I have the same feeling. but as (2) is for sysfs interface > consistency, to make it transparent to userspace tools like libvirt, > I guess the same name is necessary? What do we actually need here, I wonder? (1) and (2) seem to serve slightly different purposes, while (2) and what I called (3) have the same purpose. Is it important to userspace that (1) and (2) have the same name?
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com> To: Yan Zhao <yan.y.zhao@intel.com> Cc: "cjia@nvidia.com" <cjia@nvidia.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "libvir-list@redhat.com" <libvir-list@redhat.com>, "Zhengxiao.zx@alibaba-inc.com" <Zhengxiao.zx@alibaba-inc.com>, "shuangtai.tst@alibaba-inc.com" <shuangtai.tst@alibaba-inc.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "kwankhede@nvidia.com" <kwankhede@nvidia.com>, "eauger@redhat.com" <eauger@redhat.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "eskultet@redhat.com" <eskultet@redhat.com>, "Yang, Ziye" <ziye.yang@intel.com>, "mlevitsk@redhat.com" <mlevitsk@redhat.com>, "pasic@linux.ibm.com" <pasic@linux.ibm.com>, "aik@ozlabs.ru" <aik@ozlabs.ru>, "felipe@nutanix.com" <felipe@nutanix.com>, "Ken.Xue@amd.com" <Ken.Xue@amd.com>, "Tian, Kevin" <kevin.tian@intel.com>, "Zeng, Xin" <xin.zeng@intel.com>, "dgilbert@redhat.com" <dgilbert@redhat.com>, "zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>, "dinechin@redhat.com" <dinechin@redhat.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "intel-gvt-dev@lists.freedesktop.org" <intel-gvt-dev@lists.freedesktop.org>, "Liu, Changpeng" <changpeng.liu@intel.com>, "berrange@redhat.com" <berrange@redhat.com>, "corbet@lwn.net" <corbet@lwn.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Wang, Zhi A" <zhi.a.wang@intel.com>, "jonathan.davies@nutanix.com" <jonathan.davies@nutanix.com>, "He, Shaopeng" <shaopeng.he@intel.com> Subject: Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration Date: Fri, 17 Apr 2020 13:24:57 +0200 [thread overview] Message-ID: <20200417132457.45d91fe3.cohuck@redhat.com> (raw) In-Reply-To: <20200417095202.GD16688@joy-OptiPlex-7040> On Fri, 17 Apr 2020 05:52:02 -0400 Yan Zhao <yan.y.zhao@intel.com> wrote: > On Fri, Apr 17, 2020 at 04:44:50PM +0800, Cornelia Huck wrote: > > On Mon, 13 Apr 2020 01:52:01 -0400 > > Yan Zhao <yan.y.zhao@intel.com> 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. > > > > > > Currently, it has two locations: > > > (1) under mdev_type node, > > > which can be used even before device creation, but only for mdev > > > devices of the same mdev type. > > > (2) under mdev device node, > > > which can only be used after the mdev devices are created, but the src > > > and target mdev devices are not necessarily be of the same mdev type > > > (The second location is newly added in v5, in order to keep consistent > > > with the migration_version node for migratable pass-though devices) > > > > What is the relationship between those two attributes? > > > (1) is for mdev devices specifically, and (2) is provided to keep the same > sysfs interface as with non-mdev cases. so (2) is for both mdev devices and > non-mdev devices. > > in future, if we enable vfio-pci vendor ops, (i.e. a non-mdev device > is binding to vfio-pci, but is able to register migration region and do > migration transactions from a vendor provided affiliate driver), > the vendor driver would export (2) directly, under device node. > It is not able to provide (1) as there're no mdev devices involved. Ok, creating an alternate attribute for non-mdev devices makes sense. However, wouldn't that rather be a case (3)? The change here only refers to mdev devices. > > > Is existence (and compatibility) of (1) a pre-req for possible > > existence (and compatibility) of (2)? > > > no. (2) does not reply on (1). Hm. Non-existence of (1) seems to imply "this type does not support migration". If an mdev created for such a type suddenly does support migration, it feels a bit odd. (It obviously cannot be a prereq for what I called (3) above.) > > > Does userspace need to check (1) or can it completely rely on (2), if > > it so chooses? > > > I think it can completely reply on (2) if compatibility check before > mdev creation is not required. > > > If devices with a different mdev type are indeed compatible, it seems > > userspace can only find out after the devices have actually been > > created, as (1) does not apply? > yes, I think so. How useful would it be for userspace to even look at (1) in that case? It only knows if things have a chance of working if it actually goes ahead and creates devices. > > > One of my worries is that the existence of an attribute with the same > > name in two similar locations might lead to confusion. But maybe it > > isn't a problem. > > > Yes, I have the same feeling. but as (2) is for sysfs interface > consistency, to make it transparent to userspace tools like libvirt, > I guess the same name is necessary? What do we actually need here, I wonder? (1) and (2) seem to serve slightly different purposes, while (2) and what I called (3) have the same purpose. Is it important to userspace that (1) and (2) have the same name?
next prev parent reply other threads:[~2020-04-17 11:27 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-13 5:52 [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration Yan Zhao 2020-04-13 5:52 ` Yan Zhao 2020-04-13 5:54 ` [PATCH v5 1/4] vfio/mdev: add migration_version attribute for mdev (under mdev_type node) Yan Zhao 2020-04-13 5:54 ` Yan Zhao 2020-04-15 7:28 ` Erik Skultety 2020-04-15 7:28 ` Erik Skultety 2020-04-15 8:58 ` Yan Zhao 2020-04-15 8:58 ` Yan Zhao 2020-04-13 5:54 ` [PATCH v5 2/4] drm/i915/gvt: export migration_version to mdev sysfs " Yan Zhao 2020-04-13 5:54 ` Yan Zhao 2020-04-13 5:55 ` [PATCH v5 3/4] vfio/mdev: add migration_version attribute for mdev (under mdev device node) Yan Zhao 2020-04-13 5:55 ` Yan Zhao 2020-04-15 7:42 ` Erik Skultety 2020-04-15 7:42 ` Erik Skultety 2020-04-15 9:02 ` Yan Zhao 2020-04-15 9:02 ` Yan Zhao 2020-04-13 5:55 ` [PATCH v5 4/4] drm/i915/gvt: export migration_version to mdev sysfs " Yan Zhao 2020-04-13 5:55 ` Yan Zhao 2020-04-17 8:44 ` [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration Cornelia Huck 2020-04-17 8:44 ` Cornelia Huck 2020-04-17 9:52 ` Yan Zhao 2020-04-17 9:52 ` Yan Zhao 2020-04-17 11:24 ` Cornelia Huck [this message] 2020-04-17 11:24 ` Cornelia Huck 2020-04-20 1:24 ` Yan Zhao 2020-04-20 1:24 ` Yan Zhao 2020-04-20 22:56 ` Alex Williamson 2020-04-20 22:56 ` Alex Williamson 2020-04-21 2:37 ` Yan Zhao 2020-04-21 2:37 ` Yan Zhao 2020-04-21 12:08 ` Tian, Kevin 2020-04-21 12:08 ` Tian, Kevin 2020-04-22 7:36 ` Yan Zhao 2020-04-22 7:36 ` Yan Zhao 2020-04-24 19:10 ` Dr. David Alan Gilbert 2020-04-24 19:10 ` Dr. David Alan Gilbert 2020-04-26 1:36 ` Yan Zhao 2020-04-26 1:36 ` Yan Zhao 2020-04-27 15:37 ` Dr. David Alan Gilbert 2020-04-27 15:37 ` Dr. David Alan Gilbert 2020-04-28 0:54 ` Yan Zhao 2020-04-28 0:54 ` Yan Zhao 2020-04-28 14:14 ` Dr. David Alan Gilbert 2020-04-28 14:14 ` Dr. David Alan Gilbert 2020-04-29 7:26 ` Yan Zhao 2020-04-29 7:26 ` Yan Zhao 2020-04-29 8:22 ` Dr. David Alan Gilbert 2020-04-29 8:22 ` Dr. David Alan Gilbert 2020-04-29 9:35 ` Yan Zhao 2020-04-29 9:35 ` Yan Zhao 2020-04-29 9:48 ` Dr. David Alan Gilbert 2020-04-29 9:48 ` Dr. David Alan Gilbert 2020-04-30 0:39 ` Yan Zhao 2020-04-30 0:39 ` Yan Zhao 2020-06-02 22:55 ` Alex Williamson 2020-06-02 22:55 ` Alex Williamson 2020-06-03 3:19 ` Yan Zhao 2020-06-03 3:19 ` Yan Zhao 2020-06-03 3:55 ` Alex Williamson 2020-06-03 3:55 ` Alex Williamson 2020-06-03 5:24 ` Yan Zhao 2020-06-03 5:24 ` Yan Zhao 2020-06-03 16:26 ` Alex Williamson 2020-06-03 16:26 ` Alex Williamson 2020-06-05 10:22 ` Dr. David Alan Gilbert 2020-06-05 10:22 ` Dr. David Alan Gilbert 2020-06-05 14:31 ` Alex Williamson 2020-06-05 14:31 ` Alex Williamson 2020-06-05 14:39 ` Dr. David Alan Gilbert 2020-06-05 14:39 ` Dr. David Alan Gilbert 2020-06-10 0:37 ` Yan Zhao 2020-06-10 0:37 ` Yan Zhao 2020-06-19 22:40 ` Alex Williamson 2020-06-19 22:40 ` Alex Williamson 2020-06-22 2:28 ` Yan Zhao 2020-06-22 2:28 ` Yan Zhao 2020-04-29 14:13 ` Eric Blake 2020-04-29 14:13 ` Eric Blake 2020-04-30 0:45 ` Yan Zhao 2020-04-30 0:45 ` Yan Zhao
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200417132457.45d91fe3.cohuck@redhat.com \ --to=cohuck@redhat.com \ --cc=Ken.Xue@amd.com \ --cc=Zhengxiao.zx@alibaba-inc.com \ --cc=aik@ozlabs.ru \ --cc=alex.williamson@redhat.com \ --cc=berrange@redhat.com \ --cc=changpeng.liu@intel.com \ --cc=cjia@nvidia.com \ --cc=corbet@lwn.net \ --cc=dgilbert@redhat.com \ --cc=dinechin@redhat.com \ --cc=eauger@redhat.com \ --cc=eskultet@redhat.com \ --cc=felipe@nutanix.com \ --cc=intel-gvt-dev@lists.freedesktop.org \ --cc=jonathan.davies@nutanix.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=libvir-list@redhat.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mlevitsk@redhat.com \ --cc=pasic@linux.ibm.com \ --cc=qemu-devel@nongnu.org \ --cc=shaopeng.he@intel.com \ --cc=shuangtai.tst@alibaba-inc.com \ --cc=xin.zeng@intel.com \ --cc=yan.y.zhao@intel.com \ --cc=yi.l.liu@intel.com \ --cc=zhenyuw@linux.intel.com \ --cc=zhi.a.wang@intel.com \ --cc=ziye.yang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.