All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Mostafa Saleh <smostafa@google.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>,
	Michael Shavit <mshavit@google.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	patches@lists.linux.dev, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 4/7] iommu/arm-smmu-v3: Split struct arm_smmu_ctx_desc_cfg.cdtab
Date: Thu, 6 Jun 2024 20:59:20 -0300	[thread overview]
Message-ID: <20240606235920.GG19897@nvidia.com> (raw)
In-Reply-To: <Zl87uRwIJyfMW1xs@google.com>

On Tue, Jun 04, 2024 at 04:07:21PM +0000, Mostafa Saleh wrote:
> > @@ -1236,7 +1235,7 @@ struct arm_smmu_cd *arm_smmu_alloc_cd_ptr(struct arm_smmu_master *master,
> >  			if (arm_smmu_alloc_cd_leaf_table(smmu, l1_desc))
> >  				return NULL;
> >  
> > -			l1ptr = cd_table->cdtab + idx * CTXDESC_L1_DESC_DWORDS;
> 
> Similarly to patch 1, I believe we can get rid of CTXDESC_L1_DESC_DWORDS entirely.

I gave CD the same treatment, it ends up like:

struct arm_smmu_cd {
	__le64 data[8];
};

struct arm_smmu_cdtab_l2 {
	struct arm_smmu_cd cds[CTXDESC_L2_ENTRIES];
};

struct arm_smmu_cdtab_l1 {
	__le64 l2ptr;
};

struct arm_smmu_ctx_desc_cfg {
	union {
		struct {
			struct arm_smmu_cd *table;
			unsigned int num_ents;
		} linear;
		struct {
			struct arm_smmu_cdtab_l1 *l1tab;
			struct arm_smmu_cdtab_l2 **l2ptrs;
			unsigned int num_l1_ents;
		} l2;
	};
	dma_addr_t			cdtab_dma;
	u8				s1fmt;
	/* log2 of the maximum number of CDs supported by this table */
	u8				s1cdmax;
};

And we can remove a bunch of the #defines in favour of sizeof()

> > -	dmam_free_coherent(smmu->dev, l1size, cd_table->cdtab, cd_table->cdtab_dma);
> >  	cd_table->cdtab_dma = 0;
> > -	cd_table->cdtab = NULL;
> > +	cd_table->cdtab.linear = NULL;
> 
> nit: AFAIU, arm_smmu_cdtab_allocated() was added to check the cd table existence
> regardless the config.
> So, I think we should be consistent, as here it is set as linear, while it can be 2lvl.

I deleted this code, the tables are allocated once and stay allocated
forever until release when the entire cd_table is deleted. No reason
to 0 memory we are about to kfree.

Thanks,
Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Mostafa Saleh <smostafa@google.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>,
	Michael Shavit <mshavit@google.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	patches@lists.linux.dev, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 4/7] iommu/arm-smmu-v3: Split struct arm_smmu_ctx_desc_cfg.cdtab
Date: Thu, 6 Jun 2024 20:59:20 -0300	[thread overview]
Message-ID: <20240606235920.GG19897@nvidia.com> (raw)
In-Reply-To: <Zl87uRwIJyfMW1xs@google.com>

