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
next prev 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).