From: "Zhang, Tina" <tina.zhang@intel.com> To: "Tian, Kevin" <kevin.tian@intel.com>, David Stevens <stevensd@chromium.org>, Lu Baolu <baolu.lu@linux.intel.com> Cc: "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: RE: [PATCH v2] iommu/vt-d: calculate mask for non-aligned flushes Date: Fri, 25 Mar 2022 07:15:12 +0000 [thread overview] Message-ID: <MW5PR11MB58814148CD05C8284C3BCB23891A9@MW5PR11MB5881.namprd11.prod.outlook.com> (raw) In-Reply-To: <BN9PR11MB52761E41CAD28CFCB935688C8C1A9@BN9PR11MB5276.namprd11.prod.outlook.com> > -----Original Message----- > From: iommu <iommu-bounces@lists.linux-foundation.org> On Behalf Of > Tian, Kevin > Sent: Friday, March 25, 2022 2:14 PM > To: David Stevens <stevensd@chromium.org>; Lu Baolu > <baolu.lu@linux.intel.com> > Cc: iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH v2] iommu/vt-d: calculate mask for non-aligned flushes > > > From: David Stevens > > Sent: Tuesday, March 22, 2022 2:36 PM > > > > From: David Stevens <stevensd@chromium.org> > > > > Calculate the appropriate mask for non-size-aligned page selective > > invalidation. Since psi uses the mask value to mask out the lower > > order bits of the target address, properly flushing the iotlb requires > > using a mask value such that [pfn, pfn+pages) all lie within the > > flushed size-aligned region. This is not normally an issue because > > iova.c always allocates iovas that are aligned to their size. However, > > iovas which come from other sources (e.g. userspace via VFIO) may not > > be aligned. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > --- > > v1 -> v2: > > - Calculate an appropriate mask for non-size-aligned iovas instead > > of falling back to domain selective flush. > > > > drivers/iommu/intel/iommu.c | 27 ++++++++++++++++++++++++--- > > 1 file changed, 24 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > > index 5b196cfe9ed2..ab2273300346 100644 > > --- a/drivers/iommu/intel/iommu.c > > +++ b/drivers/iommu/intel/iommu.c > > @@ -1717,7 +1717,8 @@ static void iommu_flush_iotlb_psi(struct > > intel_iommu *iommu, > > unsigned long pfn, unsigned int pages, > > int ih, int map) > > { > > - unsigned int mask = ilog2(__roundup_pow_of_two(pages)); > > + unsigned int aligned_pages = __roundup_pow_of_two(pages); > > + unsigned int mask = ilog2(aligned_pages); > > uint64_t addr = (uint64_t)pfn << VTD_PAGE_SHIFT; > > u16 did = domain->iommu_did[iommu->seq_id]; > > > > @@ -1729,10 +1730,30 @@ static void iommu_flush_iotlb_psi(struct > > intel_iommu *iommu, > > if (domain_use_first_level(domain)) { > > domain_flush_piotlb(iommu, domain, addr, pages, ih); > > } else { > > + unsigned long bitmask = aligned_pages - 1; > > + > > + /* > > + * PSI masks the low order bits of the base address. If the > > + * address isn't aligned to the mask, then compute a mask > > value > > + * needed to ensure the target range is flushed. > > + */ > > + if (unlikely(bitmask & pfn)) { > > + unsigned long end_pfn = pfn + pages - 1, shared_bits; > > + > > + /* > > + * Since end_pfn <= pfn + bitmask, the only way bits > > + * higher than bitmask can differ in pfn and end_pfn > > is > > + * by carrying. This means after masking out bitmask, > > + * high bits starting with the first set bit in > > + * shared_bits are all equal in both pfn and end_pfn. > > + */ > > + shared_bits = ~(pfn ^ end_pfn) & ~bitmask; > > + mask = shared_bits ? __ffs(shared_bits) : > > BITS_PER_LONG; > > + } > > While it works I wonder whether below is simpler regarding to readability: > > } else { > + /* > + * PSI masks the low order bits of the base address. If the > + * address isn't aligned to the mask and [pfn, pfn+pages) > + * don't all lie within the flushed size-aligned region, > + * simply increment the mask by one to cover the trailing > pages. > + */ > + if (unlikely((pfn & (aligned_pages - 1)) && > + (pfn + pages - 1 >= ALIGN(pfn, aligned_pages)))) > + mask++; According to the vt-d spec, increasing mask means more bits of the pfn would be masked out. So simply increasing the mask number might not be correct. This second version does give more consideration on that. BR, Tina > > Thanks > Kevin > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/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: "Zhang, Tina" <tina.zhang@intel.com> To: "Tian, Kevin" <kevin.tian@intel.com>, David Stevens <stevensd@chromium.org>, Lu Baolu <baolu.lu@linux.intel.com> Cc: "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: RE: [PATCH v2] iommu/vt-d: calculate mask for non-aligned flushes Date: Fri, 25 Mar 2022 07:15:12 +0000 [thread overview] Message-ID: <MW5PR11MB58814148CD05C8284C3BCB23891A9@MW5PR11MB5881.namprd11.prod.outlook.com> (raw) In-Reply-To: <BN9PR11MB52761E41CAD28CFCB935688C8C1A9@BN9PR11MB5276.namprd11.prod.outlook.com> > -----Original Message----- > From: iommu <iommu-bounces@lists.linux-foundation.org> On Behalf Of > Tian, Kevin > Sent: Friday, March 25, 2022 2:14 PM > To: David Stevens <stevensd@chromium.org>; Lu Baolu > <baolu.lu@linux.intel.com> > Cc: iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH v2] iommu/vt-d: calculate mask for non-aligned flushes > > > From: David Stevens > > Sent: Tuesday, March 22, 2022 2:36 PM > > > > From: David Stevens <stevensd@chromium.org> > > > > Calculate the appropriate mask for non-size-aligned page selective > > invalidation. Since psi uses the mask value to mask out the lower > > order bits of the target address, properly flushing the iotlb requires > > using a mask value such that [pfn, pfn+pages) all lie within the > > flushed size-aligned region. This is not normally an issue because > > iova.c always allocates iovas that are aligned to their size. However, > > iovas which come from other sources (e.g. userspace via VFIO) may not > > be aligned. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > --- > > v1 -> v2: > > - Calculate an appropriate mask for non-size-aligned iovas instead > > of falling back to domain selective flush. > > > > drivers/iommu/intel/iommu.c | 27 ++++++++++++++++++++++++--- > > 1 file changed, 24 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > > index 5b196cfe9ed2..ab2273300346 100644 > > --- a/drivers/iommu/intel/iommu.c > > +++ b/drivers/iommu/intel/iommu.c > > @@ -1717,7 +1717,8 @@ static void iommu_flush_iotlb_psi(struct > > intel_iommu *iommu, > > unsigned long pfn, unsigned int pages, > > int ih, int map) > > { > > - unsigned int mask = ilog2(__roundup_pow_of_two(pages)); > > + unsigned int aligned_pages = __roundup_pow_of_two(pages); > > + unsigned int mask = ilog2(aligned_pages); > > uint64_t addr = (uint64_t)pfn << VTD_PAGE_SHIFT; > > u16 did = domain->iommu_did[iommu->seq_id]; > > > > @@ -1729,10 +1730,30 @@ static void iommu_flush_iotlb_psi(struct > > intel_iommu *iommu, > > if (domain_use_first_level(domain)) { > > domain_flush_piotlb(iommu, domain, addr, pages, ih); > > } else { > > + unsigned long bitmask = aligned_pages - 1; > > + > > + /* > > + * PSI masks the low order bits of the base address. If the > > + * address isn't aligned to the mask, then compute a mask > > value > > + * needed to ensure the target range is flushed. > > + */ > > + if (unlikely(bitmask & pfn)) { > > + unsigned long end_pfn = pfn + pages - 1, shared_bits; > > + > > + /* > > + * Since end_pfn <= pfn + bitmask, the only way bits > > + * higher than bitmask can differ in pfn and end_pfn > > is > > + * by carrying. This means after masking out bitmask, > > + * high bits starting with the first set bit in > > + * shared_bits are all equal in both pfn and end_pfn. > > + */ > > + shared_bits = ~(pfn ^ end_pfn) & ~bitmask; > > + mask = shared_bits ? __ffs(shared_bits) : > > BITS_PER_LONG; > > + } > > While it works I wonder whether below is simpler regarding to readability: > > } else { > + /* > + * PSI masks the low order bits of the base address. If the > + * address isn't aligned to the mask and [pfn, pfn+pages) > + * don't all lie within the flushed size-aligned region, > + * simply increment the mask by one to cover the trailing > pages. > + */ > + if (unlikely((pfn & (aligned_pages - 1)) && > + (pfn + pages - 1 >= ALIGN(pfn, aligned_pages)))) > + mask++; According to the vt-d spec, increasing mask means more bits of the pfn would be masked out. So simply increasing the mask number might not be correct. This second version does give more consideration on that. BR, Tina > > Thanks > Kevin > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-25 7:15 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-22 6:35 [PATCH v2] iommu/vt-d: calculate mask for non-aligned flushes David Stevens 2022-03-22 6:35 ` David Stevens 2022-03-25 6:13 ` Tian, Kevin 2022-03-25 6:13 ` Tian, Kevin 2022-03-25 7:15 ` Zhang, Tina [this message] 2022-03-25 7:15 ` Zhang, Tina 2022-03-25 7:43 ` David Stevens 2022-03-25 7:43 ` David Stevens 2022-03-25 8:17 ` Tian, Kevin 2022-03-25 8:17 ` Tian, Kevin 2022-03-28 8:53 ` Lu Baolu 2022-03-28 8:53 ` 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=MW5PR11MB58814148CD05C8284C3BCB23891A9@MW5PR11MB5881.namprd11.prod.outlook.com \ --to=tina.zhang@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=iommu@lists.linux-foundation.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=stevensd@chromium.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.