All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Keqian Zhu <zhukeqian1@huawei.com>,
	eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, will@kernel.org, joro@8bytes.org,
	maz@kernel.org, robin.murphy@arm.com, alex.williamson@redhat.com
Cc: jean-philippe@linaro.org, jacob.jun.pan@linux.intel.com,
	nicoleotsuka@gmail.com, vivek.gautam@arm.com, yi.l.liu@intel.com,
	zhangfei.gao@linaro.org
Subject: Re: [PATCH v11 01/13] vfio: VFIO_IOMMU_SET_PASID_TABLE
Date: Mon, 22 Feb 2021 11:53:38 +0100	[thread overview]
Message-ID: <e476f85d-f49f-f9a6-3232-e99a4cb5a0a2@redhat.com> (raw)
In-Reply-To: <84a111da-1969-1701-9a6d-cae8d7c285c6@huawei.com>

Hi Keqian,

On 2/2/21 1:34 PM, Keqian Zhu wrote:
> Hi Eric,
> 
> On 2020/11/16 19:00, Eric Auger wrote:
>> From: "Liu, Yi L" <yi.l.liu@linux.intel.com>
>>
>> This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
>> which aims to pass the virtual iommu guest configuration
>> to the host. This latter takes the form of the so-called
>> PASID table.
>>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v11 -> v12:
>> - use iommu_uapi_set_pasid_table
>> - check SET and UNSET are not set simultaneously (Zenghui)
>>
>> v8 -> v9:
>> - Merge VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE into a single
>>   VFIO_IOMMU_SET_PASID_TABLE ioctl.
>>
>> v6 -> v7:
>> - add a comment related to VFIO_IOMMU_DETACH_PASID_TABLE
>>
>> v3 -> v4:
>> - restore ATTACH/DETACH
>> - add unwind on failure
>>
>> v2 -> v3:
>> - s/BIND_PASID_TABLE/SET_PASID_TABLE
>>
>> v1 -> v2:
>> - s/BIND_GUEST_STAGE/BIND_PASID_TABLE
>> - remove the struct device arg
>> ---
>>  drivers/vfio/vfio_iommu_type1.c | 65 +++++++++++++++++++++++++++++++++
>>  include/uapi/linux/vfio.h       | 19 ++++++++++
>>  2 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index 67e827638995..87ddd9e882dc 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -2587,6 +2587,41 @@ static int vfio_iommu_iova_build_caps(struct vfio_iommu *iommu,
>>  	return ret;
>>  }
>>  
>> +static void
>> +vfio_detach_pasid_table(struct vfio_iommu *iommu)
>> +{
>> +	struct vfio_domain *d;
>> +
>> +	mutex_lock(&iommu->lock);
>> +	list_for_each_entry(d, &iommu->domain_list, next)
>> +		iommu_detach_pasid_table(d->domain);
>> +
>> +	mutex_unlock(&iommu->lock);
>> +}
>> +
>> +static int
>> +vfio_attach_pasid_table(struct vfio_iommu *iommu, unsigned long arg)
>> +{
>> +	struct vfio_domain *d;
>> +	int ret = 0;
>> +
>> +	mutex_lock(&iommu->lock);
>> +
>> +	list_for_each_entry(d, &iommu->domain_list, next) {
>> +		ret = iommu_uapi_attach_pasid_table(d->domain, (void __user *)arg);
> This design is not very clear to me. This assumes all iommu_domains share the same pasid table.
> 
> As I understand, it's reasonable when there is only one group in the domain, and only one domain in the vfio_iommu.
> If more than one group in the vfio_iommu, the guest may put them into different guest iommu_domain, then they have different pasid table.
> 
> Is this the use scenario?

the vfio_iommu is attached to a container. all the groups within a
container share the same set of page tables (linux
Documentation/driver-api/vfio.rst). So to me if you want to use
different pasid tables, the groups need to be attached to different
containers. Does that make sense to you?

Thanks

Eric
> 
> Thanks,
> Keqian
> 
>> +		if (ret)
>> +			goto unwind;
>> +	}
>> +	goto unlock;
>> +unwind:
>> +	list_for_each_entry_continue_reverse(d, &iommu->domain_list, next) {
>> +		iommu_detach_pasid_table(d->domain);
>> +	}
>> +unlock:
>> +	mutex_unlock(&iommu->lock);
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
>>  					   struct vfio_info_cap *caps)
>>  {
>> @@ -2747,6 +2782,34 @@ static int vfio_iommu_type1_unmap_dma(struct vfio_iommu *iommu,
>>  			-EFAULT : 0;
>>  }
>>  
>> +static int vfio_iommu_type1_set_pasid_table(struct vfio_iommu *iommu,
>> +					    unsigned long arg)
>> +{
>> +	struct vfio_iommu_type1_set_pasid_table spt;
>> +	unsigned long minsz;
>> +	int ret = -EINVAL;
>> +
>> +	minsz = offsetofend(struct vfio_iommu_type1_set_pasid_table, flags);
>> +
>> +	if (copy_from_user(&spt, (void __user *)arg, minsz))
>> +		return -EFAULT;
>> +
>> +	if (spt.argsz < minsz)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET &&
>> +	    spt.flags & VFIO_PASID_TABLE_FLAG_UNSET)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET)
>> +		ret = vfio_attach_pasid_table(iommu, arg + minsz);
>> +	else if (spt.flags & VFIO_PASID_TABLE_FLAG_UNSET) {
>> +		vfio_detach_pasid_table(iommu);
>> +		ret = 0;
>> +	}
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
>>  					unsigned long arg)
>>  {
>> @@ -2867,6 +2930,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>>  		return vfio_iommu_type1_unmap_dma(iommu, arg);
>>  	case VFIO_IOMMU_DIRTY_PAGES:
>>  		return vfio_iommu_type1_dirty_pages(iommu, arg);
>> +	case VFIO_IOMMU_SET_PASID_TABLE:
>> +		return vfio_iommu_type1_set_pasid_table(iommu, arg);
>>  	default:
>>  		return -ENOTTY;
>>  	}
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 2f313a238a8f..78ce3ce6c331 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -14,6 +14,7 @@
>>  
>>  #include <linux/types.h>
>>  #include <linux/ioctl.h>
>> +#include <linux/iommu.h>
>>  
>>  #define VFIO_API_VERSION	0
>>  
>> @@ -1180,6 +1181,24 @@ struct vfio_iommu_type1_dirty_bitmap_get {
>>  
>>  #define VFIO_IOMMU_DIRTY_PAGES             _IO(VFIO_TYPE, VFIO_BASE + 17)
>>  
>> +/*
>> + * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 22,
>> + *			struct vfio_iommu_type1_set_pasid_table)
>> + *
>> + * The SET operation passes a PASID table to the host while the
>> + * UNSET operation detaches the one currently programmed. Setting
>> + * a table while another is already programmed replaces the old table.
>> + */
>> +struct vfio_iommu_type1_set_pasid_table {
>> +	__u32	argsz;
>> +	__u32	flags;
>> +#define VFIO_PASID_TABLE_FLAG_SET	(1 << 0)
>> +#define VFIO_PASID_TABLE_FLAG_UNSET	(1 << 1)
>> +	struct iommu_pasid_table_config config; /* used on SET */
>> +};
>> +
>> +#define VFIO_IOMMU_SET_PASID_TABLE	_IO(VFIO_TYPE, VFIO_BASE + 22)
>> +
>>  /* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
>>  
>>  /*
>>
> 


WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Keqian Zhu <zhukeqian1@huawei.com>,
	eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, will@kernel.org, joro@8bytes.org,
	maz@kernel.org, robin.murphy@arm.com, alex.williamson@redhat.com
Cc: jean-philippe@linaro.org, vivek.gautam@arm.com, zhangfei.gao@linaro.org
Subject: Re: [PATCH v11 01/13] vfio: VFIO_IOMMU_SET_PASID_TABLE
Date: Mon, 22 Feb 2021 11:53:38 +0100	[thread overview]
Message-ID: <e476f85d-f49f-f9a6-3232-e99a4cb5a0a2@redhat.com> (raw)
In-Reply-To: <84a111da-1969-1701-9a6d-cae8d7c285c6@huawei.com>

Hi Keqian,

On 2/2/21 1:34 PM, Keqian Zhu wrote:
> Hi Eric,
> 
> On 2020/11/16 19:00, Eric Auger wrote:
>> From: "Liu, Yi L" <yi.l.liu@linux.intel.com>
>>
>> This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
>> which aims to pass the virtual iommu guest configuration
>> to the host. This latter takes the form of the so-called
>> PASID table.
>>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v11 -> v12:
>> - use iommu_uapi_set_pasid_table
>> - check SET and UNSET are not set simultaneously (Zenghui)
>>
>> v8 -> v9:
>> - Merge VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE into a single
>>   VFIO_IOMMU_SET_PASID_TABLE ioctl.
>>
>> v6 -> v7:
>> - add a comment related to VFIO_IOMMU_DETACH_PASID_TABLE
>>
>> v3 -> v4:
>> - restore ATTACH/DETACH
>> - add unwind on failure
>>
>> v2 -> v3:
>> - s/BIND_PASID_TABLE/SET_PASID_TABLE
>>
>> v1 -> v2:
>> - s/BIND_GUEST_STAGE/BIND_PASID_TABLE
>> - remove the struct device arg
>> ---
>>  drivers/vfio/vfio_iommu_type1.c | 65 +++++++++++++++++++++++++++++++++
>>  include/uapi/linux/vfio.h       | 19 ++++++++++
>>  2 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index 67e827638995..87ddd9e882dc 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -2587,6 +2587,41 @@ static int vfio_iommu_iova_build_caps(struct vfio_iommu *iommu,
>>  	return ret;
>>  }
>>  
>> +static void
>> +vfio_detach_pasid_table(struct vfio_iommu *iommu)
>> +{
>> +	struct vfio_domain *d;
>> +
>> +	mutex_lock(&iommu->lock);
>> +	list_for_each_entry(d, &iommu->domain_list, next)
>> +		iommu_detach_pasid_table(d->domain);
>> +
>> +	mutex_unlock(&iommu->lock);
>> +}
>> +
>> +static int
>> +vfio_attach_pasid_table(struct vfio_iommu *iommu, unsigned long arg)
>> +{
>> +	struct vfio_domain *d;
>> +	int ret = 0;
>> +
>> +	mutex_lock(&iommu->lock);
>> +
>> +	list_for_each_entry(d, &iommu->domain_list, next) {
>> +		ret = iommu_uapi_attach_pasid_table(d->domain, (void __user *)arg);
> This design is not very clear to me. This assumes all iommu_domains share the same pasid table.
> 
> As I understand, it's reasonable when there is only one group in the domain, and only one domain in the vfio_iommu.
> If more than one group in the vfio_iommu, the guest may put them into different guest iommu_domain, then they have different pasid table.
> 
> Is this the use scenario?

the vfio_iommu is attached to a container. all the groups within a
container share the same set of page tables (linux
Documentation/driver-api/vfio.rst). So to me if you want to use
different pasid tables, the groups need to be attached to different
containers. Does that make sense to you?

Thanks

Eric
> 
> Thanks,
> Keqian
> 
>> +		if (ret)
>> +			goto unwind;
>> +	}
>> +	goto unlock;
>> +unwind:
>> +	list_for_each_entry_continue_reverse(d, &iommu->domain_list, next) {
>> +		iommu_detach_pasid_table(d->domain);
>> +	}
>> +unlock:
>> +	mutex_unlock(&iommu->lock);
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
>>  					   struct vfio_info_cap *caps)
>>  {
>> @@ -2747,6 +2782,34 @@ static int vfio_iommu_type1_unmap_dma(struct vfio_iommu *iommu,
>>  			-EFAULT : 0;
>>  }
>>  
>> +static int vfio_iommu_type1_set_pasid_table(struct vfio_iommu *iommu,
>> +					    unsigned long arg)
>> +{
>> +	struct vfio_iommu_type1_set_pasid_table spt;
>> +	unsigned long minsz;
>> +	int ret = -EINVAL;
>> +
>> +	minsz = offsetofend(struct vfio_iommu_type1_set_pasid_table, flags);
>> +
>> +	if (copy_from_user(&spt, (void __user *)arg, minsz))
>> +		return -EFAULT;
>> +
>> +	if (spt.argsz < minsz)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET &&
>> +	    spt.flags & VFIO_PASID_TABLE_FLAG_UNSET)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET)
>> +		ret = vfio_attach_pasid_table(iommu, arg + minsz);
>> +	else if (spt.flags & VFIO_PASID_TABLE_FLAG_UNSET) {
>> +		vfio_detach_pasid_table(iommu);
>> +		ret = 0;
>> +	}
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
>>  					unsigned long arg)
>>  {
>> @@ -2867,6 +2930,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>>  		return vfio_iommu_type1_unmap_dma(iommu, arg);
>>  	case VFIO_IOMMU_DIRTY_PAGES:
>>  		return vfio_iommu_type1_dirty_pages(iommu, arg);
>> +	case VFIO_IOMMU_SET_PASID_TABLE:
>> +		return vfio_iommu_type1_set_pasid_table(iommu, arg);
>>  	default:
>>  		return -ENOTTY;
>>  	}
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 2f313a238a8f..78ce3ce6c331 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -14,6 +14,7 @@
>>  
>>  #include <linux/types.h>
>>  #include <linux/ioctl.h>
>> +#include <linux/iommu.h>
>>  
>>  #define VFIO_API_VERSION	0
>>  
>> @@ -1180,6 +1181,24 @@ struct vfio_iommu_type1_dirty_bitmap_get {
>>  
>>  #define VFIO_IOMMU_DIRTY_PAGES             _IO(VFIO_TYPE, VFIO_BASE + 17)
>>  
>> +/*
>> + * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 22,
>> + *			struct vfio_iommu_type1_set_pasid_table)
>> + *
>> + * The SET operation passes a PASID table to the host while the
>> + * UNSET operation detaches the one currently programmed. Setting
>> + * a table while another is already programmed replaces the old table.
>> + */
>> +struct vfio_iommu_type1_set_pasid_table {
>> +	__u32	argsz;
>> +	__u32	flags;
>> +#define VFIO_PASID_TABLE_FLAG_SET	(1 << 0)
>> +#define VFIO_PASID_TABLE_FLAG_UNSET	(1 << 1)
>> +	struct iommu_pasid_table_config config; /* used on SET */
>> +};
>> +
>> +#define VFIO_IOMMU_SET_PASID_TABLE	_IO(VFIO_TYPE, VFIO_BASE + 22)
>> +
>>  /* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
>>  
>>  /*
>>
> 

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Keqian Zhu <zhukeqian1@huawei.com>,
	eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, will@kernel.org, joro@8bytes.org,
	maz@kernel.org, robin.murphy@arm.com, alex.williamson@redhat.com
Cc: jean-philippe@linaro.org, jacob.jun.pan@linux.intel.com,
	nicoleotsuka@gmail.com, vivek.gautam@arm.com, yi.l.liu@intel.com,
	zhangfei.gao@linaro.org
Subject: Re: [PATCH v11 01/13] vfio: VFIO_IOMMU_SET_PASID_TABLE
Date: Mon, 22 Feb 2021 11:53:38 +0100	[thread overview]
Message-ID: <e476f85d-f49f-f9a6-3232-e99a4cb5a0a2@redhat.com> (raw)
In-Reply-To: <84a111da-1969-1701-9a6d-cae8d7c285c6@huawei.com>

Hi Keqian,

On 2/2/21 1:34 PM, Keqian Zhu wrote:
> Hi Eric,
> 
> On 2020/11/16 19:00, Eric Auger wrote:
>> From: "Liu, Yi L" <yi.l.liu@linux.intel.com>
>>
>> This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
>> which aims to pass the virtual iommu guest configuration
>> to the host. This latter takes the form of the so-called
>> PASID table.
>>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v11 -> v12:
>> - use iommu_uapi_set_pasid_table
>> - check SET and UNSET are not set simultaneously (Zenghui)
>>
>> v8 -> v9:
>> - Merge VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE into a single
>>   VFIO_IOMMU_SET_PASID_TABLE ioctl.
>>
>> v6 -> v7:
>> - add a comment related to VFIO_IOMMU_DETACH_PASID_TABLE
>>
>> v3 -> v4:
>> - restore ATTACH/DETACH
>> - add unwind on failure
>>
>> v2 -> v3:
>> - s/BIND_PASID_TABLE/SET_PASID_TABLE
>>
>> v1 -> v2:
>> - s/BIND_GUEST_STAGE/BIND_PASID_TABLE
>> - remove the struct device arg
>> ---
>>  drivers/vfio/vfio_iommu_type1.c | 65 +++++++++++++++++++++++++++++++++
>>  include/uapi/linux/vfio.h       | 19 ++++++++++
>>  2 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index 67e827638995..87ddd9e882dc 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -2587,6 +2587,41 @@ static int vfio_iommu_iova_build_caps(struct vfio_iommu *iommu,
>>  	return ret;
>>  }
>>  
>> +static void
>> +vfio_detach_pasid_table(struct vfio_iommu *iommu)
>> +{
>> +	struct vfio_domain *d;
>> +
>> +	mutex_lock(&iommu->lock);
>> +	list_for_each_entry(d, &iommu->domain_list, next)
>> +		iommu_detach_pasid_table(d->domain);
>> +
>> +	mutex_unlock(&iommu->lock);
>> +}
>> +
>> +static int
>> +vfio_attach_pasid_table(struct vfio_iommu *iommu, unsigned long arg)
>> +{
>> +	struct vfio_domain *d;
>> +	int ret = 0;
>> +
>> +	mutex_lock(&iommu->lock);
>> +
>> +	list_for_each_entry(d, &iommu->domain_list, next) {
>> +		ret = iommu_uapi_attach_pasid_table(d->domain, (void __user *)arg);
> This design is not very clear to me. This assumes all iommu_domains share the same pasid table.
> 
> As I understand, it's reasonable when there is only one group in the domain, and only one domain in the vfio_iommu.
> If more than one group in the vfio_iommu, the guest may put them into different guest iommu_domain, then they have different pasid table.
> 
> Is this the use scenario?

the vfio_iommu is attached to a container. all the groups within a
container share the same set of page tables (linux
Documentation/driver-api/vfio.rst). So to me if you want to use
different pasid tables, the groups need to be attached to different
containers. Does that make sense to you?

Thanks

Eric
> 
> Thanks,
> Keqian
> 
>> +		if (ret)
>> +			goto unwind;
>> +	}
>> +	goto unlock;
>> +unwind:
>> +	list_for_each_entry_continue_reverse(d, &iommu->domain_list, next) {
>> +		iommu_detach_pasid_table(d->domain);
>> +	}
>> +unlock:
>> +	mutex_unlock(&iommu->lock);
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
>>  					   struct vfio_info_cap *caps)
>>  {
>> @@ -2747,6 +2782,34 @@ static int vfio_iommu_type1_unmap_dma(struct vfio_iommu *iommu,
>>  			-EFAULT : 0;
>>  }
>>  
>> +static int vfio_iommu_type1_set_pasid_table(struct vfio_iommu *iommu,
>> +					    unsigned long arg)
>> +{
>> +	struct vfio_iommu_type1_set_pasid_table spt;
>> +	unsigned long minsz;
>> +	int ret = -EINVAL;
>> +
>> +	minsz = offsetofend(struct vfio_iommu_type1_set_pasid_table, flags);
>> +
>> +	if (copy_from_user(&spt, (void __user *)arg, minsz))
>> +		return -EFAULT;
>> +
>> +	if (spt.argsz < minsz)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET &&
>> +	    spt.flags & VFIO_PASID_TABLE_FLAG_UNSET)
>> +		return -EINVAL;
>> +
>> +	if (spt.flags & VFIO_PASID_TABLE_FLAG_SET)
>> +		ret = vfio_attach_pasid_table(iommu, arg + minsz);
>> +	else if (spt.flags & VFIO_PASID_TABLE_FLAG_UNSET) {
>> +		vfio_detach_pasid_table(iommu);
>> +		ret = 0;
>> +	}
>> +	return ret;
>> +}
>> +
>>  static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
>>  					unsigned long arg)
>>  {
>> @@ -2867,6 +2930,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>>  		return vfio_iommu_type1_unmap_dma(iommu, arg);
>>  	case VFIO_IOMMU_DIRTY_PAGES:
>>  		return vfio_iommu_type1_dirty_pages(iommu, arg);
>> +	case VFIO_IOMMU_SET_PASID_TABLE:
>> +		return vfio_iommu_type1_set_pasid_table(iommu, arg);
>>  	default:
>>  		return -ENOTTY;
>>  	}
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 2f313a238a8f..78ce3ce6c331 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -14,6 +14,7 @@
>>  
>>  #include <linux/types.h>
>>  #include <linux/ioctl.h>
>> +#include <linux/iommu.h>
>>  
>>  #define VFIO_API_VERSION	0
>>  
>> @@ -1180,6 +1181,24 @@ struct vfio_iommu_type1_dirty_bitmap_get {
>>  
>>  #define VFIO_IOMMU_DIRTY_PAGES             _IO(VFIO_TYPE, VFIO_BASE + 17)
>>  
>> +/*
>> + * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 22,
>> + *			struct vfio_iommu_type1_set_pasid_table)
>> + *
>> + * The SET operation passes a PASID table to the host while the
>> + * UNSET operation detaches the one currently programmed. Setting
>> + * a table while another is already programmed replaces the old table.
>> + */
>> +struct vfio_iommu_type1_set_pasid_table {
>> +	__u32	argsz;
>> +	__u32	flags;
>> +#define VFIO_PASID_TABLE_FLAG_SET	(1 << 0)
>> +#define VFIO_PASID_TABLE_FLAG_UNSET	(1 << 1)
>> +	struct iommu_pasid_table_config config; /* used on SET */
>> +};
>> +
>> +#define VFIO_IOMMU_SET_PASID_TABLE	_IO(VFIO_TYPE, VFIO_BASE + 22)
>> +
>>  /* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
>>  
>>  /*
>>
> 

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2021-02-22 10:55 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 11:00 [PATCH v11 00/13] SMMUv3 Nested Stage Setup (VFIO part) Eric Auger
2020-11-16 11:00 ` Eric Auger
2020-11-16 11:00 ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 01/13] vfio: VFIO_IOMMU_SET_PASID_TABLE Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-17  2:11   ` kernel test robot
2020-11-17  2:11     ` kernel test robot
2020-11-17  2:11     ` kernel test robot
2020-11-17  2:11     ` kernel test robot
2020-11-24 21:31   ` Alex Williamson
2020-11-24 21:31     ` Alex Williamson
2020-11-24 21:31     ` Alex Williamson
2021-02-02 12:34   ` Keqian Zhu
2021-02-02 12:34     ` Keqian Zhu
2021-02-02 12:34     ` Keqian Zhu
2021-02-22 10:53     ` Auger Eric [this message]
2021-02-22 10:53       ` Auger Eric
2021-02-22 10:53       ` Auger Eric
2021-02-22 12:20       ` Keqian Zhu
2021-02-22 12:20         ` Keqian Zhu
2021-02-22 12:20         ` Keqian Zhu
2021-02-22 16:12         ` Auger Eric
2021-02-22 16:12           ` Auger Eric
2021-02-22 16:12           ` Auger Eric
2020-11-16 11:00 ` [PATCH v11 02/13] vfio: VFIO_IOMMU_CACHE_INVALIDATE Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 03/13] vfio: VFIO_IOMMU_SET_MSI_BINDING Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2021-02-02 12:08   ` Keqian Zhu
2021-02-02 12:08     ` Keqian Zhu
2021-02-02 12:08     ` Keqian Zhu
2020-11-16 11:00 ` [PATCH v11 04/13] vfio/pci: Add VFIO_REGION_TYPE_NESTED region type Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-12-17 11:49   ` Kunkun Jiang
2020-12-17 11:49     ` Kunkun Jiang
2020-12-17 11:49     ` Kunkun Jiang
2021-02-23 12:45     ` Shenming Lu
2021-02-23 12:45       ` Shenming Lu
2021-02-23 12:45       ` Shenming Lu
2021-02-23 12:57       ` Auger Eric
2021-02-23 12:57         ` Auger Eric
2021-02-23 12:57         ` Auger Eric
2020-11-16 11:00 ` [PATCH v11 05/13] vfio/pci: Register an iommu fault handler Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 13:51   ` kernel test robot
2020-11-16 13:51     ` kernel test robot
2020-11-16 13:51     ` kernel test robot
2020-11-16 13:51     ` kernel test robot
2020-11-16 19:30   ` kernel test robot
2020-11-16 19:30     ` kernel test robot
2020-11-16 19:30     ` kernel test robot
2020-11-16 19:30     ` kernel test robot
2020-11-16 11:00 ` [PATCH v11 06/13] vfio/pci: Allow to mmap the fault queue Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 07/13] vfio: Use capability chains to handle device specific irq Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 08/13] vfio/pci: Add framework for custom interrupt indices Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-23 12:51   ` Shameerali Kolothum Thodi
2020-11-23 12:51     ` Shameerali Kolothum Thodi
2020-11-23 12:51     ` Shameerali Kolothum Thodi
2020-11-24  8:35     ` Auger Eric
2020-11-24  8:35       ` Auger Eric
2020-11-24  8:35       ` Auger Eric
2020-11-16 11:00 ` [PATCH v11 09/13] vfio: Add new IRQ for DMA fault reporting Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 10/13] vfio/pci: Register and allow DMA FAULT IRQ signaling Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 11/13] vfio: Document nested stage control Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00 ` [PATCH v11 12/13] vfio/pci: Register a DMA fault response region Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2021-01-08 15:19   ` Shameerali Kolothum Thodi
2021-01-08 15:19     ` Shameerali Kolothum Thodi
2021-01-08 15:19     ` Shameerali Kolothum Thodi
2021-02-18 10:36   ` Shameerali Kolothum Thodi
2021-02-18 10:36     ` Shameerali Kolothum Thodi
2021-02-18 10:36     ` Shameerali Kolothum Thodi
2021-02-18 10:48     ` Auger Eric
2021-02-18 10:48       ` Auger Eric
2021-02-18 10:48       ` Auger Eric
2020-11-16 11:00 ` [PATCH v11 13/13] vfio/pci: Inject page response upon response region fill Eric Auger
2020-11-16 11:00   ` Eric Auger
2020-11-16 11:00   ` Eric Auger
2021-03-15 18:04 ` [PATCH v11 00/13] SMMUv3 Nested Stage Setup (VFIO part) Krishna Reddy
2021-03-15 18:04   ` Krishna Reddy
2021-03-15 18:04   ` Krishna Reddy

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=e476f85d-f49f-f9a6-3232-e99a4cb5a0a2@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=nicoleotsuka@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=vivek.gautam@arm.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhukeqian1@huawei.com \
    /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.