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
WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>,
David Woodhouse <dwmw2@infradead.org>,
ashok.raj@intel.com, sanjay.k.kumar@intel.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
yi.y.sun@intel.com, jacob.jun.pan@intel.com
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@linux.intel.com>
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: 27+ 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 ` 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-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 2:18 ` Peter Xu
2018-07-11 7:26 ` Lu Baolu
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-11 7:39 ` Peter Xu
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-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
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 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.