From: Yan Zhao <yan.y.zhao@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, libvir-list@redhat.com,
Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, kwankhede@nvidia.com, eauger@redhat.com,
xin-ran.wang@intel.com, corbet@lwn.net,
openstack-discuss@lists.openstack.org, shaohe.feng@intel.com,
kevin.tian@intel.com, eskultet@redhat.com,
jian-feng.ding@intel.com, dgilbert@redhat.com,
zhenyuw@linux.intel.com, hejie.xu@intel.com,
bao.yumeng@zte.com.cn, Sean Mooney <smooney@redhat.com>,
intel-gvt-dev@lists.freedesktop.org, berrange@redhat.com,
cohuck@redhat.com, dinechin@redhat.com, devel@ovirt.org
Subject: Re: device compatibility interface for live migration with assigned devices
Date: Tue, 4 Aug 2020 16:37:08 +0800 [thread overview]
Message-ID: <20200804083708.GA30485@joy-OptiPlex-7040> (raw)
In-Reply-To: <20200730112930.6f4c5762@x1.home>
> > yes, include a device_api field is better.
> > for mdev, "device_type=vfio-mdev", is it right?
>
> No, vfio-mdev is not a device API, it's the driver that attaches to the
> mdev bus device to expose it through vfio. The device_api exposes the
> actual interface of the vfio device, it's also vfio-pci for typical
> mdev devices found on x86, but may be vfio-ccw, vfio-ap, etc... See
> VFIO_DEVICE_API_PCI_STRING and friends.
>
ok. got it.
> > > > > device_id=8086591d
> > >
> > > Is device_id interpreted relative to device_type? How does this
> > > relate to mdev_type? If we have an mdev_type, doesn't that fully
> > > defined the software API?
> > >
> > it's parent pci id for mdev actually.
>
> If we need to specify the parent PCI ID then something is fundamentally
> wrong with the mdev_type. The mdev_type should define a unique,
> software compatible interface, regardless of the parent device IDs. If
> a i915-GVTg_V5_2 means different things based on the parent device IDs,
> then then different mdev_types should be reported for those parent
> devices.
>
hmm, then do we allow vendor specific fields?
or is it a must that a vendor specific field should have corresponding
vendor attribute?
another thing is that the definition of mdev_type in GVT only corresponds
to vGPU computing ability currently,
e.g. i915-GVTg_V5_2, is 1/2 of a gen9 IGD, i915-GVTg_V4_2 is 1/2 of a
gen8 IGD.
It is too coarse-grained to live migration compatibility.
Do you think we need to update GVT's definition of mdev_type?
And is there any guide in mdev_type definition?
> > > > > mdev_type=i915-GVTg_V5_2
> > >
> > > And how are non-mdev devices represented?
> > >
> > non-mdev can opt to not include this field, or as you said below, a
> > vendor signature.
> >
> > > > > aggregator=1
> > > > > pv_mode="none+ppgtt+context"
> > >
> > > These are meaningless vendor specific matches afaict.
> > >
> > yes, pv_mode and aggregator are vendor specific fields.
> > but they are important to decide whether two devices are compatible.
> > pv_mode means whether a vGPU supports guest paravirtualized api.
> > "none+ppgtt+context" means guest can not use pv, or use ppgtt mode pv or
> > use context mode pv.
> >
> > > > > interface_version=3
> > >
> > > Not much granularity here, I prefer Sean's previous
> > > <major>.<minor>[.bugfix] scheme.
> > >
> > yes, <major>.<minor>[.bugfix] scheme may be better, but I'm not sure if
> > it works for a complicated scenario.
> > e.g for pv_mode,
> > (1) initially, pv_mode is not supported, so it's pv_mode=none, it's 0.0.0,
> > (2) then, pv_mode=ppgtt is supported, pv_mode="none+ppgtt", it's 0.1.0,
> > indicating pv_mode=none can migrate to pv_mode="none+ppgtt", but not vice versa.
> > (3) later, pv_mode=context is also supported,
> > pv_mode="none+ppgtt+context", so it's 0.2.0.
> >
> > But if later, pv_mode=ppgtt is removed. pv_mode="none+context", how to
> > name its version? "none+ppgtt" (0.1.0) is not compatible to
> > "none+context", but "none+ppgtt+context" (0.2.0) is compatible to
> > "none+context".
>
> If pv_mode=ppgtt is removed, then the compatible versions would be
> 0.0.0 or 1.0.0, ie. the major version would be incremented due to
> feature removal.
>
> > Maintain such scheme is painful to vendor driver.
>
> Migration compatibility is painful, there's no way around that. I
> think the version scheme is an attempt to push some of that low level
> burden on the vendor driver, otherwise the management tools need to
> work on an ever growing matrix of vendor specific features which is
> going to become unwieldy and is largely meaningless outside of the
> vendor driver. Instead, the vendor driver can make strategic decisions
> about where to continue to maintain a support burden and make explicit
> decisions to maintain or break compatibility. The version scheme is a
> simplification and abstraction of vendor driver features in order to
> create a small, logical compatibility matrix. Compromises necessarily
> need to be made for that to occur.
>
ok. got it.
> > > > > COMPATIBLE:
> > > > > device_type=pci
> > > > > device_id=8086591d
> > > > > mdev_type=i915-GVTg_V5_{val1:int:1,2,4,8}
> > > > this mixed notation will be hard to parse so i would avoid that.
> > >
> > > Some background, Intel has been proposing aggregation as a solution to
> > > how we scale mdev devices when hardware exposes large numbers of
> > > assignable objects that can be composed in essentially arbitrary ways.
> > > So for instance, if we have a workqueue (wq), we might have an mdev
> > > type for 1wq, 2wq, 3wq,... Nwq. It's not really practical to expose a
> > > discrete mdev type for each of those, so they want to define a base
> > > type which is composable to other types via this aggregation. This is
> > > what this substitution and tagging is attempting to accomplish. So
> > > imagine this set of values for cases where it's not practical to unroll
> > > the values for N discrete types.
> > >
> > > > > aggregator={val1}/2
> > >
> > > So the {val1} above would be substituted here, though an aggregation
> > > factor of 1/2 is a head scratcher...
> > >
> > > > > pv_mode={val2:string:"none+ppgtt","none+context","none+ppgtt+context"}
> > >
> > > I'm lost on this one though. I think maybe it's indicating that it's
> > > compatible with any of these, so do we need to list it? Couldn't this
> > > be handled by Sean's version proposal where the minor version
> > > represents feature compatibility?
> > yes, it's indicating that it's compatible with any of these.
> > Sean's version proposal may also work, but it would be painful for
> > vendor driver to maintain the versions when multiple similar features
> > are involved.
>
> This is something vendor drivers need to consider when adding and
> removing features.
>
> > > > > interface_version={val3:int:2,3}
> > >
> > > What does this turn into in a few years, 2,7,12,23,75,96,...
> > >
> > is a range better?
>
> I was really trying to point out that sparseness becomes an issue if
> the vendor driver is largely disconnected from how their feature
> addition and deprecation affects migration support. Thanks,
>
ok. we'll use the x.y.z scheme then.
Thanks
Yan
next prev parent reply other threads:[~2020-08-04 8:49 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 23:29 device compatibility interface for live migration with assigned devices Yan Zhao
2020-07-14 10:21 ` Daniel P. Berrangé
2020-07-14 12:33 ` Sean Mooney
[not found] ` <20200714110148.0471c03c@x1.home>
[not found] ` <eb705c72cdc8b6b8959b6ebaeeac6069a718d524.camel@redhat.com>
2020-07-14 21:15 ` Sean Mooney
2020-07-14 16:16 ` Alex Williamson
2020-07-14 16:47 ` Daniel P. Berrangé
2020-07-14 20:47 ` Alex Williamson
2020-07-15 9:16 ` Daniel P. Berrangé
2020-07-14 17:19 ` Dr. David Alan Gilbert
2020-07-14 20:59 ` Alex Williamson
2020-07-15 7:37 ` Alex Xu
2020-07-17 15:18 ` Alex Williamson
2020-07-15 8:20 ` Yan Zhao
2020-07-15 8:49 ` Feng, Shaohe
2020-07-15 9:21 ` Alex Xu
2020-07-17 14:59 ` Alex Williamson
2020-07-17 18:03 ` Dr. David Alan Gilbert
2020-07-17 18:30 ` Alex Williamson
2020-07-15 8:23 ` Dr. David Alan Gilbert
2020-07-15 7:23 ` Alex Xu
2020-07-16 4:16 ` Jason Wang
2020-07-16 8:32 ` Yan Zhao
2020-07-16 9:30 ` Jason Wang
2020-07-17 16:12 ` Alex Williamson
2020-07-20 3:41 ` Jason Wang
2020-07-20 10:39 ` Sean Mooney
2020-07-21 2:11 ` Jason Wang
2020-07-21 0:51 ` Yan Zhao
2020-07-27 7:24 ` Yan Zhao
2020-07-27 22:23 ` Alex Williamson
2020-07-29 8:05 ` Yan Zhao
2020-07-29 11:28 ` Sean Mooney
2020-07-29 19:12 ` Alex Williamson
2020-07-30 3:41 ` Yan Zhao
2020-07-30 13:24 ` Sean Mooney
2020-07-30 17:29 ` Alex Williamson
2020-08-04 8:37 ` Yan Zhao [this message]
2020-08-05 9:44 ` Dr. David Alan Gilbert
2020-07-30 1:56 ` Yan Zhao
2020-07-30 13:14 ` Sean Mooney
2020-08-04 16:35 ` Cornelia Huck
2020-08-05 2:22 ` Jason Wang
2020-08-05 2:16 ` Yan Zhao
2020-08-05 2:41 ` Jason Wang
2020-08-05 7:56 ` Jiri Pirko
2020-08-05 8:02 ` Jason Wang
2020-08-05 9:33 ` Yan Zhao
2020-08-05 10:53 ` Jiri Pirko
2020-08-05 11:35 ` Sean Mooney
2020-08-07 11:59 ` Cornelia Huck
2020-08-13 15:33 ` Cornelia Huck
2020-08-13 19:02 ` Eric Farman
2020-08-17 6:38 ` Cornelia Huck
2020-08-10 7:46 ` Yan Zhao
2020-08-13 4:24 ` Jason Wang
2020-08-14 5:16 ` Yan Zhao
2020-08-14 12:30 ` Sean Mooney
2020-08-17 1:52 ` Yan Zhao
2020-08-18 3:24 ` Jason Wang
2020-08-18 8:55 ` Daniel P. Berrangé
2020-08-18 9:06 ` Cornelia Huck
2020-08-18 9:24 ` Daniel P. Berrangé
2020-08-18 9:38 ` Cornelia Huck
[not found] ` <3a073222-dcfe-c02d-198b-29f6a507b2e1@redhat.com>
2020-08-18 9:16 ` Daniel P. Berrangé
2020-08-18 9:36 ` Cornelia Huck
2020-08-18 9:39 ` Parav Pandit
2020-08-19 3:30 ` Yan Zhao
2020-08-19 5:58 ` Parav Pandit
2020-08-19 9:41 ` Jason Wang
2020-08-19 6:57 ` [ovirt-devel] " Jason Wang
2020-08-19 6:59 ` Yan Zhao
2020-08-19 7:39 ` Jason Wang
2020-08-19 8:13 ` Yan Zhao
2020-08-19 9:28 ` Jason Wang
2020-08-20 12:27 ` Cornelia Huck
2020-08-21 3:14 ` Jason Wang
2020-08-21 14:52 ` Cornelia Huck
2020-08-31 3:07 ` Jason Wang
2020-08-19 17:50 ` Alex Williamson
2020-08-20 0:18 ` Yan Zhao
2020-08-20 3:13 ` Alex Williamson
2020-08-20 3:09 ` Yan Zhao
2020-08-19 2:54 ` Jason Wang
2020-08-20 0:39 ` Yan Zhao
2020-08-20 1:29 ` Sean Mooney
2020-08-20 4:01 ` Yan Zhao
2020-08-20 5:16 ` Sean Mooney
2020-08-20 6:27 ` Yan Zhao
2020-08-20 13:24 ` Sean Mooney
2020-08-26 8:54 ` Yan Zhao
2020-08-20 3:22 ` Alex Williamson
2020-08-20 3:16 ` Yan Zhao
2020-08-25 14:39 ` Cornelia Huck
2020-08-26 6:41 ` Yan Zhao
2020-08-28 13:47 ` Cornelia Huck
2020-08-28 14:04 ` Sean Mooney
2020-08-31 4:43 ` Yan Zhao
2020-09-08 14:41 ` Cornelia Huck
2020-09-09 2:13 ` Yan Zhao
2020-09-10 12:38 ` Cornelia Huck
2020-09-10 12:50 ` Sean Mooney
2020-09-10 18:02 ` Alex Williamson
2020-09-11 0:56 ` Yan Zhao
2020-09-11 10:08 ` Cornelia Huck
2020-09-11 10:18 ` Tian, Kevin
2020-09-11 16:51 ` Alex Williamson
2020-09-14 13:48 ` Zeng, Xin
2020-09-14 14:44 ` Alex Williamson
2020-09-15 7:46 ` Zeng, Xin
2020-09-09 5:37 ` Yan Zhao
2020-08-31 2:23 ` Yan Zhao
2020-08-19 2:38 ` Jason Wang
2020-08-18 9:32 ` Parav Pandit
2020-08-19 2:45 ` Jason Wang
2020-08-19 5:26 ` Parav Pandit
2020-08-19 6:48 ` Jason Wang
2020-08-19 6:53 ` Parav Pandit
2020-07-29 19:05 ` Dr. David Alan Gilbert
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=20200804083708.GA30485@joy-OptiPlex-7040 \
--to=yan.y.zhao@intel.com \
--cc=alex.williamson@redhat.com \
--cc=bao.yumeng@zte.com.cn \
--cc=berrange@redhat.com \
--cc=cohuck@redhat.com \
--cc=corbet@lwn.net \
--cc=devel@ovirt.org \
--cc=dgilbert@redhat.com \
--cc=dinechin@redhat.com \
--cc=eauger@redhat.com \
--cc=eskultet@redhat.com \
--cc=hejie.xu@intel.com \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jasowang@redhat.com \
--cc=jian-feng.ding@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=libvir-list@redhat.com \
--cc=openstack-discuss@lists.openstack.org \
--cc=qemu-devel@nongnu.org \
--cc=shaohe.feng@intel.com \
--cc=smooney@redhat.com \
--cc=xin-ran.wang@intel.com \
--cc=zhenyuw@linux.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).