From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <iommu@lists.linux.dev>, Joerg Roedel <joro@8bytes.org>,
<linux-arm-kernel@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>, Eric Auger <eric.auger@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Moritz Fischer <mdf@kernel.org>,
Michael Shavit <mshavit@google.com>, <patches@lists.linux.dev>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Subject: Re: [PATCH v7 02/14] iommu/arm-smmu-v3: Start building a generic PASID layer
Date: Sun, 12 May 2024 13:54:10 -0700 [thread overview]
Message-ID: <ZkEscmhh4I6PeP/S@nvidia.com> (raw)
In-Reply-To: <ZkDAL+TX93QfTFMc@nvidia.com>
On Sun, May 12, 2024 at 10:12:15AM -0300, Jason Gunthorpe wrote:
> On Fri, May 10, 2024 at 07:32:16PM -0700, Nicolin Chen wrote:
> > On Wed, May 08, 2024 at 03:57:10PM -0300, Jason Gunthorpe wrote:
> > > @@ -611,10 +599,9 @@ void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
> > > struct arm_smmu_bond *bond = NULL, *t;
> > > struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > >
> > > + arm_smmu_remove_pasid(master, to_smmu_domain(domain), id);
> > > +
> > > mutex_lock(&sva_lock);
> > > -
> > > - arm_smmu_clear_cd(master, id);
> > > -
> >
> > Should the new arm_smmu_remove_pasid() be inside the sva_lock as
> > the arm_smmu_clear_cd() previously? This would also seem to match
> > with the arm_smmu_set_pasid() that's inside the sva_lock too.
>
> Not needed, the sva_lock primarily protects the bond/etc stuff. The CD
> is locked by the group mutex. By the end of the series the sva_lock is
> just protecting the set_feature stuff, none of the attach flow.
I see. That lock in the end product does look cleaner.
> > > +int arm_smmu_set_pasid(struct arm_smmu_master *master,
> > > + struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
> > > + const struct arm_smmu_cd *cd)
> > > +{
> > > + struct arm_smmu_cd *cdptr;
> > > +
> > > + /* The core code validates pasid */
> > > +
> > > + if (!master->cd_table.in_ste)
> > > + return -ENODEV;
> > > +
> > > + cdptr = arm_smmu_alloc_cd_ptr(master, pasid);
> > > + if (!cdptr)
> > > + return -ENOMEM;
> >
> > Though I might be missing some piece, the in_ste is set in the
> > arm_smmu_install_ste_for_dev() when STE.Config=S1_TRANS, in which
> > case cdptr is already allocated?
>
> This only means that at least the first level of a two level (or
> entire linear) table is allocated.
>
> alloc_cd_ptr() is sill needed to allocate any second level. For
> instance if the PASID is > 1024 then we will need a new second level
> page as only SSID=0 will have been allocated.
Oh, I had misread that v.s. arm_smmu_alloc_cd_tables, while a
cdptr here is a CD entry.
Thanks
Nicolin
WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <iommu@lists.linux.dev>, Joerg Roedel <joro@8bytes.org>,
<linux-arm-kernel@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>, Eric Auger <eric.auger@redhat.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Moritz Fischer <mdf@kernel.org>,
Michael Shavit <mshavit@google.com>, <patches@lists.linux.dev>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Subject: Re: [PATCH v7 02/14] iommu/arm-smmu-v3: Start building a generic PASID layer
Date: Sun, 12 May 2024 13:54:10 -0700 [thread overview]
Message-ID: <ZkEscmhh4I6PeP/S@nvidia.com> (raw)
In-Reply-To: <ZkDAL+TX93QfTFMc@nvidia.com>
On Sun, May 12, 2024 at 10:12:15AM -0300, Jason Gunthorpe wrote:
> On Fri, May 10, 2024 at 07:32:16PM -0700, Nicolin Chen wrote:
> > On Wed, May 08, 2024 at 03:57:10PM -0300, Jason Gunthorpe wrote:
> > > @@ -611,10 +599,9 @@ void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
> > > struct arm_smmu_bond *bond = NULL, *t;
> > > struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > >
> > > + arm_smmu_remove_pasid(master, to_smmu_domain(domain), id);
> > > +
> > > mutex_lock(&sva_lock);
> > > -
> > > - arm_smmu_clear_cd(master, id);
> > > -
> >
> > Should the new arm_smmu_remove_pasid() be inside the sva_lock as
> > the arm_smmu_clear_cd() previously? This would also seem to match
> > with the arm_smmu_set_pasid() that's inside the sva_lock too.
>
> Not needed, the sva_lock primarily protects the bond/etc stuff. The CD
> is locked by the group mutex. By the end of the series the sva_lock is
> just protecting the set_feature stuff, none of the attach flow.
I see. That lock in the end product does look cleaner.
> > > +int arm_smmu_set_pasid(struct arm_smmu_master *master,
> > > + struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
> > > + const struct arm_smmu_cd *cd)
> > > +{
> > > + struct arm_smmu_cd *cdptr;
> > > +
> > > + /* The core code validates pasid */
> > > +
> > > + if (!master->cd_table.in_ste)
> > > + return -ENODEV;
> > > +
> > > + cdptr = arm_smmu_alloc_cd_ptr(master, pasid);
> > > + if (!cdptr)
> > > + return -ENOMEM;
> >
> > Though I might be missing some piece, the in_ste is set in the
> > arm_smmu_install_ste_for_dev() when STE.Config=S1_TRANS, in which
> > case cdptr is already allocated?
>
> This only means that at least the first level of a two level (or
> entire linear) table is allocated.
>
> alloc_cd_ptr() is sill needed to allocate any second level. For
> instance if the PASID is > 1024 then we will need a new second level
> page as only SSID=0 will have been allocated.
Oh, I had misread that v.s. arm_smmu_alloc_cd_tables, while a
cdptr here is a CD entry.
Thanks
Nicolin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-05-12 20:54 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 18:57 [PATCH v7 00/14] Update SMMUv3 to the modern iommu API (part 2b/3) Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-08 18:57 ` [PATCH v7 01/14] iommu/arm-smmu-v3: Convert to domain_alloc_sva() Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-09 18:21 ` Nicolin Chen
2024-05-09 18:21 ` Nicolin Chen
2024-05-09 18:40 ` Jason Gunthorpe
2024-05-09 18:40 ` Jason Gunthorpe
2024-05-08 18:57 ` [PATCH v7 02/14] iommu/arm-smmu-v3: Start building a generic PASID layer Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-11 2:32 ` Nicolin Chen
2024-05-11 2:32 ` Nicolin Chen
2024-05-12 13:12 ` Jason Gunthorpe
2024-05-12 13:12 ` Jason Gunthorpe
2024-05-12 20:54 ` Nicolin Chen [this message]
2024-05-12 20:54 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 03/14] iommu/arm-smmu-v3: Make smmu_domain->devices into an allocated list Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-11 3:12 ` Nicolin Chen
2024-05-11 3:12 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 04/14] iommu/arm-smmu-v3: Make changing domains be hitless for ATS Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-11 21:56 ` Nicolin Chen
2024-05-11 21:56 ` Nicolin Chen
2024-05-24 15:46 ` Jason Gunthorpe
2024-05-24 15:46 ` Jason Gunthorpe
2024-05-08 18:57 ` [PATCH v7 05/14] iommu/arm-smmu-v3: Add ssid to struct arm_smmu_master_domain Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-12 9:03 ` Nicolin Chen
2024-05-12 9:03 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 06/14] iommu/arm-smmu-v3: Do not use master->sva_enable to restrict attaches Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 6:01 ` Nicolin Chen
2024-05-13 6:01 ` Nicolin Chen
2024-05-13 20:58 ` Nicolin Chen
2024-05-13 20:58 ` Nicolin Chen
2024-05-14 22:51 ` Jason Gunthorpe
2024-05-14 22:51 ` Jason Gunthorpe
2024-05-15 0:36 ` Nicolin Chen
2024-05-15 0:36 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 07/14] iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*() interface Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 6:32 ` Nicolin Chen
2024-05-13 6:32 ` Nicolin Chen
2024-05-13 22:28 ` Jason Gunthorpe
2024-05-13 22:28 ` Jason Gunthorpe
2024-05-08 18:57 ` [PATCH v7 08/14] iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 6:36 ` Nicolin Chen
2024-05-13 6:36 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 09/14] iommu/arm-smmu-v3: Keep track of arm_smmu_master_domain for SVA Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 6:41 ` Nicolin Chen
2024-05-13 6:41 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 10/14] iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 21:23 ` Nicolin Chen
2024-05-13 21:23 ` Nicolin Chen
2024-05-17 19:48 ` Jason Gunthorpe
2024-05-17 19:48 ` Jason Gunthorpe
2024-05-17 20:34 ` Nicolin Chen
2024-05-17 20:34 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 11/14] iommu/arm-smmu-v3: Allow IDENTITY/BLOCKED to be set while PASID is used Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 7:11 ` Nicolin Chen
2024-05-13 7:11 ` Nicolin Chen
2024-05-14 23:02 ` Jason Gunthorpe
2024-05-14 23:02 ` Jason Gunthorpe
2024-05-15 0:32 ` Nicolin Chen
2024-05-15 0:32 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 12/14] iommu/arm-smmu-v3: Test the STE S1DSS functionality Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 21:34 ` Nicolin Chen
2024-05-13 21:34 ` Nicolin Chen
2024-05-08 18:57 ` [PATCH v7 13/14] iommu/arm-smmu-v3: Allow a PASID to be set when RID is IDENTITY/BLOCKED Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 8:31 ` Nicolin Chen
2024-05-13 8:31 ` Nicolin Chen
2024-05-21 17:51 ` Jason Gunthorpe
2024-05-21 17:51 ` Jason Gunthorpe
2024-05-08 18:57 ` [PATCH v7 14/14] iommu/arm-smmu-v3: Allow setting a S1 domain to a PASID Jason Gunthorpe
2024-05-08 18:57 ` Jason Gunthorpe
2024-05-13 8:34 ` Nicolin Chen
2024-05-13 8:34 ` Nicolin Chen
2024-05-09 9:39 ` [PATCH v7 00/14] Update SMMUv3 to the modern iommu API (part 2b/3) Nicolin Chen
2024-05-09 9:39 ` Nicolin Chen
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=ZkEscmhh4I6PeP/S@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mdf@kernel.org \
--cc=mshavit@google.com \
--cc=patches@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=will@kernel.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.