iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	yi.y.sun-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH v4 6/9] iommu/vt-d: Per PCI device pasid table interfaces
Date: Wed, 11 Jul 2018 15:39:32 +0800	[thread overview]
Message-ID: <20180711073932.GA15615@xz-mi> (raw)
In-Reply-To: <5B45B11D.1080405-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

On Wed, Jul 11, 2018 at 03:26:21PM +0800, Lu Baolu wrote:

[...]

> >> +int intel_pasid_alloc_table(struct device *dev)
> >> +{
> >> +	struct device_domain_info *info;
> >> +	struct pasid_table *pasid_table;
> >> +	struct pasid_table_opaque data;
> >> +	struct page *pages;
> >> +	size_t size, count;
> >> +	int ret, order;
> >> +
> >> +	info = dev->archdata.iommu;
> >> +	if (WARN_ON(!info || !dev_is_pci(dev) ||
> >> +		    !info->pasid_supported || info->pasid_table))
> >> +		return -EINVAL;
> >> +
> >> +	/* DMA alias device already has a pasid table, use it: */
> >> +	data.pasid_table = &pasid_table;
> >> +	ret = pci_for_each_dma_alias(to_pci_dev(dev),
> >> +				     &get_alias_pasid_table, &data);
> >> +	if (ret)
> >> +		goto attach_out;
> >> +
> >> +	pasid_table = kzalloc(sizeof(*pasid_table), GFP_ATOMIC);
> > Do we need to take some lock here (e.g., the pasid lock)?  Otherwise
> > what if two devices (that are sharing the same DMA alias) call the
> > function intel_pasid_alloc_table() concurrently, then could it
> > possible that we create one table for each of the device while AFAIU
> > we should let them share a single pasid table?
> 
> The only place where this function is called is in a single-thread context
> (protected by a spinlock of device_domain_lock with local interrupt disabled).
> 
> So we don't need an extra lock here. But anyway, I should put a comment
> here.

Yeah, that would be nice too!  Or add a comment for both of the
functions:

  /* Must be with device_domain_lock held */

Regards,

-- 
Peter Xu

  parent reply	other threads:[~2018-07-11  7:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09  5:22 [PATCH v4 0/9] iommu/vt-d: Improve PASID id and table management Lu Baolu
2018-07-09  5:22 ` [PATCH v4 1/9] iommu/vt-d: Global PASID name space Lu Baolu
2018-07-11  2:48   ` Peter Xu
2018-07-11  6:32     ` Lu Baolu
2018-07-09  5:22 ` [PATCH v4 2/9] iommu/vt-d: Avoid using idr_for_each_entry() Lu Baolu
2018-07-09  5:22 ` [PATCH v4 3/9] iommu/vt-d: Apply global PASID in SVA Lu Baolu
2018-07-09  5:22 ` [PATCH v4 4/9] iommu/vt-d: Move device_domain_info to header Lu Baolu
2018-07-09  5:22 ` [PATCH v4 5/9] iommu/vt-d: Add for_each_device_domain() helper Lu Baolu
2018-07-09  5:22 ` [PATCH v4 6/9] iommu/vt-d: Per PCI device pasid table interfaces Lu Baolu
     [not found]   ` <1531113778-28238-7-git-send-email-baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-11  2:18     ` Peter Xu
2018-07-11  7:26       ` Lu Baolu
     [not found]         ` <5B45B11D.1080405-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-11  7:39           ` Peter Xu [this message]
2018-07-09  5:22 ` [PATCH v4 7/9] iommu/vt-d: Allocate and free pasid table Lu Baolu
2018-07-09  5:22 ` [PATCH v4 8/9] iommu/vt-d: Apply per pci device pasid table in SVA Lu Baolu
2018-07-09  5:22 ` [PATCH v4 9/9] iommu/vt-d: Remove the obsolete per iommu pasid tables Lu Baolu
2018-07-11  2:45   ` Peter Xu
2018-07-11  6:43     ` Lu Baolu
2018-07-13  1:34     ` Lu Baolu
2018-07-13  5:00       ` Peter Xu
2018-07-14  7:23         ` 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=20180711073932.GA15615@xz-mi \
    --to=peterx-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=yi.y.sun-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).