All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux.dev, Robin Murphy <robin.murphy@arm.com>,
	Jason Gunthorpe <jgg@nvidia.com>, Joerg Roedel <joro@8bytes.org>,
	dmaengine@vger.kernel.org, vkoul@kernel.org,
	Will Deacon <will@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Raj Ashok <ashok.raj@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	"Zanussi, Tom" <tom.zanussi@intel.com>,
	jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v3 7/7] dmaengine/idxd: Re-enable kernel workqueue under DMA API
Date: Mon, 3 Apr 2023 14:54:58 -0700	[thread overview]
Message-ID: <20230403145458.5c30d5c6@jacob-builder> (raw)
In-Reply-To: <07b7a01f-8a0d-6eca-e436-df5135d679cb@linux.intel.com>

Hi Baolu,

On Sat, 1 Apr 2023 21:39:32 +0800, Baolu Lu <baolu.lu@linux.intel.com>
wrote:

> On 2023/4/1 7:11, Jacob Pan wrote:
> >   static void idxd_disable_system_pasid(struct idxd_device *idxd)
> >   {
> > +	struct pci_dev *pdev = idxd->pdev;
> > +	struct device *dev = &pdev->dev;
> > +	struct iommu_domain *domain;
> > +	union gencfg_reg gencfg;
> > +
> > +	domain = iommu_get_domain_for_dev(dev);
> > +	if (!domain || domain->type == IOMMU_DOMAIN_BLOCKED)
> > +		return;  
> 
> Out of curiosity, why do you need to check the domain type? And, in
> which case could the domain for the device be changed to a blocking one?
> 
> Once a driver is bound to the device, the driver "owns" the DMA of the
> device. No one else could change the domain except the driver itself.
nothing particular just for precaution, I can drop the check or add a
warn_on.

> > +
> > +	iommu_detach_device_pasid(domain, dev, idxd->pasid);
> > +	iommu_free_global_pasid(idxd->pasid);
> >   
> > -	iommu_sva_unbind_device(idxd->sva);
> > +	gencfg.bits = ioread32(idxd->reg_base + IDXD_GENCFG_OFFSET);
> > +	gencfg.user_int_en = 0;
> > +	iowrite32(gencfg.bits, idxd->reg_base + IDXD_GENCFG_OFFSET);
> >   	idxd->sva = NULL;
> > +	idxd->pasid = IOMMU_PASID_INVALID;
> >   }  
> 
> Best regards,
> baolu


Thanks,

Jacob

  reply	other threads:[~2023-04-03 21:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 23:11 [PATCH v3 0/7] Re-enable IDXD kernel workqueue under DMA API Jacob Pan
2023-03-31 23:11 ` [PATCH v3 1/7] iommu/vt-d: Use non-privileged mode for all PASIDs Jacob Pan
2023-04-01 13:41   ` Baolu Lu
2023-03-31 23:11 ` [PATCH v3 2/7] iommu/vt-d: Remove PASID supervisor request support Jacob Pan
2023-03-31 23:11 ` [PATCH v3 3/7] iommu/sva: Support allocation of global PASIDs outside SVA Jacob Pan
2023-04-01 13:16   ` Baolu Lu
2023-04-03 20:44     ` Jacob Pan
2023-04-01 13:28   ` Baolu Lu
2023-04-03 20:55     ` Jacob Pan
2023-03-31 23:11 ` [PATCH v3 4/7] iommu/vt-d: Reserve RID_PASID from global PASID space Jacob Pan
2023-04-01 13:43   ` Baolu Lu
2023-04-03 21:40     ` Jacob Pan
2023-03-31 23:11 ` [PATCH v3 5/7] iommu/vt-d: Make device pasid attachment explicit Jacob Pan
2023-03-31 23:11 ` [PATCH v3 6/7] iommu/vt-d: Implement set_dev_pasid domain op Jacob Pan
2023-04-01 13:48   ` Baolu Lu
2023-04-03 21:48     ` Jacob Pan
2023-04-04  5:24       ` Baolu Lu
2023-03-31 23:11 ` [PATCH v3 7/7] dmaengine/idxd: Re-enable kernel workqueue under DMA API Jacob Pan
2023-03-31 23:31   ` Yu, Fenghua
2023-04-03 21:56     ` Jacob Pan
2023-04-01 13:39   ` Baolu Lu
2023-04-03 21:54     ` Jacob Pan [this message]
2023-04-05 12:15   ` Jason Gunthorpe
2023-04-06  2:49     ` Baolu Lu
2023-04-06 12:23 ` [PATCH v3 0/7] Re-enable IDXD " Baolu Lu

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=20230403145458.5c30d5c6@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=fenghua.yu@intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tom.zanussi@intel.com \
    --cc=tony.luck@intel.com \
    --cc=vkoul@kernel.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@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.