All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirti Wankhede <kwankhede@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
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>
Subject: Re: [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags
Date: Fri, 21 Oct 2016 08:30:53 +0530	[thread overview]
Message-ID: <3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com> (raw)
In-Reply-To: <20161020152220.57f6ee06@t450s.home>



On 10/21/2016 2:52 AM, Alex Williamson wrote:
> On Fri, 21 Oct 2016 02:44:37 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> 
...

>>>>>>  
>>>>>> +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,
>>>   
>>
>> Ok. The strings should be in uapi, but having function (like below) to
>> return proper string based on flag would be good to have for vendor driver.
>>
>>  +const char *vfio_device_api_string(u32 flags)
>>  +{
>>  +	if (flags & VFIO_DEVICE_FLAGS_PCI)
>>  +		return VFIO_DEVICE_API_PCI_STRING;
>>  +
>>  +	if (flags & VFIO_DEVICE_FLAGS_PLATFORM)
>>  +		return VFIO_DEVICE_API_PLATFORM_STRING;
>>  +
>>  +	if (flags & VFIO_DEVICE_FLAGS_AMBA)
>>  +		return VFIO_DEVICE_API_AMBA_STRING;
>>  +
>>  +	return "";
>>  +}
>>  +EXPORT_SYMBOL(vfio_device_api_string);
> 
> I disagree, it's pointless maintenance overhead.  It's yet another
> function that we need to care about for kABI and it offers almost no
> value.  Thanks,
> 

If any vendor driver sets VFIO_DEVICE_FLAGS_PLATFORM flag but sets
VFIO_DEVICE_API_PCI_STRING, we don't have a way to verify this in kernel
driver. Is that acceptable?


Kirti

WARNING: multiple messages have this Message-ID (diff)
From: Kirti Wankhede <kwankhede@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
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
Subject: Re: [Qemu-devel] [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags
Date: Fri, 21 Oct 2016 08:30:53 +0530	[thread overview]
Message-ID: <3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com> (raw)
In-Reply-To: <20161020152220.57f6ee06@t450s.home>



On 10/21/2016 2:52 AM, Alex Williamson wrote:
> On Fri, 21 Oct 2016 02:44:37 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> 
...

>>>>>>  
>>>>>> +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,
>>>   
>>
>> Ok. The strings should be in uapi, but having function (like below) to
>> return proper string based on flag would be good to have for vendor driver.
>>
>>  +const char *vfio_device_api_string(u32 flags)
>>  +{
>>  +	if (flags & VFIO_DEVICE_FLAGS_PCI)
>>  +		return VFIO_DEVICE_API_PCI_STRING;
>>  +
>>  +	if (flags & VFIO_DEVICE_FLAGS_PLATFORM)
>>  +		return VFIO_DEVICE_API_PLATFORM_STRING;
>>  +
>>  +	if (flags & VFIO_DEVICE_FLAGS_AMBA)
>>  +		return VFIO_DEVICE_API_AMBA_STRING;
>>  +
>>  +	return "";
>>  +}
>>  +EXPORT_SYMBOL(vfio_device_api_string);
> 
> I disagree, it's pointless maintenance overhead.  It's yet another
> function that we need to care about for kABI and it offers almost no
> value.  Thanks,
> 

If any vendor driver sets VFIO_DEVICE_FLAGS_PLATFORM flag but sets
VFIO_DEVICE_API_PCI_STRING, we don't have a way to verify this in kernel
driver. Is that acceptable?


Kirti

  reply	other threads:[~2016-10-21  3:01 UTC|newest]

Thread overview: 148+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 21:22 [PATCH v9 00/12] Add Mediated device support Kirti Wankhede
2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 01/12] vfio: Mediated device Core driver Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-18 23:16   ` Alex Williamson
2016-10-18 23:16     ` [Qemu-devel] " Alex Williamson
2016-10-19 19:16     ` Kirti Wankhede
2016-10-19 19:16       ` [Qemu-devel] " Kirti Wankhede
2016-10-19 22:20       ` Alex Williamson
2016-10-19 22:20         ` [Qemu-devel] " Alex Williamson
2016-10-19 22:20         ` Alex Williamson
2016-10-20  7:23   ` Jike Song
2016-10-20  7:23     ` [Qemu-devel] " Jike Song
2016-10-20 17:12     ` Alex Williamson
2016-10-20 17:12       ` [Qemu-devel] " Alex Williamson
2016-10-21  2:41       ` Jike Song
2016-10-21  2:41         ` [Qemu-devel] " Jike Song
2016-10-27  5:56       ` Jike Song
2016-10-27  5:56         ` [Qemu-devel] " Jike Song
2016-10-26  6:52   ` Tian, Kevin
2016-10-26  6:52     ` [Qemu-devel] " Tian, Kevin
2016-10-26 14:58     ` Kirti Wankhede
2016-10-26 14:58       ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 02/12] vfio: VFIO based driver for Mediated devices Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-26  6:57   ` Tian, Kevin
2016-10-26  6:57     ` [Qemu-devel] " Tian, Kevin
2016-10-26 15:01     ` Kirti Wankhede
2016-10-26 15:01       ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 03/12] vfio: Rearrange functions to get vfio_group from dev Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-19 17:26   ` Alex Williamson
2016-10-19 17:26     ` [Qemu-devel] " Alex Williamson
2016-10-17 21:22 ` [PATCH v9 04/12] vfio iommu: Add support for mediated devices Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22   ` Kirti Wankhede
2016-10-19 21:02   ` Alex Williamson
2016-10-19 21:02     ` [Qemu-devel] " Alex Williamson
2016-10-20 20:17     ` Kirti Wankhede
2016-10-20 20:17       ` [Qemu-devel] " Kirti Wankhede
2016-10-24  2:32       ` Alex Williamson
2016-10-24  2:32         ` [Qemu-devel] " Alex Williamson
2016-10-26  7:19         ` Tian, Kevin
2016-10-26  7:19           ` [Qemu-devel] " Tian, Kevin
2016-10-26 15:06           ` Kirti Wankhede
2016-10-26 15:06             ` [Qemu-devel] " Kirti Wankhede
2016-10-26  7:53     ` Tian, Kevin
2016-10-26  7:53       ` [Qemu-devel] " Tian, Kevin
2016-10-26 15:16       ` Alex Williamson
2016-10-26 15:16         ` [Qemu-devel] " Alex Williamson
2016-10-26  7:54     ` Tian, Kevin
2016-10-26  7:54       ` [Qemu-devel] " Tian, Kevin
2016-10-26 15:19       ` Alex Williamson
2016-10-26 15:19         ` [Qemu-devel] " Alex Williamson
2016-10-21  7:49   ` Jike Song
2016-10-21  7:49     ` [Qemu-devel] " Jike Song
2016-10-21 14:36     ` Alex Williamson
2016-10-21 14:36       ` [Qemu-devel] " Alex Williamson
2016-10-24 10:35       ` Kirti Wankhede
2016-10-24 10:35         ` [Qemu-devel] " Kirti Wankhede
2016-10-27  7:20   ` Alexey Kardashevskiy
2016-10-27 12:31     ` Kirti Wankhede
2016-10-27 12:31       ` Kirti Wankhede
2016-10-27 12:31       ` Kirti Wankhede
2016-10-27 14:30       ` [Qemu-devel] " Alex Williamson
2016-10-27 14:30         ` Alex Williamson
2016-10-27 14:30         ` Alex Williamson
2016-10-27 15:59         ` [Qemu-devel] " Kirti Wankhede
2016-10-27 15:59           ` Kirti Wankhede
2016-10-28  2:18       ` Alexey Kardashevskiy
2016-11-01 14:01         ` Kirti Wankhede
2016-11-01 14:01           ` Kirti Wankhede
2016-11-02  1:24           ` Alexey Kardashevskiy
2016-11-02  3:29             ` Kirti Wankhede
2016-11-02  3:29               ` Kirti Wankhede
2016-11-02  4:09               ` Alexey Kardashevskiy
2016-11-02 12:21                 ` Jike Song
2016-11-02 12:21                   ` Jike Song
2016-11-02 12:41                   ` [Qemu-devel] " Kirti Wankhede
2016-11-02 12:41                     ` Kirti Wankhede
2016-11-02 13:00                     ` Jike Song
2016-11-02 13:18                       ` Kirti Wankhede
2016-11-02 13:18                         ` Kirti Wankhede
2016-11-02 13:35                         ` Jike Song
2016-11-02 13:35                           ` Jike Song
2016-11-03  4:29                         ` [Qemu-devel] " Alexey Kardashevskiy
2016-11-03  4:29                           ` Alexey Kardashevskiy
2016-10-17 21:22 ` [PATCH v9 05/12] vfio: Introduce common function to add capabilities Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-20 19:24   ` Alex Williamson
2016-10-20 19:24     ` [Qemu-devel] " Alex Williamson
2016-10-24 21:27     ` Kirti Wankhede
2016-10-24 21:27       ` [Qemu-devel] " Kirti Wankhede
2016-10-24 21:39       ` Alex Williamson
2016-10-24 21:39         ` [Qemu-devel] " Alex Williamson
2016-10-17 21:22 ` [PATCH v9 06/12] vfio_pci: Update vfio_pci to use vfio_info_add_capability() Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-20 19:24   ` Alex Williamson
2016-10-20 19:24     ` [Qemu-devel] " Alex Williamson
2016-10-24 21:22     ` Kirti Wankhede
2016-10-24 21:22       ` [Qemu-devel] " Kirti Wankhede
2016-10-24 21:37       ` Alex Williamson
2016-10-24 21:37         ` [Qemu-devel] " Alex Williamson
2016-10-17 21:22 ` [PATCH v9 07/12] vfio: Introduce vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 08/12] vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 09/12] vfio_platform: " Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-17 21:22 ` [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-20 19:34   ` Alex Williamson
2016-10-20 19:34     ` [Qemu-devel] " Alex Williamson
2016-10-20 20:29     ` Kirti Wankhede
2016-10-20 20:29       ` [Qemu-devel] " Kirti Wankhede
2016-10-20 21:05       ` Alex Williamson
2016-10-20 21:05         ` [Qemu-devel] " Alex Williamson
2016-10-20 21:14         ` Kirti Wankhede
2016-10-20 21:14           ` [Qemu-devel] " Kirti Wankhede
2016-10-20 21:22           ` Alex Williamson
2016-10-20 21:22             ` [Qemu-devel] " Alex Williamson
2016-10-21  3:00             ` Kirti Wankhede [this message]
2016-10-21  3:00               ` Kirti Wankhede
2016-10-21  3:20               ` Alex Williamson
2016-10-21  3:20                 ` [Qemu-devel] " Alex Williamson
2016-10-17 21:22 ` [PATCH v9 11/12] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-25 16:17   ` Alex Williamson
2016-10-25 16:17     ` [Qemu-devel] " Alex Williamson
2016-10-17 21:22 ` [PATCH v9 12/12] docs: Sample driver to demonstrate how to use Mediated device framework Kirti Wankhede
2016-10-17 21:22   ` [Qemu-devel] " Kirti Wankhede
2016-10-18  2:54   ` Dong Jia Shi
2016-10-18 17:17     ` Alex Williamson
2016-10-18 17:17       ` [Qemu-devel] " Alex Williamson
2016-10-19 19:19       ` Kirti Wankhede
2016-10-19 19:19         ` [Qemu-devel] " Kirti Wankhede
2016-10-18  2:54   ` Dong Jia Shi
2016-10-17 21:41 ` [PATCH v9 00/12] Add Mediated device support Alex Williamson
2016-10-17 21:41   ` [Qemu-devel] " Alex Williamson
2016-10-24  7:07 ` Jike Song
2016-10-24  7:07   ` [Qemu-devel] " Jike Song
2016-12-05 17:44   ` Gerd Hoffmann
2016-12-05 17:44     ` [Qemu-devel] " Gerd Hoffmann
2016-12-05 17:44     ` Gerd Hoffmann
2016-12-06  2:24     ` Jike Song
2016-12-06  2:24       ` [Qemu-devel] " Jike Song
2016-12-07 14:40       ` Gerd Hoffmann
2016-12-07 14:40         ` [Qemu-devel] " Gerd Hoffmann

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=3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com \
    --to=kwankhede@nvidia.com \
    --cc=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=linux-kernel@vger.kernel.org \
    --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.