All of lore.kernel.org
 help / color / mirror / Atom feed
From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 5/9] VFIO: Extend external user API
Date: Wed, 27 Aug 2014 17:20:46 +0200	[thread overview]
Message-ID: <53FDF74E.6000201@linaro.org> (raw)
In-Reply-To: <1409079734.2906.129.camel@ul30vt.home>

On 08/26/2014 09:02 PM, Alex Williamson wrote:
> On Mon, 2014-08-25 at 15:27 +0200, Eric Auger wrote:
>> New functions are added to be called from ARM KVM-VFIO device.
>>
>> - vfio_device_get_external_user enables to get a vfio device from
>>   its fd
>> - vfio_device_put_external_user puts the vfio device
>> - vfio_external_get_type enables to retrieve the type of the device
>>   (PCI or platform)
>> - vfio_external_get_base_device enables to get the
>>   struct device*, useful to access the platform_device
>>
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>> ---
>>  drivers/vfio/vfio.c  | 35 +++++++++++++++++++++++++++++++++++
>>  include/linux/vfio.h |  4 ++++
>>  2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>> index 8e84471..c93b9e4 100644
>> --- a/drivers/vfio/vfio.c
>> +++ b/drivers/vfio/vfio.c
>> @@ -1401,6 +1401,41 @@ void vfio_group_put_external_user(struct vfio_group *group)
>>  }
>>  EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
>>  
>> +struct vfio_device *vfio_device_get_external_user(struct file *filep)
>> +{
>> +	struct vfio_device *vdev = filep->private_data;
>> +
>> +	if (filep->f_op != &vfio_device_fops)
>> +		return ERR_PTR(-EINVAL);
>> +
>> +	vfio_device_get(vdev);
>> +	return vdev;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_device_get_external_user);
>> +
>> +void vfio_device_put_external_user(struct vfio_device *vdev)
>> +{
>> +	vfio_device_put(vdev);
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_device_put_external_user);
>> +
>> +int vfio_external_get_type(struct vfio_device *vdev)
>> +{
>> +	if (!strcmp(vdev->ops->name,  "vfio-platform"))
>> +		return VFIO_DEVICE_FLAGS_PLATFORM;
>> +	else if (!strcmp(vdev->ops->name,  "vfio-pci"))
>> +		return VFIO_DEVICE_FLAGS_PCI;
>> +	else
>> +		return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_external_get_type);
> 
> Returning the bit of the flag we use in get_device_info looks rather
> sloppy here.  Should we define a new enum for use with this?  Actually,
> is this interface even necessary?  If we can get the struct device then
> we can get the bus_type and keep vfio out of this.

thanks for the nit. I will try to get rid of it using it.
> 
> For both of these last two, I like to use the convention that where
> there is a "get" there is a matching "put".  These aren't reference
> counting anything, so let's not use get in the name.

I will rename.

Thanks

Eric
> 
>> +
>> +struct device *vfio_external_get_base_device(struct vfio_device *vdev)
>> +{
>> +	return vdev->dev;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_external_get_base_device);
>> +
> 
> Looks almost too simple, but reviewing the object lifecycles, this all
> looks safe.  Thanks,
> 
> Alex
> 
>>  int vfio_external_user_iommu_id(struct vfio_group *group)
>>  {
>>  	return iommu_group_id(group->iommu_group);
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index ffe04ed..19e98eb 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -99,6 +99,10 @@ extern void vfio_group_put_external_user(struct vfio_group *group);
>>  extern int vfio_external_user_iommu_id(struct vfio_group *group);
>>  extern long vfio_external_check_extension(struct vfio_group *group,
>>  					  unsigned long arg);
>> +extern struct vfio_device *vfio_device_get_external_user(struct file *filep);
>> +extern void vfio_device_put_external_user(struct vfio_device *vdev);
>> +extern int vfio_external_get_type(struct vfio_device *vdev);
>> +extern struct device *vfio_external_get_base_device(struct vfio_device *vdev);
>>  
>>  struct pci_dev;
>>  #ifdef CONFIG_EEH
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: eric.auger@st.com, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	joel.schopp@amd.com, kim.phillips@freescale.com,
	linux-kernel@vger.kernel.org, patches@linaro.org,
	will.deacon@arm.com, a.motakis@virtualopensystems.com,
	a.rigo@virtualopensystems.com, john.liuli@huawei.com
Subject: Re: [RFC 5/9] VFIO: Extend external user API
Date: Wed, 27 Aug 2014 17:20:46 +0200	[thread overview]
Message-ID: <53FDF74E.6000201@linaro.org> (raw)
In-Reply-To: <1409079734.2906.129.camel@ul30vt.home>

On 08/26/2014 09:02 PM, Alex Williamson wrote:
> On Mon, 2014-08-25 at 15:27 +0200, Eric Auger wrote:
>> New functions are added to be called from ARM KVM-VFIO device.
>>
>> - vfio_device_get_external_user enables to get a vfio device from
>>   its fd
>> - vfio_device_put_external_user puts the vfio device
>> - vfio_external_get_type enables to retrieve the type of the device
>>   (PCI or platform)
>> - vfio_external_get_base_device enables to get the
>>   struct device*, useful to access the platform_device
>>
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>> ---
>>  drivers/vfio/vfio.c  | 35 +++++++++++++++++++++++++++++++++++
>>  include/linux/vfio.h |  4 ++++
>>  2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>> index 8e84471..c93b9e4 100644
>> --- a/drivers/vfio/vfio.c
>> +++ b/drivers/vfio/vfio.c
>> @@ -1401,6 +1401,41 @@ void vfio_group_put_external_user(struct vfio_group *group)
>>  }
>>  EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
>>  
>> +struct vfio_device *vfio_device_get_external_user(struct file *filep)
>> +{
>> +	struct vfio_device *vdev = filep->private_data;
>> +
>> +	if (filep->f_op != &vfio_device_fops)
>> +		return ERR_PTR(-EINVAL);
>> +
>> +	vfio_device_get(vdev);
>> +	return vdev;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_device_get_external_user);
>> +
>> +void vfio_device_put_external_user(struct vfio_device *vdev)
>> +{
>> +	vfio_device_put(vdev);
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_device_put_external_user);
>> +
>> +int vfio_external_get_type(struct vfio_device *vdev)
>> +{
>> +	if (!strcmp(vdev->ops->name,  "vfio-platform"))
>> +		return VFIO_DEVICE_FLAGS_PLATFORM;
>> +	else if (!strcmp(vdev->ops->name,  "vfio-pci"))
>> +		return VFIO_DEVICE_FLAGS_PCI;
>> +	else
>> +		return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_external_get_type);
> 
> Returning the bit of the flag we use in get_device_info looks rather
> sloppy here.  Should we define a new enum for use with this?  Actually,
> is this interface even necessary?  If we can get the struct device then
> we can get the bus_type and keep vfio out of this.

