From: Yan Zhao <yan.y.zhao@intel.com>
To: Cornelia Huck <cohuck@redhat.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 05:52:02 -0400 [thread overview]
Message-ID: <20200417095202.GD16688@joy-OptiPlex-7040> (raw)
In-Reply-To: <20200417104450.2d2f2fa9.cohuck@redhat.com>
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.
> Is existence (and compatibility) of (1) a pre-req for possible
> existence (and compatibility) of (2)?
>
no. (2) does not reply on (1).
> 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.
> 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?
Thanks
Yan
> >
> > Patch 1 defines migration_version attribute for the first location in
> > Documentation/vfio-mediated-device.txt
> >
> > Patch 2 uses GVT as an example for patch 1 to show how to expose
> > migration_version attribute and check migration compatibility in vendor
> > driver.
> >
> > Patch 3 defines migration_version attribute for the second location in
> > Documentation/vfio-mediated-device.txt
> >
> > Patch 4 uses GVT as an example for patch 3 to show how to expose
> > migration_version attribute and check migration compatibility in vendor
> > driver.
> >
> > (The previous "Reviewed-by" and "Acked-by" for patch 1 and patch 2 are
> > kept in v5, as there are only small changes to commit messages of the two
> > patches.)
> >
> > v5:
> > added patch 2 and 4 for mdev device part of migration_version attribute.
> >
> > v4:
> > 1. fixed indentation/spell errors, reworded several error messages
> > 2. added a missing memory free for error handling in patch 2
> >
> > v3:
> > 1. renamed version to migration_version
> > 2. let errno to be freely defined by vendor driver
> > 3. let checking mdev_type be prerequisite of migration compatibility check
> > 4. reworded most part of patch 1
> > 5. print detailed error log in patch 2 and generate migration_version
> > string at init time
> >
> > v2:
> > 1. renamed patched 1
> > 2. made definition of device version string completely private to vendor
> > driver
> > 3. reverted changes to sample mdev drivers
> > 4. described intent and usage of version attribute more clearly.
> >
> >
> > Yan Zhao (4):
> > vfio/mdev: add migration_version attribute for mdev (under mdev_type
> > node)
> > drm/i915/gvt: export migration_version to mdev sysfs (under mdev_type
> > node)
> > vfio/mdev: add migration_version attribute for mdev (under mdev device
> > node)
> > drm/i915/gvt: export migration_version to mdev sysfs (under mdev
> > device node)
> >
> > .../driver-api/vfio-mediated-device.rst | 183 ++++++++++++++++++
> > drivers/gpu/drm/i915/gvt/Makefile | 2 +-
> > drivers/gpu/drm/i915/gvt/gvt.c | 39 ++++
> > drivers/gpu/drm/i915/gvt/gvt.h | 7 +
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 55 ++++++
> > drivers/gpu/drm/i915/gvt/migration_version.c | 170 ++++++++++++++++
> > drivers/gpu/drm/i915/gvt/vgpu.c | 13 +-
> > 7 files changed, 466 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/gvt/migration_version.c
> >
>
next prev parent reply other threads:[~2020-04-17 10:01 UTC|newest]
Thread overview: 40+ 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:54 ` [PATCH v5 1/4] vfio/mdev: add migration_version attribute for mdev (under mdev_type node) Yan Zhao
2020-04-15 7:28 ` Erik Skultety
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:55 ` [PATCH v5 3/4] vfio/mdev: add migration_version attribute for mdev (under mdev device node) Yan Zhao
2020-04-15 7:42 ` Erik Skultety
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-17 8:44 ` [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration Cornelia Huck
2020-04-17 9:52 ` Yan Zhao [this message]
2020-04-17 11:24 ` Cornelia Huck
2020-04-20 1:24 ` Yan Zhao
2020-04-20 22:56 ` Alex Williamson
2020-04-21 2:37 ` Yan Zhao
2020-04-21 12:08 ` Tian, Kevin
2020-04-22 7:36 ` Yan Zhao
2020-04-24 19:10 ` Dr. David Alan Gilbert
2020-04-26 1:36 ` Yan Zhao
2020-04-27 15:37 ` Dr. David Alan Gilbert
2020-04-28 0:54 ` Yan Zhao
2020-04-28 14:14 ` Dr. David Alan Gilbert
2020-04-29 7:26 ` Yan Zhao
2020-04-29 8:22 ` Dr. David Alan Gilbert
2020-04-29 9:35 ` Yan Zhao
2020-04-29 9:48 ` Dr. David Alan Gilbert
2020-04-30 0:39 ` Yan Zhao
2020-06-02 22:55 ` Alex Williamson
2020-06-03 3:19 ` Yan Zhao
2020-06-03 3:55 ` Alex Williamson
2020-06-03 5:24 ` Yan Zhao
2020-06-03 16:26 ` Alex Williamson
2020-06-05 10:22 ` Dr. David Alan Gilbert
2020-06-05 14:31 ` Alex Williamson
2020-06-05 14:39 ` Dr. David Alan Gilbert
2020-06-10 0:37 ` Yan Zhao
2020-06-19 22:40 ` Alex Williamson
2020-06-22 2:28 ` Yan Zhao
2020-04-29 14:13 ` Eric Blake
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=20200417095202.GD16688@joy-OptiPlex-7040 \
--to=yan.y.zhao@intel.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=cohuck@redhat.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=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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).