From: Lu Baolu <baolu.lu@linux.intel.com> To: Jacob Pan <jacob.jun.pan@intel.com> Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>, ashok.raj@intel.com, kevin.tian@intel.com, Jean-Philippe Brucker <jean-philippe@linaro.org>, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/11] iommu/vt-d: Add pasid private data helpers Date: Mon, 24 May 2021 10:16:18 +0800 [thread overview] Message-ID: <15bdf989-40c9-2b45-0fb6-273a43479789@linux.intel.com> (raw) In-Reply-To: <20210521142518.25087d34@jacob-builder> Hi Jacob, Thanks for reviewing my patch. On 5/22/21 5:25 AM, Jacob Pan wrote: > Hi BaoLu, > > On Thu, 20 May 2021 11:15:21 +0800, Lu Baolu <baolu.lu@linux.intel.com> > wrote: > >> We are about to use iommu_sva_alloc/free_pasid() helpers in iommu core. >> That means the pasid life cycle will be managed by iommu core. Use a >> local array to save the per pasid private data instead of attaching it >> the real pasid. >> > I feel a little awkward to have a separate xarray for storing per IOASID > data. Seems duplicated. > Jason suggested in another thread that we can make ioasid_data public > and embeded in struct intel_svm, then we can get rid of the private data > pointer. ioasid_find will return the ioasid_data, then we can retrieve the > private data with container_of. The problem that this patch wants to solve is that the iommu_sva_alloc_pasid() will attach the mm pointer to the sva pasid. pasid = ioasid_alloc(&iommu_sva_pasid, min, max, mm); Assuming that each sva pasid can have only a single private data pointer, the vendor iommu driver shouldn't set the private data again. > > roughly, > > struct intel_svm { > ... > struct ioasid_data; > }; > > struct ioasid_data { > ioasid_t id; > refcount_t refs; > struct mm_struct *mm; > }; > > This can be a separate patch/effort if it make sense to you. Yes if we have a better solution. Best regards, baolu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com> To: Jacob Pan <jacob.jun.pan@intel.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>, kevin.tian@intel.com, ashok.raj@intel.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org Subject: Re: [PATCH 01/11] iommu/vt-d: Add pasid private data helpers Date: Mon, 24 May 2021 10:16:18 +0800 [thread overview] Message-ID: <15bdf989-40c9-2b45-0fb6-273a43479789@linux.intel.com> (raw) In-Reply-To: <20210521142518.25087d34@jacob-builder> Hi Jacob, Thanks for reviewing my patch. On 5/22/21 5:25 AM, Jacob Pan wrote: > Hi BaoLu, > > On Thu, 20 May 2021 11:15:21 +0800, Lu Baolu <baolu.lu@linux.intel.com> > wrote: > >> We are about to use iommu_sva_alloc/free_pasid() helpers in iommu core. >> That means the pasid life cycle will be managed by iommu core. Use a >> local array to save the per pasid private data instead of attaching it >> the real pasid. >> > I feel a little awkward to have a separate xarray for storing per IOASID > data. Seems duplicated. > Jason suggested in another thread that we can make ioasid_data public > and embeded in struct intel_svm, then we can get rid of the private data > pointer. ioasid_find will return the ioasid_data, then we can retrieve the > private data with container_of. The problem that this patch wants to solve is that the iommu_sva_alloc_pasid() will attach the mm pointer to the sva pasid. pasid = ioasid_alloc(&iommu_sva_pasid, min, max, mm); Assuming that each sva pasid can have only a single private data pointer, the vendor iommu driver shouldn't set the private data again. > > roughly, > > struct intel_svm { > ... > struct ioasid_data; > }; > > struct ioasid_data { > ioasid_t id; > refcount_t refs; > struct mm_struct *mm; > }; > > This can be a separate patch/effort if it make sense to you. Yes if we have a better solution. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-05-24 2:17 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-20 3:15 [PATCH 00/11] Convert Intel IOMMU to use sva-lib helpers Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 01/11] iommu/vt-d: Add pasid private data helpers Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-21 21:25 ` Jacob Pan 2021-05-21 21:25 ` Jacob Pan 2021-05-24 2:16 ` Lu Baolu [this message] 2021-05-24 2:16 ` Lu Baolu 2021-05-24 18:54 ` Jacob Pan 2021-05-24 18:54 ` Jacob Pan 2021-05-20 3:15 ` [PATCH 02/11] iommu/vt-d: Use iommu_sva_alloc(free)_pasid() helpers Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 03/11] iommu/vt-d: Use common helper to lookup svm devices Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 04/11] iommu/vt-d: Refactor prq_event_thread() Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 05/11] iommu/vt-d: Allocate/register iopf queue for sva devices Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 06/11] iommu/vt-d: Report prq to io-pgfault framework Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 07/11] iommu/vt-d: Add prq_report trace event Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 08/11] iommu/vt-d: Add common code for dmar latency performance monitors Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 09/11] iommu/vt-d: Expose latency monitor data through debugfs Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 10/11] iommu/vt-d: Add cache invalidation latency sampling Lu Baolu 2021-05-20 3:15 ` Lu Baolu 2021-05-20 3:15 ` [PATCH 11/11] iommu/vt-d: Add PRQ handling " Lu Baolu 2021-05-20 3:15 ` Lu Baolu
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=15bdf989-40c9-2b45-0fb6-273a43479789@linux.intel.com \ --to=baolu.lu@linux.intel.com \ --cc=ashok.raj@intel.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@intel.com \ --cc=jean-philippe@linaro.org \ --cc=joro@8bytes.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: linkBe 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.