From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags Date: Thu, 20 Oct 2016 15:05:01 -0600 Message-ID: <20161020150501.39f28c7e@t450s.home> References: <1476739332-4911-1-git-send-email-kwankhede@nvidia.com> <1476739332-4911-11-git-send-email-kwankhede@nvidia.com> <20161020133403.08828f47@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: , , , , , , , , To: Kirti Wankhede Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35290 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755365AbcJTVFE (ORCPT ); Thu, 20 Oct 2016 17:05:04 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 21 Oct 2016 01:59:55 +0530 Kirti Wankhede wrote: > On 10/21/2016 1:04 AM, Alex Williamson wrote: > > On Tue, 18 Oct 2016 02:52:10 +0530 > > Kirti Wankhede wrote: > > > >> Function vfio_device_api_string() returns string based on flag set in > >> vfio_device_info's flag. This should be used by vendor driver to get string > >> based on flag for device_api attribute. > >> > >> Signed-off-by: Kirti Wankhede > >> Signed-off-by: Neo Jia > >> Change-Id: I42d29f475f02a7132ce13297fbf2b48f1da10995 > >> --- > >> drivers/vfio/vfio.c | 15 +++++++++++++++ > >> include/linux/vfio.h | 2 ++ > >> 2 files changed, 17 insertions(+) > >> > >> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c > >> index 10ef1c5fa762..aec470454a13 100644 > >> --- a/drivers/vfio/vfio.c > >> +++ b/drivers/vfio/vfio.c > >> @@ -1917,6 +1917,21 @@ int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs, > >> } > >> EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare); > >> > >> +const char *vfio_device_api_string(u32 flags) > >> +{ > >> + if (flags & VFIO_DEVICE_FLAGS_PCI) > >> + return "vfio-pci"; > >> + > >> + if (flags & VFIO_DEVICE_FLAGS_PLATFORM) > >> + return "vfio-platform"; > >> + > >> + if (flags & VFIO_DEVICE_FLAGS_AMBA) > >> + return "vfio-amba"; > >> + > >> + return ""; > >> +} > >> +EXPORT_SYMBOL(vfio_device_api_string); > >> + > >> /* > >> * Pin a set of guest PFNs and return their associated host PFNs for local > >> * domain only. > >> diff --git a/include/linux/vfio.h b/include/linux/vfio.h > >> index 31d059f1649b..fca2bf23c4f1 100644 > >> --- a/include/linux/vfio.h > >> +++ b/include/linux/vfio.h > >> @@ -116,6 +116,8 @@ extern int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, > >> int num_irqs, int max_irq_type, > >> size_t *data_size); > >> > >> +extern const char *vfio_device_api_string(u32 flags); > >> + > >> struct pci_dev; > >> #ifdef CONFIG_EEH > >> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev); > > > > Couldn't this simply be a #define in the uapi header? > > > > #define VFIO_DEVICE_PCI_API_STRING "vfio-pci" > > > > I don't really see why we need a lookup function. > > > > String is tightly coupled with the FLAG, right? > Instead user need to take care of making sure to return proper string, > and don't mis-match the string, I think having function is easier. That's exactly why I proposed putting the #define string in the uapi, by that I mean the vfio uapi header. That keeps the tight coupling to the flag, they're both defined in the same place, plus it gives userspace a reference so they're not just inventing a string to compare against. IOW, the vendor driver simply does an sprintf of VFIO_DEVICE_PCI_API_STRING and userspace (ie. libvirt) can do a strcmp with VFIO_DEVICE_PCI_API_STRING from the same header and everybody arrives at the same result. > Vendor driver should decide the type of device they want to expose and > set the flag, using this function vendor driver would return string > which is based on flag they set. Being a function adds no intrinsic value and being in a uapi header does add value to userspace. Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxKWT-0002o0-Fp for qemu-devel@nongnu.org; Thu, 20 Oct 2016 17:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxKWO-0005We-U2 for qemu-devel@nongnu.org; Thu, 20 Oct 2016 17:05:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57596) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxKWO-0005VQ-MP for qemu-devel@nongnu.org; Thu, 20 Oct 2016 17:05:04 -0400 Date: Thu, 20 Oct 2016 15:05:01 -0600 From: Alex Williamson Message-ID: <20161020150501.39f28c7e@t450s.home> In-Reply-To: References: <1476739332-4911-1-git-send-email-kwankhede@nvidia.com> <1476739332-4911-11-git-send-email-kwankhede@nvidia.com> <20161020133403.08828f47@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirti Wankhede Cc: pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com, jike.song@intel.com, bjsdjshi@linux.vnet.ibm.com, linux-kernel@vger.kernel.org On Fri, 21 Oct 2016 01:59:55 +0530 Kirti Wankhede wrote: > On 10/21/2016 1:04 AM, Alex Williamson wrote: > > On Tue, 18 Oct 2016 02:52:10 +0530 > > Kirti Wankhede wrote: > > > >> Function vfio_device_api_string() returns string based on flag set in > >> vfio_device_info's flag. This should be used by vendor driver to get string > >> based on flag for device_api attribute. > >> > >> Signed-off-by: Kirti Wankhede > >> Signed-off-by: Neo Jia > >> Change-Id: I42d29f475f02a7132ce13297fbf2b48f1da10995 > >> --- > >> drivers/vfio/vfio.c | 15 +++++++++++++++ > >> include/linux/vfio.h | 2 ++ > >> 2 files changed, 17 insertions(+) > >> > >> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c > >> index 10ef1c5fa762..aec470454a13 100644 > >> --- a/drivers/vfio/vfio.c > >> +++ b/drivers/vfio/vfio.c > >> @@ -1917,6 +1917,21 @@ int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs, > >> } > >> EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare); > >> > >> +const char *vfio_device_api_string(u32 flags) > >> +{ > >> + if (flags & VFIO_DEVICE_FLAGS_PCI) > >> + return "vfio-pci"; > >> + > >> + if (flags & VFIO_DEVICE_FLAGS_PLATFORM) > >> + return "vfio-platform"; > >> + > >> + if (flags & VFIO_DEVICE_FLAGS_AMBA) > >> + return "vfio-amba"; > >> + > >> + return ""; > >> +} > >> +EXPORT_SYMBOL(vfio_device_api_string); > >> + > >> /* > >> * Pin a set of guest PFNs and return their associated host PFNs for local > >> * domain only. > >> diff --git a/include/linux/vfio.h b/include/linux/vfio.h > >> index 31d059f1649b..fca2bf23c4f1 100644 > >> --- a/include/linux/vfio.h > >> +++ b/include/linux/vfio.h > >> @@ -116,6 +116,8 @@ extern int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, > >> int num_irqs, int max_irq_type, > >> size_t *data_size); > >> > >> +extern const char *vfio_device_api_string(u32 flags); > >> + > >> struct pci_dev; > >> #ifdef CONFIG_EEH > >> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev); > > > > Couldn't this simply be a #define in the uapi header? > > > > #define VFIO_DEVICE_PCI_API_STRING "vfio-pci" > > > > I don't really see why we need a lookup function. > > > > String is tightly coupled with the FLAG, right? > Instead user need to take care of making sure to return proper string, > and don't mis-match the string, I think having function is easier. That's exactly why I proposed putting the #define string in the uapi, by that I mean the vfio uapi header. That keeps the tight coupling to the flag, they're both defined in the same place, plus it gives userspace a reference so they're not just inventing a string to compare against. IOW, the vendor driver simply does an sprintf of VFIO_DEVICE_PCI_API_STRING and userspace (ie. libvirt) can do a strcmp with VFIO_DEVICE_PCI_API_STRING from the same header and everybody arrives at the same result. > Vendor driver should decide the type of device they want to expose and > set the flag, using this function vendor driver would return string > which is based on flag they set. Being a function adds no intrinsic value and being in a uapi header does add value to userspace. Thanks, Alex