On Tue, Jun 04, 2024 at 04:07:21PM +0000, Mostafa Saleh wrote:
> > @@ -1236,7 +1235,7 @@ struct arm_smmu_cd *arm_smmu_alloc_cd_ptr(struct arm_smmu_master *master,
> >  			if (arm_smmu_alloc_cd_leaf_table(smmu, l1_desc))
> >  				return NULL;
> >  
> > -			l1ptr = cd_table->cdtab + idx * CTXDESC_L1_DESC_DWORDS;
> 
> Similarly to patch 1, I believe we can get rid of CTXDESC_L1_DESC_DWORDS entirely.

I gave CD the same treatment, it ends up like:

struct arm_smmu_cd {
	__le64 data[8];
};

struct arm_smmu_cdtab_l2 {
	struct arm_smmu_cd cds[CTXDESC_L2_ENTRIES];
};

struct arm_smmu_cdtab_l1 {
	__le64 l2ptr;
};

struct arm_smmu_ctx_desc_cfg {
	union {
		struct {
			struct arm_smmu_cd *table;
			unsigned int num_ents;
		} linear;
		struct {
			struct arm_smmu_cdtab_l1 *l1tab;
			struct arm_smmu_cdtab_l2 **l2ptrs;
			unsigned int num_l1_ents;
		} l2;
	};
	dma_addr_t			cdtab_dma;
	u8				s1fmt;
	/* log2 of the maximum number of CDs supported by this table */
	u8				s1cdmax;
};

And we can remove a bunch of the #defines in favour of sizeof()

> > -	dmam_free_coherent(smmu->dev, l1size, cd_table->cdtab, cd_table->cdtab_dma);
> >  	cd_table->cdtab_dma = 0;
> > -	cd_table->cdtab = NULL;
> > +	cd_table->cdtab.linear = NULL;
> 
> nit: AFAIU, arm_smmu_cdtab_allocated() was added to check the cd table existence
> regardless the config.
> So, I think we should be consistent, as here it is set as linear, while it can be 2lvl.

I deleted this code, the tables are allocated once and stay allocated
forever until release when the entire cd_table is deleted. No reason
to 0 memory we are about to kfree.

Thanks,
Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-06-06 23:59 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 22:31 [PATCH 0/7] Tidy some minor things in the stream table/cd table area Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 1/7] iommu/arm-smmu-v3: Split struct arm_smmu_strtab_cfg.strtab Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04  8:32   ` Nicolin Chen
2024-06-04  8:32     ` Nicolin Chen
2024-06-04 12:59     ` Jason Gunthorpe
2024-06-04 12:59       ` Jason Gunthorpe
2024-06-04 18:28       ` Nicolin Chen
2024-06-04 18:28         ` Nicolin Chen
2024-06-04 19:02         ` Jason Gunthorpe
2024-06-04 19:02           ` Jason Gunthorpe
2024-06-04 19:28           ` Nicolin Chen
2024-06-04 19:28             ` Nicolin Chen
2024-06-04 15:52   ` Mostafa Saleh
2024-06-04 15:52     ` Mostafa Saleh
2024-06-05 23:51     ` Jason Gunthorpe
2024-06-05 23:51       ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 2/7] iommu/arm-smmu-v3: Do not zero the strtab twice Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04 15:56   ` Mostafa Saleh
2024-06-04 15:56     ` Mostafa Saleh
2024-06-05 21:22     ` Jason Gunthorpe
2024-06-05 21:22       ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 3/7] iommu/arm-smmu-v3: Shrink the strtab l1_desc array Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04 16:01   ` Mostafa Saleh
2024-06-04 16:01     ` Mostafa Saleh
2024-06-03 22:31 ` [PATCH 4/7] iommu/arm-smmu-v3: Split struct arm_smmu_ctx_desc_cfg.cdtab Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04 16:07   ` Mostafa Saleh
2024-06-04 16:07     ` Mostafa Saleh
2024-06-06 23:59     ` Jason Gunthorpe [this message]
2024-06-06 23:59       ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 5/7] iommu/arm-smmu-v3: Do not use devm for the cd table allocations Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 6/7] iommu/arm-smmu-v3: Shrink the cdtab l1_desc array Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04 16:14   ` Mostafa Saleh
2024-06-04 16:14     ` Mostafa Saleh
2024-06-03 22:31 ` [PATCH 7/7] iommu/arm-smmu-v3: Use the new rb tree helpers Jason Gunthorpe
2024-06-03 22:31   ` Jason Gunthorpe
2024-06-04 16:22   ` Mostafa Saleh
2024-06-04 16:22     ` Mostafa Saleh
2024-06-03 22:41 ` [PATCH 0/7] Tidy some minor things in the stream table/cd table area Nicolin Chen
2024-06-03 22:41   ` 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=20240606235920.GG19897@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mshavit@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=smostafa@google.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.