All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Yi L <yi.l.liu@linux.intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v8 02/10] iommu/vt-d: Add nested translation helper function
Date: Fri, 10 Jan 2020 10:25:41 -0800	[thread overview]
Message-ID: <20200110102541.736219a7@jacob-builder> (raw)
In-Reply-To: <89cc7a91-f645-e331-8f02-62c281c0ea3d@linux.intel.com>

On Fri, 10 Jan 2020 09:15:45 +0800
Lu Baolu <baolu.lu@linux.intel.com> wrote:

> Hi Jacob,
> 
> On 1/10/20 2:39 AM, Jacob Pan wrote:
> > On Wed, 18 Dec 2019 10:41:53 +0800
> > Lu Baolu <baolu.lu@linux.intel.com> wrote:
> >   
> >> Hi again,
> >>
> >> On 12/17/19 3:24 AM, Jacob Pan wrote:  
> >>> +/**
> >>> + * intel_pasid_setup_nested() - Set up PASID entry for nested
> >>> translation
> >>> + * which is used for vSVA. The first level page tables are used
> >>> for
> >>> + * GVA-GPA or GIOVA-GPA translation in the guest, second level
> >>> page tables
> >>> + *  are used for GPA-HPA translation.
> >>> + *
> >>> + * @iommu:      Iommu which the device belong to
> >>> + * @dev:        Device to be set up for translation
> >>> + * @gpgd:       FLPTPTR: First Level Page translation pointer in
> >>> GPA
> >>> + * @pasid:      PASID to be programmed in the device PASID table
> >>> + * @pasid_data: Additional PASID info from the guest bind request
> >>> + * @domain:     Domain info for setting up second level page
> >>> tables
> >>> + * @addr_width: Address width of the first level (guest)
> >>> + */
> >>> +int intel_pasid_setup_nested(struct intel_iommu *iommu,
> >>> +			struct device *dev, pgd_t *gpgd,
> >>> +			int pasid, struct
> >>> iommu_gpasid_bind_data_vtd *pasid_data,
> >>> +			struct dmar_domain *domain,
> >>> +			int addr_width)
> >>> +{
> >>> +	struct pasid_entry *pte;
> >>> +	struct dma_pte *pgd;
> >>> +	u64 pgd_val;
> >>> +	int agaw;
> >>> +	u16 did;
> >>> +
> >>> +	if (!ecap_nest(iommu->ecap)) {
> >>> +		pr_err("IOMMU: %s: No nested translation
> >>> support\n",
> >>> +		       iommu->name);
> >>> +		return -EINVAL;
> >>> +	}
> >>> +
> >>> +	pte = intel_pasid_get_entry(dev, pasid);
> >>> +	if (WARN_ON(!pte))
> >>> +		return -EINVAL;
> >>> +
> >>> +	pasid_clear_entry(pte);  
> >>
> >> In some cases, e.g. nested mode for GIOVA-HPA, the PASID entry
> >> might have already been setup for second level translation. (This
> >> could be checked with the Present bit.) Hence, it's safe to flush
> >> caches here.
> >>
> >> Or, maybe intel_pasid_tear_down_entry() is more suitable?
> >>  
> > We don't allow binding the same device-PASID twice, so if the PASID
> > entry was used for GIOVA/RID2PASID, it should unbind first, and
> > teardown flush included, right?
> >   
> 
> Fair enough. Can you please add this as a comment to this function? So
> that the caller of this interface can know this. Or add a check in
> this function which returns error if the pasid entry has already been
> bond.
> 
Sounds good, i will do both comment and check as this:

	/*
	 * Caller must ensure PASID entry is not in use, i.e. not bind the
	 * same PASID to the same device twice.
	 */
	if (pasid_pte_is_present(pte))
		return -EBUSY;
We already have the check in the current caller.
Thanks,
> Best regards,
> baolu

[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: Lu Baolu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>, Yi Liu <yi.l.liu@intel.com>,
	Eric Auger <eric.auger@redhat.com>,
	Yi L <yi.l.liu@linux.intel.com>,
	jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v8 02/10] iommu/vt-d: Add nested translation helper function
Date: Fri, 10 Jan 2020 10:25:41 -0800	[thread overview]
Message-ID: <20200110102541.736219a7@jacob-builder> (raw)
In-Reply-To: <89cc7a91-f645-e331-8f02-62c281c0ea3d@linux.intel.com>

On Fri, 10 Jan 2020 09:15:45 +0800
Lu Baolu <baolu.lu@linux.intel.com> wrote:

> Hi Jacob,
> 
> On 1/10/20 2:39 AM, Jacob Pan wrote:
> > On Wed, 18 Dec 2019 10:41:53 +0800
> > Lu Baolu <baolu.lu@linux.intel.com> wrote:
> >   
> >> Hi again,
> >>
> >> On 12/17/19 3:24 AM, Jacob Pan wrote:  
> >>> +/**
> >>> + * intel_pasid_setup_nested() - Set up PASID entry for nested
> >>> translation
> >>> + * which is used for vSVA. The first level page tables are used
> >>> for
> >>> + * GVA-GPA or GIOVA-GPA translation in the guest, second level
> >>> page tables
> >>> + *  are used for GPA-HPA translation.
> >>> + *
> >>> + * @iommu:      Iommu which the device belong to
> >>> + * @dev:        Device to be set up for translation
> >>> + * @gpgd:       FLPTPTR: First Level Page translation pointer in
> >>> GPA
> >>> + * @pasid:      PASID to be programmed in the device PASID table
> >>> + * @pasid_data: Additional PASID info from the guest bind request
> >>> + * @domain:     Domain info for setting up second level page
> >>> tables
> >>> + * @addr_width: Address width of the first level (guest)
> >>> + */
> >>> +int intel_pasid_setup_nested(struct intel_iommu *iommu,
> >>> +			struct device *dev, pgd_t *gpgd,
> >>> +			int pasid, struct
> >>> iommu_gpasid_bind_data_vtd *pasid_data,
> >>> +			struct dmar_domain *domain,
> >>> +			int addr_width)
> >>> +{
> >>> +	struct pasid_entry *pte;
> >>> +	struct dma_pte *pgd;
> >>> +	u64 pgd_val;
> >>> +	int agaw;
> >>> +	u16 did;
> >>> +
> >>> +	if (!ecap_nest(iommu->ecap)) {
> >>> +		pr_err("IOMMU: %s: No nested translation
> >>> support\n",
> >>> +		       iommu->name);
> >>> +		return -EINVAL;
> >>> +	}
> >>> +
> >>> +	pte = intel_pasid_get_entry(dev, pasid);
> >>> +	if (WARN_ON(!pte))
> >>> +		return -EINVAL;
> >>> +
> >>> +	pasid_clear_entry(pte);  
> >>
> >> In some cases, e.g. nested mode for GIOVA-HPA, the PASID entry
> >> might have already been setup for second level translation. (This
> >> could be checked with the Present bit.) Hence, it's safe to flush
> >> caches here.
> >>
> >> Or, maybe intel_pasid_tear_down_entry() is more suitable?
> >>  
> > We don't allow binding the same device-PASID twice, so if the PASID
> > entry was used for GIOVA/RID2PASID, it should unbind first, and
> > teardown flush included, right?
> >   
> 
> Fair enough. Can you please add this as a comment to this function? So
> that the caller of this interface can know this. Or add a check in
> this function which returns error if the pasid entry has already been
> bond.
> 
Sounds good, i will do both comment and check as this:

	/*
	 * Caller must ensure PASID entry is not in use, i.e. not bind the
	 * same PASID to the same device twice.
	 */
	if (pasid_pte_is_present(pte))
		return -EBUSY;
We already have the check in the current caller.
Thanks,
> Best regards,
> baolu

[Jacob Pan]

  reply	other threads:[~2020-01-10 18:20 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16 19:24 [PATCH v8 00/10] Nested Shared Virtual Address (SVA) VT-d support Jacob Pan
2019-12-16 19:24 ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 01/10] iommu/vt-d: Move domain helper to header Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 02/10] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-18  2:01   ` Lu Baolu
2019-12-18  2:01     ` Lu Baolu
2020-01-09 17:51     ` Jacob Pan
2020-01-09 17:51       ` Jacob Pan
2019-12-18  2:41   ` Lu Baolu
2019-12-18  2:41     ` Lu Baolu
2020-01-09 18:39     ` Jacob Pan
2020-01-09 18:39       ` Jacob Pan
2020-01-10  1:15       ` Lu Baolu
2020-01-10  1:15         ` Lu Baolu
2020-01-10 18:25         ` Jacob Pan [this message]
2020-01-10 18:25           ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 03/10] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-18  3:14   ` Lu Baolu
2019-12-18  3:14     ` Lu Baolu
2020-01-09 21:45     ` Jacob Pan
2020-01-09 21:45       ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 04/10] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-19  2:46   ` Lu Baolu
2019-12-19  2:46     ` Lu Baolu
2020-01-09 21:50     ` Jacob Pan
2020-01-09 21:50       ` Jacob Pan
2020-01-10  1:17       ` Lu Baolu
2020-01-10  1:17         ` Lu Baolu
2019-12-16 19:24 ` [PATCH v8 05/10] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 06/10] iommu/vt-d: Cache virtual command capability register Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-18  3:25   ` Lu Baolu
2019-12-18  3:25     ` Lu Baolu
2020-01-09 21:59     ` Jacob Pan
2020-01-09 21:59       ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 07/10] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 08/10] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-18  4:10   ` Lu Baolu
2019-12-18  4:10     ` Lu Baolu
2020-01-09 22:06     ` Jacob Pan
2020-01-09 22:06       ` Jacob Pan
2020-01-10  1:19       ` Lu Baolu
2020-01-10  1:19         ` Lu Baolu
2019-12-16 19:24 ` [PATCH v8 09/10] iommu/ioasid: Add notifier for status change Jacob Pan
2019-12-16 19:24   ` Jacob Pan
2019-12-16 19:24 ` [PATCH v8 10/10] iommu/vt-d: Handle IOASID notifications Jacob Pan
2019-12-16 19:24   ` 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=20200110102541.736219a7@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yi.l.liu@linux.intel.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.