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: Sun, 19 Apr 2020 21:24:57 -0400 [thread overview]
Message-ID: <20200420012457.GE16688@joy-OptiPlex-7040> (raw)
In-Reply-To: <20200417132457.45d91fe3.cohuck@redhat.com>
On Fri, Apr 17, 2020 at 07:24:57PM +0800, Cornelia Huck wrote:
> 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.
>
as you pointed below, (3) and (2) serve the same purpose.
and I think a possible usage is to migrate between a non-mdev device and
an mdev device. so I think it's better for them both to use (2) rather
than creating (3).
> >
> > > 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.
>
yes. but I think if the condition happens, it should be reported a bug
to vendor driver.
should I add a line in the doc like "vendor driver should ensure that the
migration compatibility from migration_version under mdev_type should be
consistent with that from migration_version under device node" ?
> (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.
>
hmm, is it useful for userspace to test the migration_version under mdev
type before it knows what mdev device to generate ?
like when the userspace wants to migrate an mdev device in src vm,
but it has not created target vm and the target mdev device.
> >
> > > 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?
so change (1) to migration_type_version and (2) to
migration_instance_version?
But as they are under different locations, could that location imply
enough information?
Thanks
Yan
next prev parent reply other threads:[~2020-04-20 1:34 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
2020-04-17 11:24 ` Cornelia Huck
2020-04-20 1:24 ` Yan Zhao [this message]
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=20200420012457.GE16688@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).