diff mbox

[v9,10/12] vfio: Add function to get device_api string from vfio_device_info.flags

Message ID 1476739332-4911-11-git-send-email-kwankhede@nvidia.com
State New
Headers show

Commit Message

Kirti Wankhede Oct. 17, 2016, 9:22 p.m. UTC
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 <kwankhede@nvidia.com>
Signed-off-by: Neo Jia <cjia@nvidia.com>
Change-Id: I42d29f475f02a7132ce13297fbf2b48f1da10995
---
 drivers/vfio/vfio.c  | 15 +++++++++++++++
 include/linux/vfio.h |  2 ++
 2 files changed, 17 insertions(+)

Comments

Alex Williamson Oct. 20, 2016, 7:34 p.m. UTC | #1
On Tue, 18 Oct 2016 02:52:10 +0530
Kirti Wankhede <kwankhede@nvidia.com> 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 <kwankhede@nvidia.com>
> Signed-off-by: Neo Jia <cjia@nvidia.com>
> 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.
Kirti Wankhede Oct. 20, 2016, 8:29 p.m. UTC | #2
On 10/21/2016 1:04 AM, Alex Williamson wrote:
> On Tue, 18 Oct 2016 02:52:10 +0530
> Kirti Wankhede <kwankhede@nvidia.com> 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 <kwankhede@nvidia.com>
>> Signed-off-by: Neo Jia <cjia@nvidia.com>
>> 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.
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.

Kirti
Alex Williamson Oct. 20, 2016, 9:05 p.m. UTC | #3
On Fri, 21 Oct 2016 01:59:55 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> On 10/21/2016 1:04 AM, Alex Williamson wrote:
> > On Tue, 18 Oct 2016 02:52:10 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> 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 <kwankhede@nvidia.com>
> >> Signed-off-by: Neo Jia <cjia@nvidia.com>
> >> 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
Kirti Wankhede Oct. 20, 2016, 9:14 p.m. UTC | #4
On 10/21/2016 2:35 AM, Alex Williamson wrote:
> On Fri, 21 Oct 2016 01:59:55 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> 
>> On 10/21/2016 1:04 AM, Alex Williamson wrote:
>>> On Tue, 18 Oct 2016 02:52:10 +0530
>>> Kirti Wankhede <kwankhede@nvidia.com> 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 <kwankhede@nvidia.com>
>>>> Signed-off-by: Neo Jia <cjia@nvidia.com>
>>>> 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,
> 

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);

Kirti
Alex Williamson Oct. 20, 2016, 9:22 p.m. UTC | #5
On Fri, 21 Oct 2016 02:44:37 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> On 10/21/2016 2:35 AM, Alex Williamson wrote:
> > On Fri, 21 Oct 2016 01:59:55 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >   
> >> On 10/21/2016 1:04 AM, Alex Williamson wrote:  
> >>> On Tue, 18 Oct 2016 02:52:10 +0530
> >>> Kirti Wankhede <kwankhede@nvidia.com> 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 <kwankhede@nvidia.com>
> >>>> Signed-off-by: Neo Jia <cjia@nvidia.com>
> >>>> 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,
> >   
> 
> 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,

Alex
Kirti Wankhede Oct. 21, 2016, 3 a.m. UTC | #6
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
Alex Williamson Oct. 21, 2016, 3:20 a.m. UTC | #7
On Fri, 21 Oct 2016 08:30:53 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> 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?

a) The function doesn't solve that problem, as seen in the mtty sample
driver there's no guarantee that the vendor driver passes
device_info.flags vs the #define for the flag itself.  So we're already
expecting them to get it right in two separate places.

b) It's not going to take them very long to figure this out if they
care about userspace tools that make use of this field to determine the
device API.  This is a very obvious and simple bug.

c) We can check and correct how open source vendor drivers work.

Thanks,
Alex
diff mbox

Patch

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);