From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, "Tian, Kevin" <kevin.tian@intel.com>
Cc: baolu.lu@linux.intel.com,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Nicolin Chen <nicolinc@nvidia.com>,
"Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: [PATCH 00/14] Add iommufd physical device operations for replace and alloc hwpt
Date: Wed, 8 Mar 2023 10:08:04 +0800 [thread overview]
Message-ID: <d441b9bb-e9b2-190d-981b-1fdc288b0a07@linux.intel.com> (raw)
In-Reply-To: <ZAcyEzN4102gPsWC@nvidia.com>
On 3/7/23 8:46 PM, Jason Gunthorpe wrote:
> On Tue, Mar 07, 2023 at 08:42:06AM +0000, Tian, Kevin wrote:
>>> From: Jason Gunthorpe<jgg@nvidia.com>
>>> Sent: Saturday, February 25, 2023 8:28 AM
>>>
>> [...]
>>> The implementation is complicated because we have to introduce some
>>> per-iommu_group memory in iommufd and redo how we think about multi-
>>> device
>>> groups to be more explicit. This solves all the locking problems in the
>>> prior attempts.
>>>
>> Now think about the pasid case.
>>
>> pasid attach is managed as a device operation today:
>> iommu_attach_device_pasid()
>>
>> Following it naturally we'll have a pasid array per iommufd_device to
>> track attached HWPT per pasid.
>>
>> But internally there is only one pasid table per iommu group. i.e. same
>> story as RID attach that once dev1 replaces hwpt on pasid1 then it takes
>> effect on all other devices in the same group.
> IMHO I can't belive that any actual systems that support PASID have a
> RID aliasing problem too.
>
> I think we should fix the iommu core to make PASID per-device and
> require systems that have a RID aliasing problem to block PASID.
>
> This is a bigger picture, if drivers have to optionally share their
> PASID tables with other drivers then we can't have per-driver PASID
> allocators at all either.
This is actually required in PCI and IOMMU core. pci_enable_pasid()
requires full ACS support on device's upstream path:
if (!pci_acs_path_enabled(pdev, NULL, PCI_ACS_RR | PCI_ACS_UF))
return -EINVAL;
and, for such PCI topology, iommu core always allocates an exclusive
iommu group.
The only place where seems to be a little messy is,
static int __iommu_set_group_pasid(struct iommu_domain *domain,
struct iommu_group *group, ioasid_t
pasid)
{
struct group_device *device;
int ret = 0;
list_for_each_entry(device, &group->devices, list) {
ret = domain->ops->set_dev_pasid(domain, device->dev,
pasid);
if (ret)
break;
}
return ret;
}
Perhaps we need a check on singleton group?
Best regards,
baolu
next prev parent reply other threads:[~2023-03-08 2:09 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-25 0:27 [PATCH 00/14] Add iommufd physical device operations for replace and alloc hwpt Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 01/14] iommufd: Move isolated msi enforcement to iommufd_device_bind() Jason Gunthorpe
2023-03-02 7:45 ` Tian, Kevin
2023-02-25 0:27 ` [PATCH 02/14] iommufd: Add iommufd_group Jason Gunthorpe
2023-03-02 7:55 ` Tian, Kevin
2023-03-02 12:51 ` Jason Gunthorpe
2023-03-03 2:13 ` Tian, Kevin
2023-03-06 19:16 ` Jason Gunthorpe
2023-03-07 2:32 ` Tian, Kevin
2023-02-25 0:27 ` [PATCH 03/14] iommufd: Replace the hwpt->devices list with iommufd_group Jason Gunthorpe
2023-03-02 8:01 ` Tian, Kevin
2023-03-06 20:22 ` Jason Gunthorpe
2023-03-07 2:38 ` Tian, Kevin
2023-03-07 13:53 ` Jason Gunthorpe
2023-03-08 7:29 ` Tian, Kevin
2023-03-08 19:00 ` Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 04/14] iommufd: Use the iommufd_group to avoid duplicate reserved groups and msi setup Jason Gunthorpe
2023-03-02 8:06 ` Tian, Kevin
2023-03-02 12:55 ` Jason Gunthorpe
2023-03-03 2:16 ` Tian, Kevin
2023-02-25 0:27 ` [PATCH 05/14] iommufd: Make sw_msi_start a group global Jason Gunthorpe
2023-03-02 8:09 ` Tian, Kevin
2023-03-06 20:27 ` Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 06/14] iommufd: Move putting a hwpt to a helper function Jason Gunthorpe
2023-03-02 8:12 ` Tian, Kevin
2023-03-06 20:29 ` Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 07/14] iommufd: Add enforced_cache_coherency to iommufd_hw_pagetable_alloc() Jason Gunthorpe
2023-03-02 8:14 ` Tian, Kevin
2023-02-25 0:27 ` [PATCH 08/14] iommu: Introduce a new iommu_group_replace_domain() API Jason Gunthorpe
2023-03-02 8:16 ` Tian, Kevin
2023-02-25 0:27 ` [PATCH 09/14] iommufd: Add iommufd_device_replace() Jason Gunthorpe
2023-02-26 3:01 ` Baolu Lu
2023-02-27 13:58 ` Jason Gunthorpe
2023-02-28 1:50 ` Baolu Lu
2023-02-28 13:51 ` Jason Gunthorpe
2023-03-01 1:55 ` Baolu Lu
2023-02-26 3:13 ` Baolu Lu
2023-02-27 14:00 ` Jason Gunthorpe
2023-02-28 2:10 ` Baolu Lu
2023-02-28 13:52 ` Jason Gunthorpe
2023-03-01 2:23 ` Baolu Lu
2023-03-02 8:20 ` Tian, Kevin
2023-03-06 20:44 ` Jason Gunthorpe
2023-03-07 2:42 ` Tian, Kevin
2023-03-07 13:54 ` Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 10/14] iommufd: Make destroy_rwsem use a lock class per object type Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 11/14] iommufd/selftest: Test iommufd_device_replace() Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 12/14] iommufd: Add IOMMU_HWPT_ALLOC Jason Gunthorpe
2023-03-06 1:42 ` Nicolin Chen
2023-03-06 20:31 ` Jason Gunthorpe
2023-03-17 3:02 ` Tian, Kevin
2023-03-17 4:02 ` Nicolin Chen
2023-03-17 10:20 ` Tian, Kevin
2023-03-21 17:16 ` Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 13/14] iommufd/selftest: Return the real idev id from selftest mock_domain Jason Gunthorpe
2023-02-25 0:27 ` [PATCH 14/14] iommufd/selftest: Add a selftest for IOMMU_HWPT_ALLOC Jason Gunthorpe
2023-02-26 19:29 ` Nicolin Chen
2023-02-27 15:02 ` Jason Gunthorpe
2023-02-28 0:17 ` Nicolin Chen
2023-03-07 8:42 ` [PATCH 00/14] Add iommufd physical device operations for replace and alloc hwpt Tian, Kevin
2023-03-07 12:46 ` Jason Gunthorpe
2023-03-08 2:08 ` Baolu Lu [this message]
2023-03-08 7:38 ` Tian, Kevin
2023-03-08 18:59 ` Jason Gunthorpe
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=d441b9bb-e9b2-190d-981b-1fdc288b0a07@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--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.