Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2670522ybb; Fri, 27 Mar 2020 09:55:25 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtgIlVR8KOeYbeTh0hLoHpFmGS22p51bDy6I0o6YMjdmhi+6dAvibBCWwz9m3m+H/XqGbQh X-Received: by 2002:aca:c695:: with SMTP id w143mr4695759oif.98.1585328125823; Fri, 27 Mar 2020 09:55:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585328125; cv=none; d=google.com; s=arc-20160816; b=kU0RVLnvpMRLf9090gBS2X9m84i/G/Vm9xYD6kNUMwYOo7hL8pHzDq0JdY2aucqEQ0 p6SY8Eoc8bimK/3tPfJqxXQ0i+c/Ys0sJGe75pb5EcP1yaBIjWExwmLjhib2Sm7gyGxG AoWFs59tnRA8zTB34Z2Tmf/698dBd9blK8tNF3I+OlCqHiM2i5Blj/krVeuatDYHhw2e zxfa3Gw9vKMzakxujfsyVEi4iOysrJU+ysJFUIvi3sfm/unhAD12cKD6tOGw4mFt1uwU N5Y/vDVcW+RDFosTTGh4DP6gibG/rzRudFHZdFRVnrICasrtklG6xqIfOeBMSeusWqw4 CTiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:ironport-sdr:ironport-sdr; bh=oWHjk25+mp8gBpDvCl6AqBZDIVrGEuFFw1U0B59nUfA=; b=fN7PCDUmpG8OcPy1id5iZBJ8A8yAh1zmn5HLbKQokAjTPOQsPNdYmwx/ZjconUeRCU B9xxCqGeQcYW/yjEBM2stfu1zM/To/DUF6MVo15ydjoxPGCskWSz1mXMN41u8ueZw+KP 9oJ6iz++xX1RuSWP6IdkHoA+EHE7IGTSeCzgC9ODmldxkWkFK2bsfMtGV4okpQ7Rm6A+ VAsSTiw3Ridw2UNnk0u+/uxoQwo4JIh0/NBJeavuUQxAZtsri3zkPwnDDtkMHbUW9mh9 4VaXpba3N56U//Z6d8uMGbE1GS6KR0BG5YH9id2cIcmfmummn7giVnN+vxWt3Zntdbzn FcOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si2727818otc.58.2020.03.27.09.55.11; Fri, 27 Mar 2020 09:55:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727701AbgC0Qxk convert rfc822-to-8bit (ORCPT + 99 others); Fri, 27 Mar 2020 12:53:40 -0400 Received: from mga06.intel.com ([134.134.136.31]:20409 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726900AbgC0Qxk (ORCPT ); Fri, 27 Mar 2020 12:53:40 -0400 IronPort-SDR: 1HPBv2x/RM6NHwsXfa/ltVFrMpGK9K7ELUzPp0fwE802R0jqhq89EYM5y9zWFKK9SH4LGIwWHP 1VVNf/h0TQpQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2020 09:53:38 -0700 IronPort-SDR: aPghkadiVzT/6DpiSbdM+7TEEwdiOv0kXMVQLIY3B4lmuNgH3UkLc0mWPutgdilKXwYe52ePRv uVXE9q2odRvw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,313,1580803200"; d="scan'208";a="394432438" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga004.jf.intel.com with ESMTP; 27 Mar 2020 09:53:38 -0700 Date: Fri, 27 Mar 2020 09:59:23 -0700 From: Jacob Pan To: "Tian, Kevin" Cc: Joerg Roedel , Alex Williamson , Lu Baolu , "iommu@lists.linux-foundation.org" , LKML , David Woodhouse , Jean-Philippe Brucker , "Liu, Yi L" , "Raj, Ashok" , Christoph Hellwig , Jonathan Cameron , Eric Auger , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH 03/10] iommu/ioasid: Introduce per set allocation APIs Message-ID: <20200327095923.4454cc7f@jacob-builder> In-Reply-To: References: <1585158931-1825-1-git-send-email-jacob.jun.pan@linux.intel.com> <1585158931-1825-4-git-send-email-jacob.jun.pan@linux.intel.com> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Mar 2020 08:38:44 +0000 "Tian, Kevin" wrote: > > From: Jacob Pan > > Sent: Thursday, March 26, 2020 1:55 AM > > > > 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 > > Signed-off-by: Jacob Pan > > --- > > 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 > > #include > > > > +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 > > what is a subset? is it a different thing from set? > Subset is a set, but a subset ID is an ID only valid within the set. When we have non-identity Guest-Host PASID mapping, Subset ID is the Guest PASID but in more general terms. Or call it "Set Private ID" This can be confusing, perhaps I rephrase it as: "XArray to store ioasid_set private ID to system-wide IOASID mapping" > > + * @size: Max number of IOASIDs can be allocated within the > > set > > 'size' reads more like 'current size' instead of 'max size'. maybe > call it 'max_ioasids' to align with 'nr_ioasids'? or simplify both as > 'max' and 'nr'? > Right, how about max_id and nr_id? > > + * @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 > > 'a set of IOASIDS' sounds like 'many IOASIDs'. Just saying 'allocate > an IOASID set' is more clear. ???? > Make sense > > + * @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; > > + } > > + > > + sdata = kzalloc(sizeof(*sdata), GFP_KERNEL); > > + if (!sdata) > > + return -ENOMEM; > > + > > + spin_lock(&ioasid_allocator_lock); > > + > > + ret = xa_alloc(&ioasid_sets, &id, sdata, > > + XA_LIMIT(0, ioasid_capacity_avail - quota), > > + GFP_KERNEL); > > Interestingly I didn't find the definition of ioasid_sets. and it is > not in existing file. > It is at the beginning of this file +static DEFINE_XARRAY_ALLOC(ioasid_sets); > I'm not sure how many sets can be created, but anyway the set > namespace is different from ioasid name space. Then why do we > use ioasid capability as the limitation for allocating set id here? > I am assuming the worst case scenario which is one IOASID per set, that is why the number of sets are limited by the number of system IOASIDs. > > + if (ret) { > > + kfree(sdata); > > + goto error; > > + } > > + > > + sdata->token = token; > > given token must be unique, a check on any conflict is required here? > Right, I will add a check to reject duplicated tokens. /* Search existing set tokens, reject duplicates */ xa_for_each(&ioasid_sets, index, sdata) { if (sdata->token == token) { pr_warn("Token already exists in the set %lu\n", index); ret = -EEXIST; goto error; } } > > + 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. > > looks 'subset' is the same thing as 'set'. let's make it consistent. > Sounds good, will also rename subset ID to set private ID. > > + */ > > + 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) > > +{ > > what is the actual usage of just freeing ioasid while keeping the > set itself? > I was thinking users use mm as token can retain the ioasid_set until mm being destroyed. This is to support some kind of lazy free. > > + 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; > > + } > > why is it a warning condition? it is possible that an user has done > ioasid_free for all allocated ioasids and then call this function, > which is actually the expected normal situation. > You are right, there is no need to warn. I will put the following comment in place. /* The set is already empty, we just destroy the set if requested */ if (xa_empty(&sdata->xa)) 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); > > + } > > but the placeholder would lead to undesired behavior, not good for > bisect. If no support now, then should return an error if any in-use > ioasid is not freed. > Good point, I will return -ENOTSUPP in the place holder. Remove it during the API conversion. > > + > > +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. > > please unify capitalization around IOASID or ioasid. > Will do. > Thanks > Kevin > > > + * > > + * @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 > philippe.brucker@arm.com>"); > > MODULE_AUTHOR("Jacob Pan "); > > 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]