thanks for the nit. I will try to get rid of it using it.
> 
> For both of these last two, I like to use the convention that where
> there is a "get" there is a matching "put".  These aren't reference
> counting anything, so let's not use get in the name.

I will rename.

Thanks

Eric
> 
>> +
>> +struct device *vfio_external_get_base_device(struct vfio_device *vdev)
>> +{
>> +	return vdev->dev;
>> +}
>> +EXPORT_SYMBOL_GPL(vfio_external_get_base_device);
>> +
> 
> Looks almost too simple, but reviewing the object lifecycles, this all
> looks safe.  Thanks,
> 
> Alex
> 
>>  int vfio_external_user_iommu_id(struct vfio_group *group)
>>  {
>>  	return iommu_group_id(group->iommu_group);
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index ffe04ed..19e98eb 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -99,6 +99,10 @@ extern void vfio_group_put_external_user(struct vfio_group *group);
>>  extern int vfio_external_user_iommu_id(struct vfio_group *group);
>>  extern long vfio_external_check_extension(struct vfio_group *group,
>>  					  unsigned long arg);
>> +extern struct vfio_device *vfio_device_get_external_user(struct file *filep);
>> +extern void vfio_device_put_external_user(struct vfio_device *vdev);
>> +extern int vfio_external_get_type(struct vfio_device *vdev);
>> +extern struct device *vfio_external_get_base_device(struct vfio_device *vdev);
>>  
>>  struct pci_dev;
>>  #ifdef CONFIG_EEH
> 
> 
> 

  reply	other threads:[~2014-08-27 15:20 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 13:27 [RFC 0/9] KVM-VFIO IRQ forward control Eric Auger
2014-08-25 13:27 ` Eric Auger
2014-08-25 13:27 ` [RFC 1/9] KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded IRQ Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27 ` [RFC 2/9] KVM: ARM: VGIC: add forwarded irq rbtree lock Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27 ` [RFC 3/9] VFIO: platform: handler tests whether the IRQ is forwarded Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27 ` [RFC 4/9] KVM: KVM-VFIO: update user API to program forwarded IRQ Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-26 19:01   ` Alex Williamson
2014-08-26 19:01     ` Alex Williamson
2014-08-27 15:19     ` Eric Auger
2014-08-27 15:19       ` Eric Auger
2014-08-25 13:27 ` [RFC 5/9] VFIO: Extend external user API Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-26 19:02   ` Alex Williamson
2014-08-26 19:02     ` Alex Williamson
2014-08-27 15:20     ` Eric Auger [this message]
2014-08-27 15:20       ` Eric Auger
2014-08-25 13:27 ` [RFC 6/9] KVM: KVM-VFIO: allow arch specific implementation Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27 ` [RFC 7/9] KVM: KVM-VFIO: add new VFIO external API hooks Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-25 13:27 ` [RFC 8/9] KVM: KVM-VFIO: add kvm_vfio_arch_data and accessors Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-26 19:02   ` Alex Williamson
2014-08-26 19:02     ` Alex Williamson
2014-08-27 15:22     ` Eric Auger
2014-08-27 15:22       ` Eric Auger
2014-08-27 15:37       ` Alex Williamson
2014-08-27 15:37         ` Alex Williamson
2014-08-27 15:42         ` Eric Auger
2014-08-27 15:42           ` Eric Auger
2014-08-25 13:27 ` [RFC 9/9] KVM: KVM_VFIO: ARM: implement irq forwarding control Eric Auger
2014-08-25 13:27   ` Eric Auger
2014-08-26 19:02   ` Alex Williamson
2014-08-26 19:02     ` Alex Williamson
2014-08-27 15:24     ` Eric Auger
2014-08-27 15:24       ` Eric Auger
2014-08-26 17:49 ` [RFC 0/9] KVM-VFIO IRQ forward control Alex Williamson
2014-08-26 17:49   ` Alex Williamson
2014-08-27 15:10   ` Eric Auger
2014-08-27 15:10     ` Eric Auger

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=53FDF74E.6000201@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.