From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: "Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"cjia@nvidia.com" <cjia@nvidia.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [PATCH v8 4/6] docs: Add Documentation for Mediated devices
Date: Wed, 12 Oct 2016 09:59:55 -0600 [thread overview]
Message-ID: <20161012095955.192affc5@t450s.home> (raw)
In-Reply-To: <6814afb2-3e39-f1c9-8944-489391e948e2@nvidia.com>
On Wed, 12 Oct 2016 20:43:48 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 10/12/2016 7:22 AM, Tian, Kevin wrote:
> >> From: Kirti Wankhede [mailto:kwankhede@nvidia.com]
> >> Sent: Wednesday, October 12, 2016 4:45 AM
> >>>> +* mdev_supported_types:
> >>>> + List of current supported mediated device types and its details are added
> >>>> +in this directory in following format:
> >>>> +
> >>>> +|- <parent phy device>
> >>>> +|--- Vendor-specific-attributes [optional]
> >>>> +|--- mdev_supported_types
> >>>> +| |--- <type id>
> >>>> +| | |--- create
> >>>> +| | |--- name
> >>>> +| | |--- available_instances
> >>>> +| | |--- description /class
> >>>> +| | |--- [devices]
> >>>> +| |--- <type id>
> >>>> +| | |--- create
> >>>> +| | |--- name
> >>>> +| | |--- available_instances
> >>>> +| | |--- description /class
> >>>> +| | |--- [devices]
> >>>> +| |--- <type id>
> >>>> +| |--- create
> >>>> +| |--- name
> >>>> +| |--- available_instances
> >>>> +| |--- description /class
> >>>> +| |--- [devices]
> >>>> +
> >>>> +[TBD : description or class is yet to be decided. This will change.]
> >>>
> >>> I thought that in previous discussions we had agreed to drop
> >>> the <type id> concept and use the name as the unique identifier.
> >>> When reporting these types in libvirt we won't want to report
> >>> the type id values - we'll want the name strings to be unique.
> >>>
> >>
> >> The 'name' might not be unique but type_id will be. For example that Neo
> >> pointed out in earlier discussion, virtual devices can come from two
> >> different physical devices, end user would be presented with what they
> >> had selected but there will be internal implementation differences. In
> >> that case 'type_id' will be unique.
> >>
> >
> > Hi, Kirti, my understanding is that Neo agreed to use an unique type
> > string (if you still called it <type id>), and then no need of additional
> > 'name' field which can be put inside 'description' field. See below quote:
> >
>
> We had internal discussions about this within NVIDIA and found that
> 'name' might not be unique where as 'type_id' would be unique. I'm
> refering to Neo's mail after that, where Neo do pointed that out.
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07714.html
Everyone not privy to those internal discussions, including me, seems to
think we dropped type_id and that if a vendor does not have a stable
name, they can compose some sort of stable type description based on the
name+id, or even vendor+id, ex. NVIDIA-11. So please share why we
haven't managed to kill off type_id yet. No matter what internal
representation each vendor driver has of "type_id" it seems possible
for it to come up with stable string to define a given configuration.
Thanks,
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"cjia@nvidia.com" <cjia@nvidia.com>,
"Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices
Date: Wed, 12 Oct 2016 09:59:55 -0600 [thread overview]
Message-ID: <20161012095955.192affc5@t450s.home> (raw)
In-Reply-To: <6814afb2-3e39-f1c9-8944-489391e948e2@nvidia.com>
On Wed, 12 Oct 2016 20:43:48 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 10/12/2016 7:22 AM, Tian, Kevin wrote:
> >> From: Kirti Wankhede [mailto:kwankhede@nvidia.com]
> >> Sent: Wednesday, October 12, 2016 4:45 AM
> >>>> +* mdev_supported_types:
> >>>> + List of current supported mediated device types and its details are added
> >>>> +in this directory in following format:
> >>>> +
> >>>> +|- <parent phy device>
> >>>> +|--- Vendor-specific-attributes [optional]
> >>>> +|--- mdev_supported_types
> >>>> +| |--- <type id>
> >>>> +| | |--- create
> >>>> +| | |--- name
> >>>> +| | |--- available_instances
> >>>> +| | |--- description /class
> >>>> +| | |--- [devices]
> >>>> +| |--- <type id>
> >>>> +| | |--- create
> >>>> +| | |--- name
> >>>> +| | |--- available_instances
> >>>> +| | |--- description /class
> >>>> +| | |--- [devices]
> >>>> +| |--- <type id>
> >>>> +| |--- create
> >>>> +| |--- name
> >>>> +| |--- available_instances
> >>>> +| |--- description /class
> >>>> +| |--- [devices]
> >>>> +
> >>>> +[TBD : description or class is yet to be decided. This will change.]
> >>>
> >>> I thought that in previous discussions we had agreed to drop
> >>> the <type id> concept and use the name as the unique identifier.
> >>> When reporting these types in libvirt we won't want to report
> >>> the type id values - we'll want the name strings to be unique.
> >>>
> >>
> >> The 'name' might not be unique but type_id will be. For example that Neo
> >> pointed out in earlier discussion, virtual devices can come from two
> >> different physical devices, end user would be presented with what they
> >> had selected but there will be internal implementation differences. In
> >> that case 'type_id' will be unique.
> >>
> >
> > Hi, Kirti, my understanding is that Neo agreed to use an unique type
> > string (if you still called it <type id>), and then no need of additional
> > 'name' field which can be put inside 'description' field. See below quote:
> >
>
> We had internal discussions about this within NVIDIA and found that
> 'name' might not be unique where as 'type_id' would be unique. I'm
> refering to Neo's mail after that, where Neo do pointed that out.
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07714.html
Everyone not privy to those internal discussions, including me, seems to
think we dropped type_id and that if a vendor does not have a stable
name, they can compose some sort of stable type description based on the
name+id, or even vendor+id, ex. NVIDIA-11. So please share why we
haven't managed to kill off type_id yet. No matter what internal
representation each vendor driver has of "type_id" it seems possible
for it to come up with stable string to define a given configuration.
Thanks,
Alex
next prev parent reply other threads:[~2016-10-12 15:59 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 20:28 [PATCH v8 0/6] Add Mediated device support Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-10 20:28 ` [PATCH v8 1/6] vfio: Mediated device Core driver Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-10 21:00 ` Eric Blake
2016-10-10 21:00 ` Eric Blake
2016-10-11 3:51 ` Alex Williamson
2016-10-11 3:51 ` [Qemu-devel] " Alex Williamson
2016-10-11 20:13 ` Kirti Wankhede
2016-10-11 20:13 ` [Qemu-devel] " Kirti Wankhede
2016-10-12 8:39 ` Tian, Kevin
2016-10-12 8:39 ` [Qemu-devel] " Tian, Kevin
2016-10-10 20:28 ` [PATCH v8 2/6] vfio: VFIO based driver for Mediated devices Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-11 3:55 ` Alex Williamson
2016-10-11 3:55 ` [Qemu-devel] " Alex Williamson
2016-10-11 20:24 ` Kirti Wankhede
2016-10-11 20:24 ` [Qemu-devel] " Kirti Wankhede
2016-10-10 20:28 ` [PATCH v8 3/6] vfio iommu: Add support for mediated devices Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-11 22:06 ` Alex Williamson
2016-10-11 22:06 ` [Qemu-devel] " Alex Williamson
2016-10-12 10:38 ` Tian, Kevin
2016-10-12 10:38 ` [Qemu-devel] " Tian, Kevin
2016-10-13 14:34 ` Kirti Wankhede
2016-10-13 14:34 ` [Qemu-devel] " Kirti Wankhede
2016-10-13 17:12 ` Alex Williamson
2016-10-13 17:12 ` [Qemu-devel] " Alex Williamson
2016-10-12 10:31 ` Tian, Kevin
2016-10-12 10:31 ` [Qemu-devel] " Tian, Kevin
2016-10-14 11:35 ` Kirti Wankhede
2016-10-14 11:35 ` [Qemu-devel] " Kirti Wankhede
2016-10-14 12:29 ` Tian, Kevin
2016-10-14 12:29 ` [Qemu-devel] " Tian, Kevin
2016-10-10 20:28 ` [PATCH v8 4/6] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-11 14:14 ` Daniel P. Berrange
2016-10-11 20:44 ` Kirti Wankhede
2016-10-11 20:44 ` Kirti Wankhede
2016-10-12 1:52 ` Tian, Kevin
2016-10-12 1:52 ` [Qemu-devel] " Tian, Kevin
2016-10-12 15:13 ` Kirti Wankhede
2016-10-12 15:13 ` [Qemu-devel] " Kirti Wankhede
2016-10-12 15:59 ` Alex Williamson [this message]
2016-10-12 15:59 ` Alex Williamson
2016-10-12 19:02 ` Kirti Wankhede
2016-10-12 19:02 ` [Qemu-devel] " Kirti Wankhede
2016-10-12 21:44 ` Alex Williamson
2016-10-13 9:22 ` Kirti Wankhede
2016-10-13 14:36 ` Alex Williamson
2016-10-13 14:36 ` [Qemu-devel] " Alex Williamson
2016-10-13 16:00 ` Paolo Bonzini
2016-10-13 16:00 ` [Qemu-devel] " Paolo Bonzini
2016-10-13 16:30 ` Alex Williamson
2016-10-14 3:31 ` Kirti Wankhede
2016-10-14 4:22 ` Alex Williamson
2016-10-14 4:22 ` [Qemu-devel] " Alex Williamson
2016-10-13 3:27 ` Tian, Kevin
2016-10-13 3:27 ` [Qemu-devel] " Tian, Kevin
2016-10-14 2:22 ` Jike Song
2016-10-14 2:22 ` [Qemu-devel] " Jike Song
2016-10-14 3:15 ` Kirti Wankhede
2016-10-14 3:15 ` [Qemu-devel] " Kirti Wankhede
2016-10-10 20:28 ` [PATCH v8 5/6] Add simple sample driver for mediated device framework Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-10 20:28 ` [PATCH v8 6/6] Add common functions for SET_IRQS and GET_REGION_INFO ioctls Kirti Wankhede
2016-10-10 20:28 ` [Qemu-devel] " Kirti Wankhede
2016-10-11 23:18 ` Alex Williamson
2016-10-11 23:18 ` [Qemu-devel] " Alex Williamson
2016-10-12 19:37 ` Kirti Wankhede
2016-10-12 19:37 ` [Qemu-devel] " Kirti Wankhede
2016-10-11 2:23 ` [PATCH v8 0/6] Add Mediated device support Jike Song
2016-10-11 2:23 ` [Qemu-devel] " Jike Song
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=20161012095955.192affc5@t450s.home \
--to=alex.williamson@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=cjia@nvidia.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 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.