From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Raj Ashok <ashok.raj@intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
LKML <linux-kernel@vger.kernel.org>,
iommu@lists.linux-foundation.org,
Alex Williamson <alex.williamson@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH 03/10] iommu/ioasid: Introduce per set allocation APIs
Date: Mon, 6 Apr 2020 13:02:45 -0700 [thread overview]
Message-ID: <20200406130245.690cfe15@jacob-builder> (raw)
In-Reply-To: <20200401134745.GE882512@myrica>
On Wed, 1 Apr 2020 15:47:45 +0200
Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> On Wed, Mar 25, 2020 at 10:55:24AM -0700, Jacob Pan wrote:
> > IOASID set defines a group of IDs that share the same token. The
> > ioasid_set concept helps to do permission checking among users as
> > in the current code.
> >
> > With guest SVA usage, each VM has its own IOASID set. More
> > functionalities are needed:
> > 1. Enforce quota, each guest may be assigned limited quota such
> > that one guest cannot abuse all the system resource.
> > 2. Stores IOASID mapping between guest and host IOASIDs
> > 3. Per set operations, e.g. free the entire set
> >
> > For each ioasid_set token, a unique set ID is assigned. This makes
> > reference of the set and data lookup much easier to implement.
> >
> > Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > ---
> > drivers/iommu/ioasid.c | 147
> > +++++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/ioasid.h | 13 +++++ 2 files changed, 160
> > insertions(+)
> >
> > diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
> > index 4026e52855b9..27ee57f7079b 100644
> > --- a/drivers/iommu/ioasid.c
> > +++ b/drivers/iommu/ioasid.c
> > @@ -10,6 +10,25 @@
> > #include <linux/spinlock.h>
> > #include <linux/xarray.h>
> >
> > +static DEFINE_XARRAY_ALLOC(ioasid_sets);
> > +/**
> > + * struct ioasid_set_data - Meta data about ioasid_set
> > + *
> > + * @token: Unique to identify an IOASID set
> > + * @xa: XArray to store subset ID and IOASID mapping
> > + * @size: Max number of IOASIDs can be allocated within the
> > set
> > + * @nr_ioasids Number of IOASIDs allocated in the set
> > + * @sid ID of the set
> > + */
> > +struct ioasid_set_data {
> > + struct ioasid_set *token;
> > + struct xarray xa;
> > + int size;
> > + int nr_ioasids;
> > + int sid;
> > + struct rcu_head rcu;
> > +};
> > +
> > struct ioasid_data {
> > ioasid_t id;
> > struct ioasid_set *set;
> > @@ -388,6 +407,111 @@ void ioasid_free(ioasid_t ioasid)
> > EXPORT_SYMBOL_GPL(ioasid_free);
> >
> > /**
> > + * ioasid_alloc_set - Allocate a set of IOASIDs
> > + * @token: Unique token of the IOASID set
> > + * @quota: Quota allowed in this set
> > + * @sid: IOASID set ID to be assigned
> > + *
> > + * Return 0 upon success. Token will be stored internally for
> > lookup,
> > + * IOASID allocation within the set and other per set operations
> > will use
> > + * the @sid assigned.
> > + *
> > + */
> > +int ioasid_alloc_set(struct ioasid_set *token, ioasid_t quota, int
> > *sid) +{
> > + struct ioasid_set_data *sdata;
> > + ioasid_t id;
> > + int ret = 0;
> > +
> > + if (quota > ioasid_capacity_avail) {
> > + pr_warn("Out of IOASID capacity! ask %d, avail
> > %d\n",
> > + quota, ioasid_capacity_avail);
> > + return -ENOSPC;
> > + }
>
> This check should be in the same critical section as the quota
> substraction
>
yes, right.
> > +
> > + sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
> > + if (!sdata)
> > + return -ENOMEM;
>
> I don't understand why we need this structure at all, nor why we need
> the SID. Users have already allocated an ioasid_set, so why not just
> stick the content of ioasid_set_data in there, and pass the
> ioasid_set pointer to ioasid_alloc()?
>
My thinking was that ioasid_set is an opaque user token, e.g. we use mm
to identify a common set belong to a VM.
This sdata is an IOASID internal structure for managing & servicing per
set data. If we let user fill in the content, some of the entries need
to be managed by the IOASID code under a lock. IMO, not suitable to let
user allocate and manage.
Perhaps we should rename struct ioasid_set to ioasid_set_token?
/**
* struct ioasid_set_data - Meta data about ioasid_set
*
* @token: Unique to identify an IOASID set
* @xa: XArray to store ioasid_set private ID to
system-wide IOASID
* mapping
* @max_id: Max number of IOASIDs can be allocated within the set
* @nr_id Number of IOASIDs allocated in the set
* @sid ID of the set
*/
struct ioasid_set_data {
struct ioasid_set *token;
struct xarray xa;
int size;
int nr_ioasids;
int sid;
struct rcu_head rcu;
};
I agree SID is optional. User could just use the token to reference
the set. I use the SID for performance reason, i.e. quick lookup from
SID to its data. Otherwise, we may have to search through a list of
sets to find a match?
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > +
> > + ret = xa_alloc(&ioasid_sets, &id, sdata,
> > + XA_LIMIT(0, ioasid_capacity_avail - quota),
> > + GFP_KERNEL);
>
> Same as Kevin, I think the limit should be the static
> ioasid_capacity. And perhaps a comment explaining the worst case of
> one PASID per set. I found a little confusing using the same type
> ioasid_t for IOASIDs and IOASID sets, it may be clearer to use an int
> for IOASID set IDs.
>
Sounds good.
> Thanks,
> Jean
>
> > + if (ret) {
> > + kfree(sdata);
> > + goto error;
> > + }
> > +
> > + sdata->token = token;
> > + sdata->size = quota;
> > + sdata->sid = id;
> > +
> > + /*
> > + * Set Xarray is used to store IDs within the set, get
> > ready for
> > + * sub-set ID and system-wide IOASID allocation results.
> > + */
> > + xa_init_flags(&sdata->xa, XA_FLAGS_ALLOC);
> > +
> > + ioasid_capacity_avail -= quota;
> > + *sid = id;
> > +
> > +error:
> > + spin_unlock(&ioasid_allocator_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_alloc_set);
> > +
> > +/**
> > + * ioasid_free_set - Free all IOASIDs within the set
> > + *
> > + * @sid: The IOASID set ID to be freed
> > + * @destroy_set: Whether to keep the set for further
> > allocation.
> > + * If true, the set will be destroyed.
> > + *
> > + * All IOASIDs allocated within the set will be freed upon return.
> > + */
> > +void ioasid_free_set(int sid, bool destroy_set)
> > +{
> > + struct ioasid_set_data *sdata;
> > + struct ioasid_data *entry;
> > + unsigned long index;
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > + sdata = xa_load(&ioasid_sets, sid);
> > + if (!sdata) {
> > + pr_err("No IOASID set found to free %d\n", sid);
> > + goto done_unlock;
> > + }
> > +
> > + if (xa_empty(&sdata->xa)) {
> > + pr_warn("No IOASIDs in the set %d\n", sdata->sid);
> > + goto done_destroy;
> > + }
> > +
> > + /* Just a place holder for now */
> > + xa_for_each(&sdata->xa, index, entry) {
> > + /* Free from per sub-set pool */
> > + xa_erase(&sdata->xa, index);
> > + }
> > +
> > +done_destroy:
> > + if (destroy_set) {
> > + xa_erase(&ioasid_sets, sid);
> > +
> > + /* Return the quota back to system pool */
> > + ioasid_capacity_avail += sdata->size;
> > + kfree_rcu(sdata, rcu);
> > + }
> > +
> > +done_unlock:
> > + spin_unlock(&ioasid_allocator_lock);
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_free_set);
> > +
> > +
> > +/**
> > * ioasid_find - Find IOASID data
> > * @set: the IOASID set
> > * @ioasid: the IOASID to find
> > @@ -431,6 +555,29 @@ void *ioasid_find(struct ioasid_set *set,
> > ioasid_t ioasid, }
> > EXPORT_SYMBOL_GPL(ioasid_find);
> >
> > +/**
> > + * ioasid_find_sid - Retrieve IOASID set ID from an ioasid
> > + * Caller must hold a reference to the set.
> > + *
> > + * @ioasid: IOASID associated with the set
> > + *
> > + * Return IOASID set ID or error
> > + */
> > +int ioasid_find_sid(ioasid_t ioasid)
> > +{
> > + struct ioasid_data *ioasid_data;
> > + int ret = 0;
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > + ioasid_data = xa_load(&active_allocator->xa, ioasid);
> > + ret = (ioasid_data) ? ioasid_data->sdata->sid : -ENOENT;
> > +
> > + spin_unlock(&ioasid_allocator_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_find_sid);
> > +
> > MODULE_AUTHOR("Jean-Philippe Brucker
> > <jean-philippe.brucker@arm.com>"); MODULE_AUTHOR("Jacob Pan
> > <jacob.jun.pan@linux.intel.com>"); MODULE_DESCRIPTION("IO Address
> > Space ID (IOASID) allocator"); diff --git a/include/linux/ioasid.h
> > b/include/linux/ioasid.h index 9711fa0dc357..be158e03c034 100644
> > --- a/include/linux/ioasid.h
> > +++ b/include/linux/ioasid.h
> > @@ -41,6 +41,9 @@ int ioasid_register_allocator(struct
> > ioasid_allocator_ops *allocator); void
> > ioasid_unregister_allocator(struct ioasid_allocator_ops
> > *allocator); int ioasid_set_data(ioasid_t ioasid, void *data); void
> > ioasid_install_capacity(ioasid_t total); +int
> > ioasid_alloc_set(struct ioasid_set *token, ioasid_t quota, int
> > *sid); +void ioasid_free_set(int sid, bool destroy_set); +int
> > ioasid_find_sid(ioasid_t ioasid); #else /* !CONFIG_IOASID */
> > static inline ioasid_t ioasid_alloc(struct ioasid_set *set,
> > ioasid_t min, ioasid_t max, void *private)
> > @@ -52,6 +55,15 @@ static inline void ioasid_free(ioasid_t ioasid)
> > {
> > }
> >
> > +static inline int ioasid_alloc_set(struct ioasid_set *token,
> > ioasid_t quota, int *sid) +{
> > + return -ENOTSUPP;
> > +}
> > +
> > +static inline void ioasid_free_set(int sid, bool destroy_set)
> > +{
> > +}
> > +
> > static inline void *ioasid_find(struct ioasid_set *set, ioasid_t
> > ioasid, bool (*getter)(void *))
> > {
> > @@ -75,5 +87,6 @@ static inline int ioasid_set_data(ioasid_t
> > ioasid, void *data) static inline void
> > ioasid_install_capacity(ioasid_t total) {
> > }
> > +
> > #endif /* CONFIG_IOASID */
> > #endif /* __LINUX_IOASID_H */
> > --
> > 2.7.4
> >
[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Joerg Roedel <joro@8bytes.org>,
Alex Williamson <alex.williamson@redhat.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
iommu@lists.linux-foundation.org,
LKML <linux-kernel@vger.kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
Raj Ashok <ashok.raj@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Jonathan Cameron <jic23@kernel.org>,
Eric Auger <eric.auger@redhat.com>,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH 03/10] iommu/ioasid: Introduce per set allocation APIs
Date: Mon, 6 Apr 2020 13:02:45 -0700 [thread overview]
Message-ID: <20200406130245.690cfe15@jacob-builder> (raw)
In-Reply-To: <20200401134745.GE882512@myrica>
On Wed, 1 Apr 2020 15:47:45 +0200
Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> On Wed, Mar 25, 2020 at 10:55:24AM -0700, Jacob Pan wrote:
> > IOASID set defines a group of IDs that share the same token. The
> > ioasid_set concept helps to do permission checking among users as
> > in the current code.
> >
> > With guest SVA usage, each VM has its own IOASID set. More
> > functionalities are needed:
> > 1. Enforce quota, each guest may be assigned limited quota such
> > that one guest cannot abuse all the system resource.
> > 2. Stores IOASID mapping between guest and host IOASIDs
> > 3. Per set operations, e.g. free the entire set
> >
> > For each ioasid_set token, a unique set ID is assigned. This makes
> > reference of the set and data lookup much easier to implement.
> >
> > Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > ---
> > drivers/iommu/ioasid.c | 147
> > +++++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/ioasid.h | 13 +++++ 2 files changed, 160
> > insertions(+)
> >
> > diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
> > index 4026e52855b9..27ee57f7079b 100644
> > --- a/drivers/iommu/ioasid.c
> > +++ b/drivers/iommu/ioasid.c
> > @@ -10,6 +10,25 @@
> > #include <linux/spinlock.h>
> > #include <linux/xarray.h>
> >
> > +static DEFINE_XARRAY_ALLOC(ioasid_sets);
> > +/**
> > + * struct ioasid_set_data - Meta data about ioasid_set
> > + *
> > + * @token: Unique to identify an IOASID set
> > + * @xa: XArray to store subset ID and IOASID mapping
> > + * @size: Max number of IOASIDs can be allocated within the
> > set
> > + * @nr_ioasids Number of IOASIDs allocated in the set
> > + * @sid ID of the set
> > + */
> > +struct ioasid_set_data {
> > + struct ioasid_set *token;
> > + struct xarray xa;
> > + int size;
> > + int nr_ioasids;
> > + int sid;
> > + struct rcu_head rcu;
> > +};
> > +
> > struct ioasid_data {
> > ioasid_t id;
> > struct ioasid_set *set;
> > @@ -388,6 +407,111 @@ void ioasid_free(ioasid_t ioasid)
> > EXPORT_SYMBOL_GPL(ioasid_free);
> >
> > /**
> > + * ioasid_alloc_set - Allocate a set of IOASIDs
> > + * @token: Unique token of the IOASID set
> > + * @quota: Quota allowed in this set
> > + * @sid: IOASID set ID to be assigned
> > + *
> > + * Return 0 upon success. Token will be stored internally for
> > lookup,
> > + * IOASID allocation within the set and other per set operations
> > will use
> > + * the @sid assigned.
> > + *
> > + */
> > +int ioasid_alloc_set(struct ioasid_set *token, ioasid_t quota, int
> > *sid) +{
> > + struct ioasid_set_data *sdata;
> > + ioasid_t id;
> > + int ret = 0;
> > +
> > + if (quota > ioasid_capacity_avail) {
> > + pr_warn("Out of IOASID capacity! ask %d, avail
> > %d\n",
> > + quota, ioasid_capacity_avail);
> > + return -ENOSPC;
> > + }
>
> This check should be in the same critical section as the quota
> substraction
>
yes, right.
> > +
> > + sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
> > + if (!sdata)
> > + return -ENOMEM;
>
> I don't understand why we need this structure at all, nor why we need
> the SID. Users have already allocated an ioasid_set, so why not just
> stick the content of ioasid_set_data in there, and pass the
> ioasid_set pointer to ioasid_alloc()?
>
My thinking was that ioasid_set is an opaque user token, e.g. we use mm
to identify a common set belong to a VM.
This sdata is an IOASID internal structure for managing & servicing per
set data. If we let user fill in the content, some of the entries need
to be managed by the IOASID code under a lock. IMO, not suitable to let
user allocate and manage.
Perhaps we should rename struct ioasid_set to ioasid_set_token?
/**
* struct ioasid_set_data - Meta data about ioasid_set
*
* @token: Unique to identify an IOASID set
* @xa: XArray to store ioasid_set private ID to
system-wide IOASID
* mapping
* @max_id: Max number of IOASIDs can be allocated within the set
* @nr_id Number of IOASIDs allocated in the set
* @sid ID of the set
*/
struct ioasid_set_data {
struct ioasid_set *token;
struct xarray xa;
int size;
int nr_ioasids;
int sid;
struct rcu_head rcu;
};
I agree SID is optional. User could just use the token to reference
the set. I use the SID for performance reason, i.e. quick lookup from
SID to its data. Otherwise, we may have to search through a list of
sets to find a match?
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > +
> > + ret = xa_alloc(&ioasid_sets, &id, sdata,
> > + XA_LIMIT(0, ioasid_capacity_avail - quota),
> > + GFP_KERNEL);
>
> Same as Kevin, I think the limit should be the static
> ioasid_capacity. And perhaps a comment explaining the worst case of
> one PASID per set. I found a little confusing using the same type
> ioasid_t for IOASIDs and IOASID sets, it may be clearer to use an int
> for IOASID set IDs.
>
Sounds good.
> Thanks,
> Jean
>
> > + if (ret) {
> > + kfree(sdata);
> > + goto error;
> > + }
> > +
> > + sdata->token = token;
> > + sdata->size = quota;
> > + sdata->sid = id;
> > +
> > + /*
> > + * Set Xarray is used to store IDs within the set, get
> > ready for
> > + * sub-set ID and system-wide IOASID allocation results.
> > + */
> > + xa_init_flags(&sdata->xa, XA_FLAGS_ALLOC);
> > +
> > + ioasid_capacity_avail -= quota;
> > + *sid = id;
> > +
> > +error:
> > + spin_unlock(&ioasid_allocator_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_alloc_set);
> > +
> > +/**
> > + * ioasid_free_set - Free all IOASIDs within the set
> > + *
> > + * @sid: The IOASID set ID to be freed
> > + * @destroy_set: Whether to keep the set for further
> > allocation.
> > + * If true, the set will be destroyed.
> > + *
> > + * All IOASIDs allocated within the set will be freed upon return.
> > + */
> > +void ioasid_free_set(int sid, bool destroy_set)
> > +{
> > + struct ioasid_set_data *sdata;
> > + struct ioasid_data *entry;
> > + unsigned long index;
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > + sdata = xa_load(&ioasid_sets, sid);
> > + if (!sdata) {
> > + pr_err("No IOASID set found to free %d\n", sid);
> > + goto done_unlock;
> > + }
> > +
> > + if (xa_empty(&sdata->xa)) {
> > + pr_warn("No IOASIDs in the set %d\n", sdata->sid);
> > + goto done_destroy;
> > + }
> > +
> > + /* Just a place holder for now */
> > + xa_for_each(&sdata->xa, index, entry) {
> > + /* Free from per sub-set pool */
> > + xa_erase(&sdata->xa, index);
> > + }
> > +
> > +done_destroy:
> > + if (destroy_set) {
> > + xa_erase(&ioasid_sets, sid);
> > +
> > + /* Return the quota back to system pool */
> > + ioasid_capacity_avail += sdata->size;
> > + kfree_rcu(sdata, rcu);
> > + }
> > +
> > +done_unlock:
> > + spin_unlock(&ioasid_allocator_lock);
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_free_set);
> > +
> > +
> > +/**
> > * ioasid_find - Find IOASID data
> > * @set: the IOASID set
> > * @ioasid: the IOASID to find
> > @@ -431,6 +555,29 @@ void *ioasid_find(struct ioasid_set *set,
> > ioasid_t ioasid, }
> > EXPORT_SYMBOL_GPL(ioasid_find);
> >
> > +/**
> > + * ioasid_find_sid - Retrieve IOASID set ID from an ioasid
> > + * Caller must hold a reference to the set.
> > + *
> > + * @ioasid: IOASID associated with the set
> > + *
> > + * Return IOASID set ID or error
> > + */
> > +int ioasid_find_sid(ioasid_t ioasid)
> > +{
> > + struct ioasid_data *ioasid_data;
> > + int ret = 0;
> > +
> > + spin_lock(&ioasid_allocator_lock);
> > + ioasid_data = xa_load(&active_allocator->xa, ioasid);
> > + ret = (ioasid_data) ? ioasid_data->sdata->sid : -ENOENT;
> > +
> > + spin_unlock(&ioasid_allocator_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(ioasid_find_sid);
> > +
> > MODULE_AUTHOR("Jean-Philippe Brucker
> > <jean-philippe.brucker@arm.com>"); MODULE_AUTHOR("Jacob Pan
> > <jacob.jun.pan@linux.intel.com>"); MODULE_DESCRIPTION("IO Address
> > Space ID (IOASID) allocator"); diff --git a/include/linux/ioasid.h
> > b/include/linux/ioasid.h index 9711fa0dc357..be158e03c034 100644
> > --- a/include/linux/ioasid.h
> > +++ b/include/linux/ioasid.h
> > @@ -41,6 +41,9 @@ int ioasid_register_allocator(struct
> > ioasid_allocator_ops *allocator); void
> > ioasid_unregister_allocator(struct ioasid_allocator_ops
> > *allocator); int ioasid_set_data(ioasid_t ioasid, void *data); void
> > ioasid_install_capacity(ioasid_t total); +int
> > ioasid_alloc_set(struct ioasid_set *token, ioasid_t quota, int
> > *sid); +void ioasid_free_set(int sid, bool destroy_set); +int
> > ioasid_find_sid(ioasid_t ioasid); #else /* !CONFIG_IOASID */
> > static inline ioasid_t ioasid_alloc(struct ioasid_set *set,
> > ioasid_t min, ioasid_t max, void *private)
> > @@ -52,6 +55,15 @@ static inline void ioasid_free(ioasid_t ioasid)
> > {
> > }
> >
> > +static inline int ioasid_alloc_set(struct ioasid_set *token,
> > ioasid_t quota, int *sid) +{
> > + return -ENOTSUPP;
> > +}
> > +
> > +static inline void ioasid_free_set(int sid, bool destroy_set)
> > +{
> > +}
> > +
> > static inline void *ioasid_find(struct ioasid_set *set, ioasid_t
> > ioasid, bool (*getter)(void *))
> > {
> > @@ -75,5 +87,6 @@ static inline int ioasid_set_data(ioasid_t
> > ioasid, void *data) static inline void
> > ioasid_install_capacity(ioasid_t total) {
> > }
> > +
> > #endif /* CONFIG_IOASID */
> > #endif /* __LINUX_IOASID_H */
> > --
> > 2.7.4
> >
[Jacob Pan]
next prev parent reply other threads:[~2020-04-06 19:57 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 17:55 [PATCH 00/10] IOASID extensions for guest SVA Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-25 17:55 ` [PATCH 01/10] iommu/ioasid: Introduce system-wide capacity Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 8:07 ` Tian, Kevin
2020-03-27 8:07 ` Tian, Kevin
2020-03-27 16:08 ` Jacob Pan
2020-03-27 16:08 ` Jacob Pan
2020-04-01 13:45 ` Jean-Philippe Brucker
2020-04-01 13:45 ` Jean-Philippe Brucker
2020-04-01 22:50 ` Jacob Pan
2020-04-01 22:50 ` Jacob Pan
2020-03-25 17:55 ` [PATCH 02/10] iommu/vt-d: Set IOASID capacity when SVM is enabled Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 8:08 ` Tian, Kevin
2020-03-27 8:08 ` Tian, Kevin
2020-03-25 17:55 ` [PATCH 03/10] iommu/ioasid: Introduce per set allocation APIs Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-26 2:12 ` Lu Baolu
2020-03-26 2:12 ` Lu Baolu
2020-03-26 21:30 ` Jacob Pan
2020-03-26 21:30 ` Jacob Pan
2020-03-27 8:38 ` Tian, Kevin
2020-03-27 8:38 ` Tian, Kevin
2020-03-27 16:59 ` Jacob Pan
2020-03-27 16:59 ` Jacob Pan
2020-03-28 6:32 ` Tian, Kevin
2020-03-28 6:32 ` Tian, Kevin
2020-04-01 13:47 ` Jean-Philippe Brucker
2020-04-01 13:47 ` Jean-Philippe Brucker
2020-04-06 20:02 ` Jacob Pan [this message]
2020-04-06 20:02 ` Jacob Pan
2020-04-07 11:01 ` Jean-Philippe Brucker
2020-04-07 11:01 ` Jean-Philippe Brucker
2020-04-21 21:51 ` Jacob Pan
2020-04-21 21:51 ` Jacob Pan
2020-03-25 17:55 ` [PATCH 04/10] iommu/ioasid: Rename ioasid_set_data to avoid confusion with ioasid_set Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 9:35 ` Tian, Kevin
2020-03-27 9:35 ` Tian, Kevin
2020-03-25 17:55 ` [PATCH 05/10] iommu/ioasid: Create an IOASID set for host SVA use Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 9:41 ` Tian, Kevin
2020-03-27 9:41 ` Tian, Kevin
2020-03-27 17:28 ` Jacob Pan
2020-03-27 17:28 ` Jacob Pan
2020-03-28 6:33 ` Tian, Kevin
2020-03-28 6:33 ` Tian, Kevin
2020-04-01 13:53 ` Jean-Philippe Brucker
2020-04-01 13:53 ` Jean-Philippe Brucker
2020-04-06 15:33 ` Jacob Pan
2020-04-06 15:33 ` Jacob Pan
2020-04-07 11:01 ` Jean-Philippe Brucker
2020-04-07 11:01 ` Jean-Philippe Brucker
2020-04-13 22:06 ` Jacob Pan
2020-04-13 22:06 ` Jacob Pan
2020-04-15 15:10 ` Jean-Philippe Brucker
2020-04-15 15:10 ` Jean-Philippe Brucker
2020-03-25 17:55 ` [PATCH 06/10] iommu/ioasid: Convert to set aware allocations Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 9:54 ` Tian, Kevin
2020-03-27 9:54 ` Tian, Kevin
2020-03-27 17:41 ` Jacob Pan
2020-03-27 17:41 ` Jacob Pan
2020-03-28 6:40 ` Tian, Kevin
2020-03-28 6:40 ` Tian, Kevin
2020-04-06 20:07 ` Jacob Pan
2020-04-06 20:07 ` Jacob Pan
2020-04-01 13:55 ` Jean-Philippe Brucker
2020-04-01 13:55 ` Jean-Philippe Brucker
2020-04-01 22:45 ` Jacob Pan
2020-04-01 22:45 ` Jacob Pan
2020-03-25 17:55 ` [PATCH 07/10] iommu/ioasid: Use mutex instead of spinlock Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 9:55 ` Tian, Kevin
2020-03-27 9:55 ` Tian, Kevin
2020-04-01 13:58 ` Jean-Philippe Brucker
2020-04-01 13:58 ` Jean-Philippe Brucker
2020-03-25 17:55 ` [PATCH 08/10] iommu/ioasid: Introduce notifier APIs Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 10:03 ` Tian, Kevin
2020-03-27 10:03 ` Tian, Kevin
2020-03-27 18:36 ` Jacob Pan
2020-03-27 18:36 ` Jacob Pan
2020-03-28 6:43 ` Tian, Kevin
2020-03-28 6:43 ` Tian, Kevin
2020-03-31 15:13 ` Jacob Pan
2020-03-31 15:13 ` Jacob Pan
2020-04-01 14:00 ` Jean-Philippe Brucker
2020-04-01 14:00 ` Jean-Philippe Brucker
2020-04-10 15:43 ` Jacob Pan
2020-04-10 15:43 ` Jacob Pan
2020-03-25 17:55 ` [PATCH 09/10] iommu/ioasid: Support ioasid_set quota adjustment Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 10:09 ` Tian, Kevin
2020-03-27 10:09 ` Tian, Kevin
2020-03-27 23:30 ` Jacob Pan
2020-03-27 23:30 ` Jacob Pan
2020-03-28 6:44 ` Tian, Kevin
2020-03-28 6:44 ` Tian, Kevin
2020-03-25 17:55 ` [PATCH 10/10] iommu/vt-d: Register PASID notifier for status change Jacob Pan
2020-03-25 17:55 ` Jacob Pan
2020-03-27 10:22 ` Tian, Kevin
2020-03-27 10:22 ` Tian, Kevin
2020-03-27 23:47 ` Jacob Pan
2020-03-27 23:47 ` Jacob Pan
2020-04-01 14:03 ` [PATCH 00/10] IOASID extensions for guest SVA Jean-Philippe Brucker
2020-04-01 14:03 ` Jean-Philippe Brucker
2020-04-01 23:38 ` Jacob Pan
2020-04-01 23:38 ` Jacob Pan
2020-04-02 12:26 ` Jean-Philippe Brucker
2020-04-02 12:26 ` Jean-Philippe Brucker
2020-04-02 16:09 ` Jacob Pan
2020-04-02 16:09 ` Jacob Pan
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=20200406130245.690cfe15@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.com \
--cc=jean-philippe@linaro.org \
--cc=jic23@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.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.